Illucrum blog

Shopify SEO: 7 Issues the Platform Creates

Szymon Kokot — Mon, 06 Apr 2026 07:30:00 GMT

Shopify makes launching an online store fast. It handles hosting, SSL, sitemaps, and basic mobile responsiveness out of the box. What it does not handle well is the structural SEO work that determines whether your store actually appears in search results. The platform's rigid URL system, automatic duplicate content generation, and limited control over indexing create problems that most store owners never notice until their rankings stall.

This is not a general SEO guide. It is specifically about the issues Shopify introduces and what you can do about them. If you are running a Shopify store and organic traffic is not where it should be, at least one of these is probably why.

In short: Shopify is a strong e-commerce platform, but its default settings create duplicate content, bloated indexes, and thin pages that hurt search rankings. Fixing these platform-specific issues is the fastest path to better organic performance for most Shopify stores.

1. Duplicate Product URLs

This is Shopify's most persistent SEO problem, and it is baked into the platform's architecture. When a product belongs to more than one collection, Shopify creates a separate URL for each collection path.

A single pair of running shoes might be accessible at /products/trail-runner-pro, /collections/mens-shoes/products/trail-runner-pro, and /collections/new-arrivals/products/trail-runner-pro. All three URLs serve identical content.

Shopify adds canonical tags that point to the /products/ version, which helps. But the internal links on your site, particularly from collection pages, often point to the collection-based URL rather than the canonical one. This sends mixed signals to search engines about which version matters and splits your link equity across multiple pages.

The fix has two parts. First, audit your internal links to ensure they point to the canonical /products/ URL, not the collection path. This usually requires editing your theme's Liquid templates. Second, use Google Search Console to verify that the correct URLs are being indexed and that duplicate versions are not appearing in search results.

2. Tag Pages and Index Bloat

Shopify generates a new page every time you use tags to filter products within a collection. If you sell clothing and use tags like "cotton," "long-sleeve," "red," and "summer," each combination creates a unique, indexable URL.

These tag pages carry the same products as your main collection page, with no way to add unique titles, descriptions, or introductory content through Shopify's standard admin. From Google's perspective, they are thin, duplicate pages. A store with 20 collections and 10 tags per collection can accidentally generate 200 near-identical pages competing with your actual category pages.

The most reliable fix is adding a noindex directive to tag pages. This keeps them functional for shoppers (they can still filter products) while preventing search engines from treating them as separate pages. You can do this by adding conditional logic to your theme's section that inserts a noindex meta tag when the URL contains a /tagged/ path.

If specific tag pages genuinely target unique keywords (for example, a "vegan leather" tag page in a handbag store), you can selectively allow indexing for those pages while noindexing the rest. But this is the exception, not the rule.

3. Thin Product and Collection Content

Shopify's content editing tools are functional but basic. The product description field is a simple rich text editor, and collection pages default to displaying a product grid with minimal or no descriptive text. Many store owners leave these fields empty or paste in the manufacturer's default description.

Both choices hurt search rankings. Empty or near-identical descriptions mean Google has no unique content to index on these pages. When the same manufacturer description appears on your store and 30 competitors' stores, none of you will rank well for it.

For product pages, write original descriptions of at least 150 to 300 words per product. Lead with benefits and use cases rather than technical specifications. Include your primary keyword within the first 100 words, and add secondary terms naturally throughout.

For collection pages, add 200 to 300 words of unique descriptive copy above or below the product grid. This is the single most underrated optimisation for Shopify stores. Collection pages can rank for high-volume category keywords ("women's running shoes," "organic skincare") that individual product pages cannot.

4. Rigid URL Structure

Shopify enforces a fixed URL structure that you cannot change. Products always live under /products/, collections under /collections/, blog posts under /blogs/[blog-name]/, and pages under /pages/. There is no way to create a custom URL hierarchy like /shoes/running/trail-runner-pro/.

This is not a serious ranking disadvantage on its own. Google can rank pages regardless of their URL path. But it does mean your URLs provide less contextual information to search engines than a flexible platform like WooCommerce would allow.

Where this becomes a practical problem is in breadcrumb navigation. Shopify's default breadcrumbs are naturally shallow because there is no true parent-child category relationship in the URL structure. You can implement breadcrumb schema markup to help Google understand your site hierarchy even though the URLs don't reflect it, but this requires manual coding in your theme.

Focus your effort on what you can control: make URL slugs short and descriptive (edit the "URL and handle" field for every product and collection), and use internal linking to establish the relationships between pages that the URL structure cannot express.

5. Page Speed and Theme Bloat

Shopify's hosted infrastructure is fast by default. The problems come from what store owners add on top of it: heavy themes, too many apps, unoptimised images, and third-party scripts.

Every Shopify app you install adds JavaScript and CSS to your pages. A store with 15 apps can easily add two to three seconds of load time. Many of these apps continue loading their scripts on every page even when their functionality is only needed on one.

Themes are another factor. A theme that looks impressive in the Shopify Theme Store might have render-blocking JavaScript, unoptimised image delivery, and poor Core Web Vitals scores. According to industry data, a large majority of Shopify stores load slower than Google's recommended thresholds.

The fixes here are straightforward but require discipline. Audit your installed apps and remove anything you are not actively using. Compress all product images before uploading (tools like TinyPNG or Squoosh work well). Choose a lightweight theme, or have your current theme audited for performance issues. Use lazy loading for images below the fold.

6. Missing or Generic Structured Data

Shopify does not include rich schema markup by default. Some themes add basic Product schema, but many do not include critical fields like review ratings, availability, price currency, or brand information.

Without proper structured data, your products cannot appear in Google's rich results (the listings that show star ratings, prices, and stock status directly in search results). They also cannot appear in Google Shopping's free product listings. In 2026, with AI-generated search overviews pulling structured data to answer product queries, missing schema means your store is invisible in an increasing share of search results.

The implementation path depends on your technical comfort level. You can add Product schema directly to your theme's Liquid templates, use a Shopify app like Smart SEO or JSON-LD for SEO, or have a developer implement it. Whichever method you choose, validate the markup afterwards using Google's Rich Results Test. Broken schema can actually prevent your pages from displaying correctly, so validation is not optional.

At minimum, every product page should include: product name, description, brand, SKU or GTIN, price, currency, availability status, and aggregate review rating (if you have reviews). Collection pages benefit from FAQ schema if you add descriptive content that answers common questions about the product category.

7. Limited Blog Functionality

Shopify includes a built-in blog, but it is basic compared to WordPress or dedicated content platforms. You get a title, a rich text body, tags, and a featured image. There is no table of contents generation, no advanced layout options, no native support for FAQ schema, and limited control over URL structure.

This matters because content marketing is how online stores capture informational and long-tail keywords that product pages cannot target. "How to choose running shoes for flat feet" or "best materials for kitchen knives" are searches that a blog post can rank for and that a product page never will.

The blog limitation is a genuine constraint, but it is not a reason to skip content entirely. You can work around most of the formatting issues by editing HTML within blog posts, and FAQ schema can be added to your theme's blog template. Some stores opt for a separate blog on a subdomain (using WordPress or a platform like Hashnode) to get more flexibility, though this introduces additional complexity around domain authority and link equity.

What matters more than the platform is consistency. A Shopify blog with one well-written, keyword-targeted post per month will outperform no blog at all. Start with topics your customers actually search for: buying guides, size guides, material comparisons, care instructions. Each post should link to relevant product and collection pages, creating the internal linking network that both users and search engines rely on.

Frequently Asked Questions

Is Shopify good for SEO?

Shopify handles many SEO fundamentals well: SSL, mobile responsiveness, XML sitemaps, and canonical tags are all included by default. But the platform's rigid URL structure, duplicate content generation, and limited technical control create issues that require manual fixes. Shopify is a capable SEO platform, but it is not a hands-off one.

Does changing my Shopify theme affect SEO?

It can. A new theme may change your page load speed, heading structure, schema markup, and mobile layout. Before switching themes, benchmark your current Core Web Vitals scores and review the new theme's code quality. After switching, re-validate your structured data and check Google Search Console for any new crawl errors.

How do I fix duplicate content on Shopify?

Shopify's duplicate content comes primarily from two sources: products appearing in multiple collections (creating multiple URLs) and tag pages. For collection-based duplicates, ensure internal links point to the canonical /products/ URL. For tag pages, add a noindex directive to your theme's section for any URL containing /tagged/.

Do I need a Shopify SEO app?

An SEO app can help with bulk editing meta tags, generating structured data, and automating image alt text. If you have hundreds of products, the time savings are significant. Smart SEO and JSON-LD for SEO are well-regarded options. Avoid installing multiple SEO apps, as they often conflict with each other and add unnecessary load time.

How often should I audit my Shopify store's SEO?

A full audit once or twice per year is a reasonable starting point. Between audits, monitor Google Search Console monthly for crawl errors, indexing issues, and keyword performance changes. Any time you add a significant number of products, change themes, or install new apps, check your technical SEO metrics to catch regressions early.

What to Do Next

Shopify's SEO challenges are real, but they are also well-understood and fixable. Most stores underperform in search not because the platform is fundamentally limited, but because these platform-specific issues go unaddressed.

If your store's organic traffic is flat or declining, the issues above are the first place to look. An e-commerce SEO audit built specifically for Shopify will identify exactly which of these problems exist on your store and prioritise fixes by impact. If you already know what needs fixing, the optimisation work can be handled for you.

E-Commerce SEO: What Online Stores Get Wrong

Szymon Kokot — Mon, 30 Mar 2026 07:30:00 GMT

Most online stores treat SEO as something you bolt on after launch. Add a few keywords to product titles, install an SEO plugin, and hope for the best. The problem is that e-commerce sites face structural challenges that a generic SEO checklist will never catch. Duplicate product URLs, bloated tag pages, thin category content, slow load times caused by image-heavy catalogues; these are not edge cases. They are the default state of most online stores, and they quietly suppress rankings for months before anyone notices.

This guide covers the areas where e-commerce SEO differs from standard website optimisation, why those differences matter, and what to prioritise if your store is not getting the organic traffic it should.

In short: E-commerce SEO is not generic SEO applied to a shop. Product pages, category architecture, structured data, and platform-specific technical issues all require a different approach. Stores that treat SEO as a technical discipline rather than an afterthought consistently outperform those relying on paid ads alone.

Why Is E-Commerce SEO Different from Regular SEO?

A typical business website might have 10 to 50 pages. An online store can have hundreds or thousands. That scale changes everything about how search engines crawl, index, and rank your content.

Three things make e-commerce SEO distinct. First, product pages generate duplicate content by default. A single product listed in three different collections creates three separate URLs with identical content. Search engines don't know which one to rank, so they often rank none of them well.

Second, category and tag pages can create index bloat. Every filter combination (size, colour, material, price range) can produce a unique URL. Left unmanaged, a store with 200 products might generate 2,000 indexable pages, most of them thin or near-identical.

Third, commercial intent keywords behave differently from informational ones. Someone searching "waterproof hiking boots size 42" is ready to buy. Someone searching "how to waterproof hiking boots" wants information. Your product pages and your blog content need to target these two groups separately, with different page types and different content strategies.

Product Pages: Where Most Stores Lose Rankings

Product pages are the commercial core of any online store, and they are where most SEO effort falls apart. The most common issue is copied manufacturer descriptions. If 30 other stores carry the same product with the same description, Google has no reason to rank yours above theirs.

Writing unique product descriptions takes time. For a store with 500 products, it is a genuine investment. But it is also the single most impactful on-page change most stores can make. Descriptions don't need to be long; 150 to 300 words per product is enough. What matters is that they are original, that they include the primary keyword naturally, and that they lead with benefits and specific use cases rather than a generic feature list.

Beyond descriptions, product pages need proper title tags (unique per product, under 60 characters), descriptive alt text on every image, and structured data markup. Product schema (name, price, availability, reviews) is what makes your products eligible for rich results in Google, including star ratings, prices, and stock status directly in search results.

Category Pages: The Most Underestimated Asset

Many store owners treat collection or category pages as simple product grids. A heading, a row of thumbnails, and nothing else. This is a missed opportunity.

Category pages target broader, higher-volume keywords. "Women's running shoes" gets far more searches than any individual shoe model. A category page with 200 to 300 words of well-written descriptive copy gives search engines the context they need to understand what the page is about and rank it accordingly.

Effective category page optimisation goes beyond adding text. It includes clear heading structure, internal links to related categories and subcategories, and a logical URL hierarchy. A flat structure where every category sits at the same level makes it harder for both users and search engines to understand how your products relate to each other.

The ideal site architecture for an online store follows a simple rule: every product should be reachable within three clicks from the homepage. Homepage links to main categories, categories link to subcategories, subcategories link to products. Breadcrumb navigation reinforces this hierarchy and gives search engines an explicit map of your site's structure.

Technical SEO for E-Commerce: The Invisible Foundation

Technical SEO is where e-commerce sites accumulate the most damage without realising it. The issues are rarely visible to the store owner, but they are very visible to search engines.

Duplicate URLs: Most e-commerce platforms create multiple URLs for the same product when it belongs to more than one collection. Without canonical tags pointing to the preferred version, you split your ranking power across duplicate pages. This is platform-specific; Shopify handles it differently from WooCommerce, which handles it differently from Magento. Each requires a different fix.

Tag and filter pages: When customers use filters (size, colour, price range), each combination can generate a unique URL. These pages usually contain the same products as the parent category, just in a different order. If they are indexed, they dilute your site's authority across dozens or hundreds of near-identical pages. The fix is typically a combination of canonical tags, noindex directives, and careful use of robots.txt.

Page speed: Online stores are inherently heavier than content websites. Product images, review widgets, recommendation carousels, chat plugins, and analytics scripts all add load time. Research consistently shows that every additional second of load time costs measurable conversion rate points. Google's Core Web Vitals remain a ranking factor, and most e-commerce themes underperform on mobile without deliberate optimisation.

Pagination: Stores with large catalogues need pagination that search engines can follow. If Google can only see the first page of a 20-page category, the products on pages 2 through 20 may never get indexed.

E-Commerce Keyword Strategy: Think in Layers

Keyword research for an online store is not a single list. It works in layers that map to different page types.

Product keywords are specific and high-intent: "Nike Air Zoom Pegasus 40 women's" or "Le Creuset 5.5 qt Dutch oven." These target product pages and often convert at the highest rate because the searcher already knows what they want.

Category keywords are broader: "women's running shoes" or "cast iron cookware." These target collection pages and capture shoppers who are browsing rather than buying a specific item.

Long-tail and modifier keywords combine product types with qualifiers: "best running shoes for flat feet" or "lightweight Dutch oven for camping." These often work best as blog content that links to relevant product or category pages.

Problem-solution keywords are informational: "how to season a Dutch oven" or "running shoes for plantar fasciitis." These attract top-of-funnel traffic through content marketing and build authority over time.

The mistake most stores make is targeting only one layer. They optimise product pages for product keywords and ignore everything else. A complete keyword strategy covers all four layers, with each page type serving a different stage of the buyer journey.

Structured Data: Making Your Products Visible Beyond Blue Links

In 2026, Google's search results for product queries are dominated by rich results: Shopping carousels, product panels with prices and reviews, image packs, and AI-generated overviews. Stores that implement structured data correctly appear in these features. Stores that don't are invisible in the most valuable parts of the results page.

At minimum, every product page should include Product schema with name, description, brand, price, currency, availability, and review ratings. This markup tells search engines exactly what is on the page and makes your products eligible for rich result display.

Beyond Product schema, stores should consider FAQ schema on category pages (for common questions about the product type), Breadcrumb schema (to show site hierarchy in search results), and Organisation schema on the homepage.

The setup is technical but not complex. Most e-commerce platforms support it either natively or through apps and plugins. The important thing is to validate your markup using Google's Rich Results Test after implementation; broken schema is worse than no schema because it can prevent your pages from appearing correctly.

AI Search and Generative Engine Optimisation

Google's AI Overviews now appear on a significant share of search results, and tools like ChatGPT, Perplexity, and Claude are increasingly used for product research. This does not require a separate strategy, but it does reinforce the importance of clear, well-structured content.

AI systems pull information from pages that are well-organised, factually specific, and authoritative. The same practices that drive traditional SEO rankings (unique content, structured data, clear headings, fast load times, strong backlink profiles) also make your store more likely to be cited in AI-generated answers.

The stores that will perform best in both traditional and AI-powered search are the ones that treat their content as a product in its own right: well-researched, clearly written, and structured for machines as much as for humans.

Frequently Asked Questions

How long does it take for e-commerce SEO to show results?

Most stores see measurable changes within three to six months, depending on the starting point. Technical fixes (page speed, duplicate content, schema markup) can produce faster gains because they remove existing barriers. Content and link-building strategies compound over time and typically show stronger results after six months.

Is e-commerce SEO different for Shopify vs WooCommerce?

The principles are the same, but the implementation differs significantly. Shopify has a rigid URL structure and auto-generates duplicate product URLs across collections. WooCommerce offers more flexibility but can suffer from plugin bloat and slower performance. Each platform has specific technical issues that require platform-aware solutions.

Do I need a blog on my online store?

A blog is the most effective way to target informational and long-tail keywords that product and category pages cannot. It builds topical authority, creates internal linking opportunities, and captures top-of-funnel traffic that may convert later. Stores without content marketing are limited to ranking for purely commercial terms, which are usually the most competitive.

What is the most common e-commerce SEO mistake?

Using manufacturer-provided product descriptions that are identical across dozens of other stores. This creates a duplicate content problem that is invisible to the store owner but obvious to search engines. Writing unique descriptions for even your top 50 products will have a measurable impact.

Where to Start

E-commerce SEO is not one task; it is a system of overlapping disciplines that compound when done well. If your store is not generating the organic traffic you expect, the issue is almost always in one of the areas covered above: product page content, category structure, technical health, or keyword coverage.

The most efficient starting point is an audit that evaluates all of these areas against your specific platform and competitive landscape. Once you know what is actually holding your store back, you can prioritise fixes by impact rather than guessing. And if the fixes require more hands than you have, the implementation can be handled for you.

What Is an SEO Audit?

Szymon Kokot — Mon, 23 Mar 2026 08:30:00 GMT

If your website is not bringing in the traffic or leads you expected, the first useful question is: why? An SEO audit answers that question. It is a structured review of your website across the factors that determine whether Google shows it to the people searching for what you offer. This article explains what an audit actually covers, what it produces, and how to know whether your business needs one.

In short: An SEO audit is a systematic review of your website's technical setup, content, keywords, backlinks, and user experience. It identifies the specific issues holding back your search visibility and delivers a prioritised list of what to fix, in what order, and why each fix matters to your business.

What does an SEO audit actually check?

A professional SEO audit covers several categories, each focused on a different aspect of how search engines evaluate your website. These are the main areas.

Technical SEO looks at how well Google can access, crawl, and index your site. It covers page speed, mobile-friendliness, Core Web Vitals, HTTPS status, crawl errors, and whether your sitemap and robots.txt files are configured correctly. Technical issues are often invisible to visitors but can quietly prevent your pages from appearing in search results at all.

On-page SEO assesses the content and HTML elements on your individual pages. This includes title tags, meta descriptions, heading structure, keyword usage, content quality, and internal links. On-page SEO is where many SME websites lose ground; a page might rank on page two instead of page one simply because its title tag is poorly written or its headings don't match what people actually search for.

Keyword strategy evaluates whether your site targets the right search terms and whether your content matches the intent behind those terms. A law firm writing articles about "legal precedent analysis" when potential clients are searching "do I need a lawyer for a lease dispute" is a keyword strategy problem. The audit checks for gaps like this.

Backlink profile reviews the external links pointing to your site. Backlinks remain one of Google's strongest ranking signals. The audit assesses how many you have, how authoritative they are, and whether any are toxic (spammy or penalised links that could be hurting your rankings rather than helping them).

Competitor analysis benchmarks your site against the businesses ranking above you. It reveals what they are doing that you are not, where they are weaker than you, and where the realistic opportunities lie. This is not about copying competitors; it is about understanding the landscape you are competing in.

User experience and conversion covers how visitors interact with your site once they arrive. Page layout, call-to-action visibility, navigation clarity, mobile usability, and trust signals all affect whether a visitor becomes a customer. Search engines increasingly factor user behaviour into rankings, so a site that frustrates visitors tends to rank worse over time.

What does an audit produce?

This is where the difference between a free automated tool and a professional audit becomes clear.

A free tool (Lighthouse, SEOptimer, or similar) gives you a score and a list of issues. That is useful as a surface-level check, but it does not tell you which issues actually matter for your business, in what order to fix them, or how much effort each fix requires. You get data; you do not get a plan.

A professional audit produces a scored, prioritised report. Each issue is assessed for severity and business impact. The output is not a list of everything wrong; it is a ranked action plan that tells you what to fix first, why that item matters more than the others, and what the expected outcome is.

Good audits also include explanations in plain language. If you have to hire a separate consultant to interpret the report you just paid for, the audit failed at its job.

When does a business need an SEO audit?

There are several situations where an audit provides clear, measurable value.

You have never had one. If your website has been live for more than six months and nobody has systematically reviewed its SEO, problems are almost certainly accumulating. Websites do not stay healthy on their own. Content management systems update, plugins change, pages get added without proper optimisation, and technical debt builds up silently.

Your traffic has plateaued or declined. If organic traffic was growing and then levelled off, or if it dropped and you are not sure why, an audit identifies the cause. The fix might be technical, content-related, or competitive; you cannot know until someone looks.

You are about to redesign your website. A redesign without an SEO audit beforehand is one of the most common ways businesses lose organic traffic overnight. URLs change, redirects get missed, page structure shifts, and rankings disappear. Auditing before the redesign protects what you have already built.

You are investing in SEO but not seeing results. If you are paying for content, link building, or SEO services and the numbers are not moving, an audit can show whether the investment is going to the right places or whether something foundational is broken underneath it all.

You are entering a more competitive market. Expanding into a new region, launching a new service line, or going after higher-value keywords all require understanding where you currently stand relative to the competition.

What an SEO audit does not do

An audit identifies problems and prioritises solutions. It does not fix anything by itself. A 46-point report sitting in your inbox is useful only if someone acts on it.

This is worth stating plainly because many businesses treat the audit as the destination rather than the starting point. The audit tells you what to do. The next step is implementation; either you handle it in-house, hire someone, or work with the same team that ran the audit.

Some issues flagged in an audit take 30 minutes to fix. Others require a developer, a content writer, or a multi-month effort. Part of the audit's value is distinguishing between these so you know what is realistic given your resources.

What is the difference between a free tool and a professional audit?

Free tools are useful for a quick health check. They scan your site automatically and return a standardised report. They are a good starting point if you have never looked at your SEO at all.

However, they have real limitations.

	Free automated tool	Professional audit
Scope	Scans visible technical issues	Covers technical, content, keywords, backlinks, competitors, UX
Prioritisation	Lists issues by type	Ranks issues by business impact and effort
Context	Generic advice	Recommendations specific to your business, sector, and goals
Keyword analysis	Limited or absent	Full keyword gap analysis against search intent
Competitor insight	None	Benchmarked against your actual competitors
Deliverable	Automated PDF or dashboard	Written report with explanation and action plan

A free scan might tell you that your page speed is slow. A professional audit tells you that your page speed is slow on your pricing page specifically, that this page gets 40% of your organic traffic, that fixing two oversized images and removing an unused script will solve it, and that this fix should come before anything else because it directly affects conversions.

That difference in specificity is what separates a tool output from a consulting deliverable.

FAQ

How long does an SEO audit take?

A professional audit typically takes 3 to 8 business days depending on the scope and the size of the site. Basic audits covering core technical and on-page elements are faster. Full audits that include competitor analysis, backlink review, and content gap assessment take longer. Rushing an audit defeats the purpose; thoroughness is the point.

How much does an SEO audit cost?

Costs vary widely. Free automated tools exist at one end. Professional audits for SME websites typically range from €250 to €800 depending on scope and specialisation. Enterprise-level audits for large, complex sites can cost several thousand. The key question is not the price but what you receive: a data export or a prioritised plan with clear next steps. A full breakdown of audit pricing covers this in detail.

Can I do an SEO audit myself?

You can check the basics using free tools like Google Search Console, PageSpeed Insights, and SEOptimer. These will surface obvious technical issues and give you a general sense of your site's health. For a deeper analysis, particularly keyword strategy, competitor benchmarking, and backlink quality, you will need either professional tools (which have their own learning curve and cost) or an experienced auditor. A self-audit is a reasonable first step; it is rarely a complete one.

How often should a website be audited?

For most SME websites, a thorough audit once a year is a reasonable baseline. If you are making significant changes to your site (new pages, redesigns, CMS migrations), audit before and after. Sites in competitive or fast-moving sectors may benefit from a lighter quarterly check alongside the annual deep audit.

What happens after an SEO audit?

The audit gives you a prioritised action plan. The next step is deciding who implements it. Some businesses handle quick fixes in-house and outsource the more technical or content-heavy work. Others hand the entire plan to the team that ran the audit. Either way, the audit is the starting point of the improvement process, not the end of it.

Where to start

An SEO audit gives you clarity. Instead of guessing what might be wrong with your site or which improvements will make the biggest difference, you get a structured answer backed by data. Whether you act on it yourself or bring in help, the audit ensures you are spending time and money on the things that actually move the needle.

If this has raised questions about your own website, an audit is a straightforward starting point. And if you already know what needs fixing, the implementation can be handled for you too.

What Is a SaaS SEO Audit?

Szymon Kokot — Mon, 16 Mar 2026 08:30:00 GMT

If you're running a SaaS product and someone suggests an SEO audit, the first question worth asking is: which kind? A standard website audit will catch broken links, slow page speeds, and missing meta tags. Useful, but it won't tell you whether your organic strategy is actually built to acquire users. SaaS businesses don't sell from a brochure. They sell through funnels, free trials, demo pages, comparison content, and review platforms. A generic audit doesn't know to look at any of that.

In short: A SaaS SEO audit examines not just technical health, but whether your site captures search demand at every stage of the buyer journey, from awareness to signup. It checks what generic audits miss: funnel-stage keyword coverage, JavaScript rendering, comparison page strategy, trial page optimisation, and third-party review platform presence.

What Makes SaaS SEO Different?

Most business websites exist to inform and convert. A SaaS website does that too, but the conversion path is longer, more competitive, and more distributed. Your potential customer might first read a blog post, then search for a comparison ("your product vs competitor"), then check a review on G2 or Capterra, and only then land on your pricing page.

That means the SEO challenges for a SaaS site are structurally different from those of a local business or a services firm:

The funnel has distinct stages with different search intent. Someone searching "what is project management software" is at the top. Someone searching "Asana vs Monday" is in the middle. Someone searching "Asana pricing" is at the bottom. Your site needs content targeting all three and most SaaS sites only cover one or two.
JavaScript rendering is a real concern. Many SaaS marketing sites are built with React, Next.js, Vue, or similar frameworks. If Google can't render your JavaScript properly, your pages might not be indexed at all, regardless of how good the content is.
Third-party platforms carry significant weight. Review sites like G2, Capterra, and TrustRadius often outrank your own site for your product's name. Your presence and optimisation on these platforms is part of your organic strategy, whether you've acknowledged it or not.
Trial and demo pages are conversion-critical. These pages need to rank, load fast, and convert; but they're often afterthoughts from an SEO perspective.

A generic SEO audit doesn't check any of this. It will tell you your page speed and whether your title tags are the right length. It won't tell you that your entire mid-funnel is missing.

What Does a SaaS SEO Audit Actually Check?

A properly scoped SaaS audit covers the same technical foundation as a standard audit: page speed, Core Web Vitals, crawlability, schema markup, mobile usability; but adds layers that are specific to how SaaS products compete in search.

Here's what the additional coverage looks like:

Funnel-stage keyword coverage. The audit maps your existing content against the three stages of the SaaS buyer journey. Are you only ranking for branded terms? Do you have any presence in "vs" and comparison searches? Is there awareness-level content pulling in top-of-funnel traffic? Most SaaS sites discover that one or two stages are virtually empty.

JavaScript rendering and indexability. The audit checks whether Google can actually see your content. This means comparing the raw HTML served to crawlers against the fully rendered page. If key content, headings, body text, internal links, only appears after JavaScript execution, there's a risk that Google is indexing an empty shell. This is one of the most common and most damaging issues on SaaS sites, and it's completely invisible in a standard audit.

Comparison and alternative pages. When someone searches "[your product] vs [competitor]" or "best [category] software", you want to be the one answering that query, not a third party. The audit assesses whether these pages exist, whether they're structured for search intent, and whether they're actually ranking.

Trial and demo page SEO. Your signup flow might be the highest-value page on your site. The audit checks whether trial and demo pages have proper meta tags, schema markup, clear CTAs, fast load times, and whether they're even indexed. Surprising numbers of SaaS sites accidentally block their trial page from Google via robots.txt or noindex tags.

Third-party review platform presence. G2, Capterra, TrustRadius, Product Hunt; the audit checks whether your product is claimed, optimised, and actively managed on the platforms that matter for your category. These listings often rank for your own brand name. Leaving them unoptimised means someone else controls what searchers see first.

Programmatic SEO opportunities. Many SaaS products have natural data assets, integrations lists, supported tools, use-case categories, industry verticals that could generate dozens or hundreds of indexable pages using a template-based approach. Think of how Zapier has a page for every integration, or how Notion has a page for every use case. The audit assesses whether a similar opportunity exists and whether your tech stack supports it.

Blog and content strategy assessment. Is the blog active? Does it link to product pages? Is it targeting keywords that actually bring in potential users, or is it a disconnected content island? For SaaS, the blog is often the primary organic acquisition channel and also the most frequently neglected one.

The Funnel Coverage Problem Most SaaS Sites Have

This is the single most common issue a SaaS SEO audit surfaces, so it's worth explaining in detail.

Most SaaS companies start their content strategy at the bottom of the funnel, branded terms, pricing pages, feature pages. These rank relatively easily because nobody else is competing for your brand name. So from the inside, it looks like SEO is working.

But the middle and top of the funnel are where the real volume lives. The people searching for "best project management tool for remote teams" or "how to manage client projects" are your future customers, they just don't know your product exists yet. If you're not visible for those searches, you're not in the consideration set, and no amount of bottom-funnel optimisation will compensate.

A SaaS audit quantifies this gap. It maps keyword coverage across all three funnel stages and shows you, concretely, where the holes are and what content would fill them. This is where an audit stops being a technical exercise and becomes a growth strategy document.

If you're not sure whether your site has this kind of gap, an SEO audit will flag it, along with every other structural issue worth addressing.

What Should a SaaS SEO Audit Report Include?

A useful SaaS audit report should give you more than a list of red and green indicators. Here's what to look for:

A scored assessment for every check: not just pass/fail, but a calibrated score that tells you how much each issue matters relative to the others.
A prioritised action plan: ranked by impact, not alphabetical order. The first item on the list should be the thing that will move the needle most.
Funnel coverage analysis: a clear view of which stages you're winning and which are empty.
Competitor context: how your organic presence compares to the two or three competitors your prospects are actually evaluating you against.
SaaS-specific recommendations: not generic advice that could apply to any website, but recommendations that reflect how your product competes in search.

A report that only tells you your page speed score and that you're missing some alt text is not a SaaS SEO audit. It's a generic technical check with a different label.

FAQ

How is a SaaS SEO audit different from a standard SEO audit?

A standard audit focuses on technical health, on-page elements, and backlinks. A SaaS audit adds funnel-stage keyword analysis, JavaScript rendering checks, comparison page assessment, trial/demo page SEO, review platform presence, and programmatic SEO opportunity scanning. The technical layer is the same, the strategic layer is fundamentally different.

Does every SaaS company need a specialised audit?

If your product competes for search traffic, and most SaaS products do, whether they've invested in it or not, then yes. A generic audit will miss the issues that matter most for how SaaS buyers actually find and evaluate software. The funnel gaps and JS rendering issues alone are worth the specialised scope.

How long does a SaaS SEO audit take?

Typically 5–10 business days depending on the size of the site and the tier. A basic audit covering the core checks is faster. A full audit including competitor analysis, keyword gap mapping, and programmatic SEO assessment takes longer, but produces a strategy document, not just a checklist.

What should I do after receiving the audit?

Start with the top three items on the prioritised action plan. These are chosen for maximum impact with reasonable effort. If you want help implementing the findings, that's the natural next step, but the audit is designed to be actionable whether you implement it yourself or bring in help.

Closing

A SaaS product deserves an SEO audit that understands how SaaS products actually compete in search, through funnels, comparisons, review platforms, and content, not just page speed and meta tags. If you've been considering an audit, make sure it's scoped for what your product actually needs. And if you already know what needs fixing, the audit is still the fastest way to confirm you're prioritising the right things.

Illucrum's SaaS audit is built around the funnel model above, checking keyword coverage at each stage, JS rendering, review platform presence, and programmatic opportunities alongside the full technical foundation. → See SaaS audit details | → View pricing

A "perfect" data structure

Szymon Kokot — Thu, 29 Jan 2026 08:00:33 GMT

Algorythms, data structures and maths. Those are the three legs of the tripod that holds programming. Today, let’s focus on data structures. You know how each one has it strengths and weakneses, each one has it’s own use cases. A “perfect” data structure should only have strengths and no weakneses, but it should also be useful in all situations. Which is of course ridiculous. There is just no way you can have a data structure that would be able to replace a regular list, just the same as it would be able to replace a tree. Although it’s worth mentioning that a binary tree can be implemented with an array. In this article, I’ll explore the posibilities of coming closer to the “perfect” data structure by trying to design one that would behave like a list while assuring a O(1) complexity for all relevant operations.

Algorythmic complexity

Although this article is not about complexity, let’s briefly explain what it is about. The complexity of an algorythm is used to predict how an algorythm will perform depending on the input size. This is very important for data structures that can hold millions of entries. So for example, if we assume a simple node list of which we only have direct access to the first node, if we want to add a new item to it at the beggining, no matter how long the list is, it will always cost the same ammount of resources, which is very good. But if we want to add a new item at the end, we would need to iterate through the whole thing. In this case the time needed to add this new item would be roughly directly proportional to the length of the list.

In some other situations, things are not always that simple. Sometimes the resources needed don’t depend only on the size of the input. Which is very common for sorting algorythms, for example. In those situations, normally the worst case scenario is the most relevant. And this is where the big-o notation comes in, as a way to represent the complexity of an algorythm in it’s worst case scenario. From the previous example of the node list, adding an item at the beggining presents constant complexity, which is O(1). This basically means, it always needs the same amount of resources, no matter how long the list is. Adding an element at the end, presents linear complexity, which is O(n), where n represents the lenght of the list.

The “perfect” list

Goals

First, let’s define the goals that the list I’m trying to describe should meet. The goal is to have a data structure on which we can perform these operations with O(1) complexity:

Retrieving any element given it’s index
Adding a new element on any position
Removing any element

As we can retrieve any element given it’s index, there should be of course no problem with iterating the list. So this goals should really cover it all.

Restrictions

This list will have one very important restriction. It will have a set maximum size. This is sadly necessary, I don’t see the possibility of avoiding this restriction.

Structure

It’s clear to me, that in a way, what I’m trying to achieve is to create something like an “indexed hash table”. This seems to be the most promising approach. To start with, let’s set the maximum size to 4 elements. This should give as a list big enough to see more clearly how it works, but also small enough to make it quite simple to simulate. The list will have the following components:

The buckets: there should be as many buckets as many elements the list can hold at the same time. In our case it will have 4 bucket. Each will have it’s own identification binary number assigned to it, so we will have buckets 00, 01, 10 and 11. The buckets will really behave like wrappers of the elements stored in the list, and they themselves will be stored in a hash map, using their identifiers as keys. This will assure that we can access any element given it’s bucket number with constant complexity.
A size variable: there should be a variable to keep track of the current size of the list. Nothing special about it.
The state number: the buckets hold the elements, but it’s important to have a way of keeping track of how the buckets are odered. As our list can hold at most 4 buckets, and each has a 2 bits long key, an 8 bit long number will be used , which will contain the four buckets identifiers concatenated, in the order in which the buckets are ordered. Let’s consider the least significant two digits represent the first bucket, the two most significant digits represent the last bucket on the list.

The size variable, is there mostly to make sure the inputs are valid. Most of the magic will happen with the state number, as by manipulating it the order of the buckets will be read and written.

So for example, let’s say we start with a list like this:

State number	Size	Elements ordered from left to right
00 01 10 11	3	1 - 2 - 4

This would mean we would have a list with three elements, bucket 11 holding value “1“, bucket 10 holding value “2“ and bucket 01 holding the value “3“, while the bucket 00 remains empty. So now let’s say we want to add a “3“ between the “2” and the “4”. We would put the value “3” into the empty bucket 00, and place it between the buckets 01 and 10. This would give us:

State number	Size	Elements ordered from left to right
01 00 10 11	4	1 - 2 - 3 - 4

Now, every bucket has a value attached to it. If we wanted to remove the first value (index 0), we would empty the bucket 11, and move it to the “end”. So our list should look like this:

State number	Size	Elements ordered from left to right
11 10 00 10	3	2 - 3 - 4

Retrieving any element given it’s index

This is fairly simple. It’s sufficient to first check if the given index is allowed. Obviously you can never get the third element from a list with only two elements in it. For that we have the size variable. Once the given input is checked, we need to check which bucket is located at the indicated index. We can do that using the following formula:

$$b = {s \bmod 2^{2*(i+1)} \over 2^{2*i}}$$

Where b is the bucket number, we of course ignore any decimals; s is the state number and i is the index.

This way, no matter how long the the list is, we can retrieve any element by “just“ calculating the proper bucket. So it presents O(1) complexity.

Adding a new element anywhere

First things first, we of course need to validate the input. After that we should get the last bucket, which will be always empty if the list is not full. This can be done using the previous formula and giving the index the value of 3. Once we have the bucket we can set it’s value. The we need then to modify the state number accordingly. To do so, we can use the following formula:

$$s\prime=s mod 2^{2i} + b * 2^{2i} + {{s/2^{2i}} * 2^{2(i+1)}}$$

Where s’ is the new state number, we only care about the binary eight least significant digits; s is the old state number, i is the index and b is the bucket we are using.

And of course we need to update the index.

This time it’s not as simple as before, as we have to perform two calculations, not just one. But still the algorythm is independent from the lenght of the list, giving it the desired complexity.

Removing any element

By now it should be more or less clear how this will look like. First we need the make sure that the index we are given is valid. Then, we will retrieve the bucket for that index in the same fashion that we did before, so we can empty it. And then we can use the following formula to put the bucket at the “end”:

$$s\prime=(s-smod2^{2*(i+1)}/2^2)+(smod2^{2i})+b2^6$$

Where s’ is the new state number, s is the old state number, i is the index and b is the bucket.

And last but not least, we of course need to update the index.

And also in this case, it’s enough to perform two calculations to remove any element with complexity O(1).

Final thoughts

This list idea, surely could be optimized. For example, as the number of states is finite, no calculations are really needed. It would be enough to map the whole thing, basically making a finit state machine. Nevertheless, this solution has a big drawback. And that is the maximum length.

Nowadays, we are using 64 bit processors. The biggest list could have at most 16 elements, each with a 4 bit id, which gives as a state number of 64 bits long. This would allow us to perform the calculations easily. Surely it’s possible to do maths with numbers longer than 64 bits on 64 bit processors, but something tells me that this wouldn’t really work fast enough. But maybe I’m mistaken.

On the other hand, designing finite state machines should always work quite well, but that would be very memory heavy. And of course it would also take a lot of time to design and then implement. But maybe it is worth a try?

Class loading and linking in Java

Szymon Kokot — Tue, 16 Dec 2025 08:00:08 GMT

As Java is an object oriented language, the topic of what classes actually are and how are they loaded by the JVM, is one that really goes to the heart of things. In this article, we will explore in more detail not only what is visible to every Java developer, but also what is hidden under the hood of the JVM.

Class loaders

Let’s keep it relatively simple for a while, and let’s start with something more “tangible“ for a regular developer like tha class loaders. Class loaders, most often are Java classes extending java.lang.ClassLoader, which are responsible for loading other classes. To be more precise, they load the bytecode of a class, then they leave it to the JVM to do the linking, basically reading and analyzing the bytecode to create a new class.

Hierarchy

By default, a Java application has three main class loaders:

Bootstrap loader: The first class loader to run, it is used to get the absolute basic system loaded - essentially java.base. It is not a Java class, it’s written in native code and it doesn’t perform any checks on the classes it loads, so for security reasons it doesn’t have a representation in Java (as a class or class instance, for exmaple), and for this reason it’s refered as null.
System loader: When the bootstrap loader is done loading the core of the system, the systen loader loads the platform modules that the application depends on. This class loader is a Java, as we said earlier, extending java.lang.ClassLoader. Not only it’s accessible through a static function (ClassLoader.getSystemClassLoader()), it can also be set when starting the application. So if you want to run your app with a custom system class loader, you just need to add to your command the -Djava.system.class.loader=my.custom.ClassLoader flag.
Application loader: The last loader to run, is the most widely used. It’s basically the one that loads the application itself. It is also an instance of a Java class, just like the system class loader.

Delegation

Generally speaking, a class in Java can’t be loaded twice by the same class loader, but it can be loaded multiple times by different class loaders. This is one reason why there is a hierarchy of class loaders. And the second reason, is delegation, which purpose is precisely to avoid the same class to be loaded twice. A properly implemented class loader always delegates that task to it’s parent (the class immediately above in the hierarchy) before attempting to load it by itself. So, let’s say we want the application class loader to load the class A.

The application loader delegates the task to the system class loader.
The system loader delegates the task to the bootstrap class loader.
The boostrap class loader has no parent, so it tries to load A and if it is able to do so, it returns it to the system loader.
When the system loader receives A from its parent, it just passes it through to the application loader. If not, it tries to load A by itself and return it to the application loader.
If the application loader receives class A from the system loader, there is nothing more to do. If it doesn’t, then the application loader is the last one to give it a try.

Of course, you may add your own, totally custom class loaders. And those, although it would be a good thing if they followed delegation placing themselves beneath the app loader, in some cases they are implemented to break that rule on purpose.

Initiating and defining loaders

A class loader is said to be the defining loader of a class A, if A was actually loaded by that class loader. So if the app loader was the one that started the loading process, but due to delegation it was the bootstrap loader that actually found and loaded A, then the bootstrap loader is the defining loader of A.

A class loader is said to be the initiating loader a class A, if the class loader is either the one that started the process that loaded A or is also the defining loader of A. This means a class A can have two initiating class loadeds. In the previous example, the initiating class loaders would be both the app loader and the bootstrap loader.

This is quite important, we will talk about it later on.

JVM

Now that we know what class loaders do, let’s focus on what the JVM does. This is where the fun really begins. This part is maybe a little bit more abstract as I will try to explain the concepts without getting into the details of specific implementations. The JVM is the responsible for making sure everything is secure and optimized so there is no errors and no unnecessary calls to the class loaders.

Linking

When a class loader finds the bytecode of the class to be loaded, the JVM takes over and starts creating it’s own representation of the class. This is refered to as linking and it is done in four steps:

Verification: First, the JVM needs to make sure that the bytecode loaded is a valid representation of a class and that it’s code is well behaved.
Preparation: Once the bytecode is verified, the JVM starts allocating and getting the static variables of the class making them ready to initialize.
Resolution: Now, before initializing the class, the JVM tries to resolve the supertype and implemented interfaces if any of the class being linked. If the JVM is not able to resolve them, it first tries to load and link them before continuing.
Initialization: In this step, it’s the first time the bytecode of the class is actually being executed. In this step, all static fields are initialized as well as any static initialization blocks are run. When this is done, the class is ready to be instantiated.

Klasses

The representation of a class used by the JVM is the “klass” and it is not a Java class, they are stored in the metaspace. Each klass is unique, and all instaces of the class it represents, are created based on of that klass. Some of the information it contains is accessible from Java through the java.lang.Class, which instances are Java representations of different classes. This is what makes reflection possible, but that is a topic for a different article.

In the metaspace, klasses are not just stored in any way, they are organized. Each class loader has a dictionary assigned to it. Each klass is stored in the dictionary of it’s initiating loader. And it’s also important to point out, that each klass contains information about it’s defining loader.

Loading and linking process

Let’s consider a class A, which has been defined by the app class loader. And let’s also consider a class B that is being referenced from A.

When B is referenced while executing A, the JVM finds out from A’s klass which is it’s defining class loader, in our example it’s the app loader.
The JVM now check in the app loader’s dictionary if contains B. Which we could also express as, the JVM checks if the class loader already is an initiating loader for B. If it is, the JVM grabs the B klass and continues executing A.
But if the app loader is not an initiating loader of B, the JVM asks the app loader to load B.
Now all delegation steps explained before follow.
When B get’s loaded, it’s klass representation gets stored inside it’s initiating class loaders dictionaries for future reference.

Conclusion

Klasses are the representation of Java classes in the JVM. They are not only identified by their name, but also by their defining class loader. This is the reason why a class can be loaded multipple times by different class loader and get treated as completely different classes. Which is the reason why delegation and class loaders hierarchy is needed. Klasses are stored in the metaspace in a dictionary assigned to it’s initiating loaders, which helps the JVM to improve performance in not having to call the class loader each time some class gets referenced.

Java Hot Code Reloader

Szymon Kokot — Thu, 11 Dec 2025 08:00:34 GMT

Without a doubt, Java is a wonderful language. It's fast, strongly typed, has C-like syntax, basically everything I like in a programming language. And also it has some other useful features like being safe or platform independent. But it has one drawback. And it is that every small change in code needs a application restart to take effect. This can be quite frustrating.

Of course, it isn't true for all projects, because this issue can be solved using different tools. But all of them have one thing in common, they use some kind of trick. The aim of this article is to explore the problem of hot code reloading in Java, and explain some possible solutions, including the one I used in my own project: the Java Hot Code Reloader.

Class loading

How are classes normally loaded by the JVM? This is quite simple, class loaders are used. The class loaders in the JVM are a separate very interesting subject, worth of exploring on its own. Here we will only rapidly go through the basics we need.

Can classes get loaded twice?

First, it's good to know that each class, can't be loaded twice by the same class loader, but it can be loaded twice by two different class loaders. Loaded classes are not identified internally only by their names, but also by the class loader that defined them.

Class loader hierarchy

In a normal Java application, there are three class loaders:

Bootstrap loader: first class loader; represented by null, it is not accessible in any way from Java. It is used to get the absolute basic system loaded - essentially java.base.
System loader: second class loader in the hierarchy, it can be accessed calling ClassLoader.getSystemClassLoader(). This loader loads the rest of the platform modules that the application depends upon. We can set a custom system class loader by running the java application with the -Djava.system.class.loader=com.custom.CustomClassLoader flag.
Application loader: the last class loader in the standard hierarchy, it's the most widely used in the application.

Loading a class

When a class is to be loaded the loadClass method of a class loader is called. A correctly implemented loadClass method follow these steps:

Calls findLoadedClass method. In the end, it's a native method, that searches if the target class has been loaded before. If it wasn't, we continue.
It calls the loadClass method of it's parent (the class loader immediately above in the hierarchy), to avoid loading the same class twice from different class loaders.
If the parent was unable to load the target class, the class loader calls its own findClass method, which attempts to find the target class. If it fails, the loader throws a ClassNotFoundException.

How the loadClass method is called?

The loadClass method can be called in two ways:

It can be called manually, explicitely.
It can be called automatically by the JVM. But there's a catch. Remember the findLoadedClass method? Each class loader has it's own "cache", where all classes loaded by that class loader are saved. To save time. The JVM only calls the loadClass method only if it is unable to find the class in the class loaders cache.

Instrumentation

So, where is the problem? Well, the problem is that Java doesn't really allow overriding classes, unloading them so they can be loaded again, or loading the same class twice. An attentive reader may now say something like "wait, didn't you say a class can be loaded twice by differnet class loaders?". And to you, dear reader, I answer: yes. Absolutely yes. I will explain this matter later on, in the "Some possible solutions" section.

Even though you can't reload classes, there is something Java gives you: Instrumentation. An what does Instrumentation give us?

Redefinition

Instrumentation gives us redefinition. You can redefine classes, although there are limitations. The class structure needs to remain the same. No new methods, no removing methods, no renaming methods, non of the same to fields. It's a nice tool, but quite limited in a development environment.

Transformers

Transformers can be very useful too. They allow you to intercept the bytecode of a class before it is loaded or redefined. Having the bytecode, the content of a compiled class, you have full control over the class that is being loaded. You can change it's behavior, add custom methods, or even create a completely new class from scratch.

Some possible solutions

So it's quite clear now, that Java offers a very well designed environment, that works very well with a normal setup. But it doesn't really allow reloading classes. It allows redefinition, but that is not enough. So, what tricks can be used to solve this?

Custom JVM

First let's mention the obvious one. Which basically is, you don't like how Java works? Just create you own version tailored specially for you! Easy, right? You don't have to create a whole new language from scratch, just replace a small part of its environment, one of the parts that makes Java so safe. After all, if it is to be used only in development, not in production, that's a perfectly valid solution. And it is used for example by DCEVM.

Replacing away class loaders

As promised, the complete answer to the attentive reader. Yes, you can load the same class (or different versions of the same class) by two differnt class loaders with no problems. But that would mean getting rid off your original class loader, and creating a new one which would have to load all classes all over again. After all, if you have a class A, that references another class B, you modify B and load it with another class loader, class A keeps referencing the class B loaded by the first class loader. So you have to load A again too, so it references the new version of B.

It is still a solution and it is actually used by some tools, like Spring Boot DevTools.

JHCRs solution

And what solution did I find? JHCR uses a double approach. At first, it tries using redefinition. When that is not possible, things get a little more interesting. First, lets see what elements are involved:

Custom class loader
Custom cache memory to save already loaded classes
A transformer

Now, lets say there is a Class A:

Before loading any class, a transformer intercepts its bytecode, modifying it in a way, each call to a constructor of any class, explicitely calls the loadClass method of the custom class loader.
A hasn't been loaded before, so the loadClass method of my custom class loaders gets called normally.
It finds the class and saves it in a custom cache of the class loader (although there is no way of not saving the class in the default cache).
When the A class gets modified, a file watcher gets its new bytecode and changes the name of the new class version to A1.
Then the custom cache gets modified, so next time the loadClass method gets called for A, A1 is returned instead.
Because each constructor call has been modified forcing an explicit call to the loadClass method of our custom class loader, the default cache is never really used and from now on A1 is returned and instanced where needed instead of A.

Of course, this way, changes to A do not apply for already existing instances of A, but it works like a charm for any new instances. And that is how the second version of the JHCR works.

Conclusion

Hot code reloading is not a trivial issue in Java. But it can be done using different tricks, and everyone comes with its own problems. This is what makes the this matter so interesting and complex. All the things that were briefly mentioned here, are definitely worth of investigating on their own: class loaders and delagation, the Instrumentation API, JVM internals, bytecode manipulation. And there are things that were not mentioned for the sake of simplicity, like reflection, which also plays an important part in making JHCR work.