In short: A full website SEO audit covers technical health, on-page elements, keyword performance, backlinks, competitors, local presence, conversion signals, and AI search visibility. All 52 checks below can be run with Google Search Console, PageSpeed Insights, Chrome DevTools, a free crawler, and a handful of free validators.

What do you need before you start?

Everything here can be done on free tools. Two of them are not optional: without verified Google Search Console access you cannot complete roughly a quarter of the checks, and without Google Analytics you cannot complete the engagement checks at all.

Open a spreadsheet before you open a tool. Four columns: check number, finding, evidence (a URL, a number, or a screenshot), and severity. Fill it as you go rather than at the end, because by check 40 you will not remember what check 6 turned up.

One more decision to make now. Pick your sample pages and use the same ones throughout: the homepage, your two most commercially important pages, one blog or informational page, and the contact page. Auditing the homepage alone tells you almost nothing, because the homepage is usually the one page that got attention.

Section 1: How do you check technical SEO?

Technical checks come first because everything downstream depends on them. There is no point rewriting a title tag on a page Google has decided not to index.

1. Page speed, mobile and desktop

Run each of your five sample pages through PageSpeed Insights twice, once with the mobile strategy and once with desktop. Record both Performance scores. Judge the site on the mobile figure; it is almost always the lower of the two and it is the one that matches how Google crawls.

Record: mobile and desktop score per page, plus the top three opportunities listed for each.

2. Core Web Vitals

From the same reports, record LCP, INP, and CLS. Use the field data at the top of the report, which comes from real Chrome users over the previous 28 days, in preference to the lab data below it. If the field section is missing, the site does not have enough traffic to appear in the Chrome UX Report; note that, and treat the lab numbers as indicative only. Then open Search Console, Experience, Core Web Vitals for the site-wide view.

Thresholds: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1.

Record: the three values per page, whether they are field or lab, and the URL counts in each Search Console status band.

3. Mobile friendliness

Open DevTools, switch on device emulation, and set the viewport to a common phone size such as 390 by 844. Load all five sample pages. Look for horizontal scrolling, content wider than the viewport, text too small to read without zooming, and navigation or forms that break. Check tap targets on the primary navigation and main buttons; Google's guidance is 48 by 48 CSS pixels with 8 pixels of spacing.

Record: per page, whether the layout holds, plus screenshots of anything broken and a list of undersized tap targets.

4. HTTPS and SSL certificate

Confirm the site loads over HTTPS. Request the HTTP version and watch the DevTools Network tab to see whether it redirects to HTTPS in a single hop. Click the padlock for certificate issuer, coverage, and expiry date. Run the domain through SSL Labs for a configuration grade; the scan takes a couple of minutes.

Record: redirect behavior and hop count, certificate expiry, issuer, SSL Labs grade.

5. XML sitemap

Open yourdomain.com/sitemap.xml. Confirm it is well-formed XML and returns 200. Sample 15 to 20 of the URLs listed and check each one returns 200, is the canonical version, and is not set to noindex. Confirm the sitemap excludes admin pages, cart or checkout pages, thank-you pages, and parameter URLs. Then compare the URL count against Search Console, Indexing, Sitemaps.

Record: URL count, number of sampled URLs failing and why, Search Console discovered count, last read date.

6. Robots.txt

Open yourdomain.com/robots.txt in a browser and read the whole file. Confirm it returns 200 rather than a 404. Look for Disallow: /, which blocks the entire site, and for any rule that catches service pages, the blog, or the CSS and JavaScript needed to render pages. Confirm a Sitemap: directive is present and points at a live URL.

Record: status code, full file contents, any Disallow rule affecting content, whether the sitemap is declared.

7. Canonical tags

On each sample page, view the source and find <link rel="canonical">. Confirm it exists, uses an absolute HTTPS URL, and points at the page itself. Then test the duplicate access paths: with and without a trailing slash, with a tracking parameter appended, and the print version if one exists. Each should either return the same canonical or redirect.

Record: per page, whether the canonical is present, self-referencing, and absolute; plus any duplicate path that returns 200 with no canonical.

8. Structured data

Run the homepage and one URL of each page type through the Rich Results Test. Record the schema types detected, the error count, and the warning count. Then run the same URLs through the Schema Markup Validator, which checks against schema.org rather than only Google's supported rich result types. At minimum you are looking for Organization on the homepage and a page-type schema elsewhere.

Record: types detected per page type, errors, warnings, and any page type with no structured data at all.

9. Crawl errors and index coverage

In Search Console, go to Indexing, then Pages. Record the Indexed and Not indexed totals. Open the "Why pages aren't indexed" breakdown and record the count against each reason, paying attention to Crawled - currently not indexed, Discovered - currently not indexed, Soft 404, Excluded by noindex tag, and the duplicate reasons. Then confirm your commercially important pages appear in the indexed set.

Record: indexed count, not-indexed count, the full reason breakdown, and any key page found in the not-indexed set.

10. Redirect chains and 4xx errors

Crawl the site with Screaming Frog. Sort by status code and flag every 4xx and 5xx that is linked from somewhere on the site or listed in the sitemap. Then open Reports, Redirects, Redirect Chains; anything passing through more than one hop is a chain. Check whether permanent moves use 301 rather than 302, and flag any URL redirecting into a loop.

Record: 4xx URLs with the pages that link to them, 5xx URLs, each chain with its hop count, and any 302 used for a permanent move.

11. Duplicate and thin pages

In the crawl, use the duplicate detection on titles, meta descriptions, and H1s to find pages sharing identical elements. Then look at the word count column and open anything unusually short. The question is not whether a page hits a number; it is whether the page does its job. A 200-word contact page is fine. A 200-word service page competing against 1,500-word competitor pages is not.

Record: pages sharing duplicate titles or descriptions, and a list of pages that are thin relative to what the query requires.

12. Hreflang

If the site is monolingual, mark this N/A and move on. Otherwise view the source on a page that exists in several languages and record the <link rel="alternate" hreflang="..."> set. Check the language and region codes are valid, that each page references itself, that pairs are reciprocal, and that an x-default exists.

Record: hreflang set per sampled URL, missing reciprocals, invalid codes, broken target URLs.

Section 2: How do you check on-page SEO?

On-page work is the cheapest part of SEO to fix and the easiest part to get wrong at scale, because most of it is generated by a template that nobody has looked at since launch.

13. Title tags

Export the title column from your crawl. Check three things: every page has one, no two pages share one, and each describes the specific page rather than the brand. Length matters mainly because Google truncates and rewrites long titles, so aim for roughly 50 to 60 characters. Front-load the term the page is actually competing for.

Record: missing titles, duplicate titles, titles over 60 characters, and titles that name only the brand.

14. Meta descriptions

Export the meta description column. Check for missing, duplicated, and auto-generated descriptions on your commercially important pages. Be realistic about what this is worth: Google rewrites the majority of meta descriptions it is given, and the tag is not a ranking factor. It is a click-through asset. Write them properly for the top pages and do not spend a week rewriting them site-wide.

Record: missing and duplicate descriptions on key pages only, and whether each key page's description says something specific.

15. Heading structure

For each sample page, use the crawl's H1 and H2 columns or read the source directly. Check there is exactly one H1, that it describes the page, and that headings descend in order without skipping levels. Then read the H2s on their own; they should form a readable outline of the page. Generic H2s such as "Our approach" and "Why choose us" tell a reader and a search engine nothing.

Record: pages with no H1 or multiple H1s, hierarchy breaks, and the H2 outline for each key page.

16. Image alt text

In the crawl, open the Images tab and filter to "Missing Alt Text". Then open a sample page and read the alt attributes that do exist. You are checking for three failure modes: missing entirely, filename dumped in as alt text ("IMG_4471.jpg"), and keyword stuffing. Decorative images should carry an empty alt="" rather than a description.

Record: count of images missing alt text, count with filename or stuffed alt text, and whether decorative images are correctly marked empty.

17. Content quality and depth

Read your key pages properly, as a prospective customer would. Ask whether the page answers the questions someone arriving from search would have, whether it contains anything specific (numbers, process detail, examples, constraints), and whether the reader would have to go elsewhere to actually understand the topic. Word count is a symptom, not a target; a thin page is usually short, but making it longer does not make it good.

Record: per key page, a one-line judgement on completeness and a list of the questions it fails to answer.

18. Internal linking

In the crawl, look at the Inlinks column for each page. Check that key commercial pages receive multiple internal links from relevant content rather than only from the header and footer. Sample the anchor text used and note how much of it is "read more", "click here", or the bare URL. Then use Reports, Orphan Pages (this requires connecting the Search Console API before crawling) to find pages nothing links to.

Record: inlink count for the top ten commercial pages, anchor text patterns, and the orphan list.

19. URL structure

Export the URL list and review 30 or so across page types. You are looking for lowercase characters, hyphens rather than underscores, absence of avoidable parameters, readable slugs, and sensible length. The real finding is usually inconsistency: some URLs hyphenated and some not, some with trailing slashes and some without, blog posts with dates in the path and service pages without.

Record: the conventions in use per page type, and every place they conflict.

20. Open Graph and social tags

View the source on each page type and record whether og:title, og:description, og:image, og:url, og:type, and the Twitter Card tags are present. Confirm the og:image URL actually resolves and is at least 1200 by 630 pixels. The Facebook Sharing Debugger will render the preview and list missing tags.

Record: tag presence per template, image dimensions, and any templates sharing one generic og:image.

21. Content freshness

In Search Console, use URL Inspection on your key pages to see when Google last crawled each one. Separately, look at the site itself: when was the last blog post published, do case studies reference work from three years ago, do service pages describe an offer you no longer sell? Freshness is not a virtue in itself. Stale and wrong is the problem.

Record: last crawl date per key page, last publish date on the blog, and a list of pages containing outdated claims.

22. Keyword placement

For each key page, work out what it is actually trying to rank for, then check whether that phrase appears in the title, the H1, the first paragraph, and at least one H2. This is a coverage check, not a density calculation; keyword density targets are folklore and have not been a meaningful signal for years. What you are looking for is a page that never states plainly what it is about.

Record: per key page, the intended query and which of the four positions it appears in.

If working through this is more time than you want to spend on your own site, an SEO audit covers the same ground and arrives prioritized.

Section 3: How do you check keyword performance?

Everything so far has been about the site. This section is about what the site has actually earned. All of it comes out of Search Console.

23. Ranking keywords overview

Go to Performance, Search results, and set the date range to the last three months. Switch on all four metric columns: clicks, impressions, CTR, and average position. Sort by impressions and read the top 20 queries. The question to answer is whether these are queries from people who could buy something, or whether they are accidental.

Record: total clicks and impressions, the top 20 queries with position and CTR, and how many of them are commercially relevant.

24. Striking distance keywords

In the same report, add a position filter for greater than 3 and less than 21, then sort by impressions. These are queries where the site already ranks but sits below the click-through cliff. Cross-reference each with the page that ranks for it, using the Pages tab.

Record: the striking distance list with query, position, impressions, and the ranking URL for each.

25. Local keyword visibility

Skip this if the business does not serve a geographic market. Otherwise, filter queries containing your city or region name and note the positions. Then run three or four service-plus-location searches manually in an incognito window and note whether the site appears in the local pack, in the organic results, or nowhere.

Record: local query list with positions, plus local pack placement for each manual search.

26. Search intent alignment

Take your top 10 non-branded queries and search each one in an incognito window. Look at what is ranking: are the top results service pages, blog posts, comparison articles, or directory listings? Then compare that with the page type you have pointed at the query. A service page competing in a results set made entirely of guides is misaligned, and no amount of on-page work will fix it.

Record: per query, the dominant result format, your page type, and whether they match.

27. Keyword gap against competitors

Take the competitors you identify in check 34. Search 10 to 15 of your core service terms manually and record who ranks where. Where a competitor ranks and you do not appear at all, open their ranking page and note what it is: a dedicated service page, a location page, a guide, a comparison. That is the gap, and it is usually a page type rather than a keyword.

Record: query-by-query rankings for you and each competitor, and the page types they have that you do not.

28. Branded versus non-branded split

In the Performance report, filter queries containing your brand name and record the clicks. Then invert the filter to exclude the brand and record the clicks. Calculate the split. A site where 90% of organic clicks are branded is not being found by anybody new; search is working as a switchboard for people who already know you.

Record: branded clicks, non-branded clicks, and the percentage split.

Section 4: How do you check the backlink profile?

Search Console's Links report is limited compared with a paid backlink tool, but it is accurate about your own site, which is what matters here.

29. Referring domains

Go to Links, then Top linking sites. Record the total number of linking sites and scan the list. What you want to know is whether links come from a spread of real, relevant sites, or whether the count is inflated by one directory network that has syndicated the same listing 40 times.

Record: total linking sites, total external links, and the top 20 linking domains with a note on what each one is.

30. Toxic and spammy links

Work through the linking domains list and open anything you do not recognize. You are looking for link farms, scraped content sites, foreign-language pages unrelated to the business, and adult or gambling sites. Most sites have some of this and it is usually harmless; Google ignores the majority of low-quality links. Record it rather than panicking about it.

Record: the list of suspicious domains with a note on what each one appears to be.

31. Anchor text distribution

Open Links, then Top linking text. Record the breakdown across four buckets: branded (your company name), exact-match commercial phrases, generic ("here", "website", "read more"), and bare URLs. A natural profile is branded-heavy. A profile dominated by exact-match commercial anchors usually means somebody bought links.

Record: the anchor list with an approximate percentage per bucket.

32. Link gains and losses

Search Console shows a snapshot, not a trend, so this check depends on having a previous record. If you have one, compare the referring domain count and the top linking sites list against it and identify anything that has disappeared. If you do not, this audit becomes the baseline. Write the numbers down and date them.

Record: current referring domain count with today's date, and any domains lost since the last recorded count.

33. Competitor link gap

Run your domain and each competitor domain through SEOptimer and record the domain strength figure for each. This is a relative indicator, not an absolute measure, and it only means anything when the same tool is used consistently across all the domains. Calculate roughly how far behind or ahead you sit.

Record: domain strength per domain, and the approximate gap to the strongest competitor.

Section 5: How do you check competitors?

Four checks, all manual, all done in an incognito window so your own search history does not distort the results.

34. Identify the top three organic competitors

Search three to five of your primary non-branded service terms. Note which domains appear in the top five consistently. These are your organic competitors, and they are frequently not your business competitors; directories, marketplaces, and national publishers often occupy the results a local firm is trying to rank in.

Record: the domains that recur, with the queries each one ranks for.

35. Compare authority

Using the domain strength figures from check 33, place your site alongside the three competitors. The point of this number is not accuracy. It is calibration: it tells you whether you are trying to overtake sites in roughly your own weight class or sites with ten years and a thousand referring domains on you.

Record: the four figures side by side, and which competitors are realistically catchable.

36. Top pages comparison

Open each competitor site and map their page inventory: how many service pages, whether they have location pages, whether they have comparison or pricing pages, how much of the site is blog. Compare against your own inventory. Page types you lack entirely are the clearest opportunity in the whole audit.

Record: a page-type inventory for each competitor and for your own site, with the differences highlighted.

37. Content depth against competitors

Take the single query that matters most to you, open the top three ranking pages, and read them. Note what they cover that your equivalent page does not: pricing, process, timelines, objections, FAQs, proof. This is a reading exercise, not a word-count exercise, and it usually produces the most actionable list in the audit.

Record: per competitor page, the sections and specifics they include that yours omits.

Section 6: How do you check local SEO?

Skip this section entirely if the business does not serve customers in a defined geographic area. For everyone else, the local layer often produces more revenue per hour of work than anything in section 1.

38. Google Business Profile

Open the profile and go through every field: name, primary category, secondary categories, address, service area, hours including holiday hours, phone, website URL, description, services or products, and attributes. Count the photos and note the date of the most recent one. Check whether the primary category matches what you actually want to rank for; this is the single most influential field on the profile.

Record: completeness field by field, primary and secondary categories, photo count, date of the last post or photo.

39. NAP consistency

Find the name, address, and phone number everywhere they appear on your own site: footer, contact page, about page, location pages, and inside any schema markup. Compare them character by character against the Google Business Profile. Variations such as "Street" against "St", a different suite number format, or an old phone number are the finding.

Record: every on-site instance of NAP with its exact formatting, and each place it differs from the profile.

40. Local citations

Run the business name and location through Whitespark's free citation finder and note which directories list you. Then search "business name" "city" in Google to catch listings the tool missed. For each listing found, check the NAP matches. For each major directory missing, add it to the action list.

Record: directories listing you with NAP accuracy noted, and the top five relevant directories where you are absent.

41. Reviews

On the Google Business Profile, record the star rating, the total review count, and the date of the most recent review. Then check how many reviews have an owner response. Compare all four figures against the three businesses currently in the local pack for your main service-plus-location query, which is the only comparison that matters.

Record: rating, count, most recent review date, response rate, and the same four figures for each local pack competitor.

42. Local schema

Run the homepage and contact page through the Rich Results Test and look for LocalBusiness markup or one of its subtypes. Check which fields are populated: name, address, telephone, openingHoursSpecification, geo, url, and sameAs. Confirm the values match the NAP recorded in check 39.

Record: schema type used, fields present, fields missing, and any value that contradicts the site or the profile.

Section 7: How do you check UX and conversion?

Rankings that do not convert are an expensive hobby. These four checks are quick and they change how you prioritize everything above.

43. Calls to action on key pages

Load each key page at a mobile viewport with a clean session. Ask what the single next action is, whether it is visible without scrolling, and whether the button text says what happens next. "Learn more" is not an action. Then count the competing calls to action on the page; three different offers means no offer.

Record: per key page, the primary action, whether it is above the fold, its exact button text, and the number of competing actions.

44. Navigation and site structure

Count the items in the main navigation. Then, from the homepage, count the clicks required to reach each key service page and the contact page. The target is two or fewer. Check the navigation on mobile separately; menus that work on desktop frequently collapse into something unusable on a phone.

Record: navigation item count, click depth to each key page, and any mobile-specific breakage.

45. Engagement metrics

In GA4, go to Reports, Engagement, Pages and screens. For each key page, record the engagement rate and the average engagement time. Note that GA4's engagement rate is the inverse of the old bounce rate; a 40% engagement rate means 60% of sessions were not engaged. Filter to organic traffic only, otherwise direct and branded traffic will flatter the numbers.

Record: engagement rate and average engagement time per key page, organic sessions only.

46. Intrusive interstitials

Load your key landing pages in a mobile viewport in an incognito window, so cookies do not suppress pop-ups. Note anything that appears on load or within the first few seconds and covers the content. A small consent banner is fine. A full-screen overlay served to somebody arriving from search is a problem Google names explicitly in its guidance.

Record: which pages trigger overlays, what triggers them, the timing, and how much of the viewport they cover.

Section 8: How do you check AI search visibility?

Search increasingly gets answered before anybody clicks. These six checks establish whether the site is present in generated answers, or whether competitors are supplying them. All of it is manual, and none of it takes long.

47. Google AI Overview presence

Take four to six of your most important non-branded queries from check 23 and search each in an incognito window. Note whether an AI Overview block appears at the top of the results. Where it does, expand the citation list and record which domains are being used as sources. The queries where an overview appears and cites only competitors are the priority list.

Record: per query, whether an overview appears, the cited domains, and whether yours is among them.

48. Answer engine visibility

Ask ChatGPT, Perplexity, and Gemini the same three or four buying-intent questions a customer would ask: "who are the best {service} providers in {region}", "recommend a company for {service}". Note whether your brand appears and whether it is linked. Then ask each engine directly, "what is {brand} and what do they do", and check whether the answer is accurate, wrong, or empty. Record which sources each engine cites, because that list is where the visibility is actually being decided.

Record: per engine, whether the brand surfaces unprompted, whether the direct description is accurate, and the sources cited.

49. Answer-ready content structure

Open four or five key pages and check whether each one answers its core question directly in the first paragraph, rather than after three paragraphs of context. Look for the structure engines extract from: descriptive question-shaped H2s, short definitional sentences, tables, and a real FAQ block rather than three questions nobody asked.

Record: per page, how far down the page the direct answer sits, and whether question headings and an FAQ block exist.

50. Citation-worthy signals

Assess whether your pages contain the things generative engines preferentially quote: concrete numbers, prices, timeframes, original data, and clearly sourced claims. Then check for visible authorship: a named author, a credential or bio, and a published or updated date. Content that is anonymous, undated, and free of specifics is not going to be cited by anything.

Record: per key page, whether an author and date are visible, and how many concrete specifics the page contains.

51. Answer-supporting structured data

Run the homepage and two or three key pages through the Rich Results Test and the Schema Markup Validator. Look specifically for Organization with a populated sameAs array, FAQPage on pages with genuine question and answer content, Article with author and datePublished on blog posts, and BreadcrumbList. The sameAs array is the one most often left empty, and it is the link between your site and your profiles elsewhere.

Record: markup types found per page, missing fields, and the full sameAs list if present.

52. AI crawler access

Reopen yourdomain.com/robots.txt and search for these user-agents specifically: GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot, and Bytespider. Record whether each is allowed, blocked, or unmentioned, then establish whether any block was a deliberate decision or an inherited default from a plugin or a hosting template. Also request yourdomain.com/llms.txt and note the response; absence is a data point, not a fault.

Record: the directive for each user-agent, whether it was intended, and the llms.txt status code.

FAQ

How long does a full website SEO audit take?

For a small site, four to eight hours for the first pass if you already know the tools, spread across a couple of days because crawls, SSL scans, and PageSpeed runs all involve waiting. The technical and on-page sections take the longest. The AI search section takes under an hour and is usually the most surprising.

Do I need paid tools to run an SEO audit?

No. Every check above can be completed with Search Console, PageSpeed Insights, Chrome DevTools, the free Screaming Frog tier, GA4, and free validators. Paid tools save time on sites over 500 URLs and give far better backlink and keyword gap data. They do not reveal a category of problem that free tools miss completely.

How often should a website be audited?

A full audit once a year, and after any significant change: a redesign, a platform migration, a CMS upgrade, or a hosting move. Between audits, the Search Console Pages report and Core Web Vitals report are worth a monthly glance, because they surface regressions without you having to go looking for them.

What is the difference between this and a technical SEO audit?

A technical SEO audit covers crawling, rendering, indexation, speed, and security in far more depth, and stops there. This checklist covers the technical layer more briefly, then adds on-page, keywords, backlinks, competitors, local presence, conversion, and AI visibility. Technical is the foundation; this is the whole building.

Should I fix everything I find?

No. Most audits produce more findings than any business will act on, which is why severity belongs in the spreadsheet from the start. Fix anything blocking indexation first, then anything on a page that already earns impressions, then everything else. A finding with no traffic behind it can wait.

Closing

Fifty-two checks produce a document, and the document is the point. Findings with evidence attached can be sequenced, costed, and handed to whoever does the work; impressions cannot. If you would rather have the data gathered and prioritized for you, an SEO audit covers all of this, and the implementation can be handled from there.

The obvious part

For your GBP to rank, you first need to have one! And it's not just about having one, it needs some love. Accurate information, few photos, a list of services you offer, etc. Most of this things that if you give it some time and follow the process of creating the profile carefully and with attention to detail, you won't miss. This is the obvious part, which is definitely worth reminding. It's not difficult to have a decent GBP, it just requires a little effort.

What details need special attention?

Even though setting up a decent profile is easy and intuitive, there are definitely few thing that are easy to miss. And those things are the opening hours, review recency, review count, review responses and website content.

Opening hours

Some businesses, like local shops, don't have much of a choice. They should just write the actual opening hours. There are businesses that can't really afford being found by a user only to frustrate him by being closed while Google states they are open. But there are companies, especially in the legal sector, that close most clients on the phone, for instance. When answering the phone is a priority, some companies even opt to be open 24/7, just to make sure that when they are found, the potential client know he can call right away. Of course this kind of commitment is not for everyone. Still, B2C companies should keep in mind, that if they are closed in the afternoon and on weekends too, they most likely won't receive many phone calls.

Review recency

Reviews are probably one of the most important factors. And review recency is especially important to close customers. According to BrightLocal, 18% are only convinced by reviews from within the last seven days. 32% look for reviews two weeks old or less and 74% seek reviews written in the last three months. Getting reviews on Google is not a one time thing. It's not just getting a decent number of reviews with a good overall score. Collecting reviews on Google has to be a constant process, that should never stop.

Review count

Once you get the reviews flowing, this is a matter of time. But still worth mentioning. Local pack reviews show not only the overall rating, but also the review count. If you have to choose between three companies you never heard about, they all seem similar, all have good reviews, but one has 200+ reviews, another has only 70+ and the last one has 190+ reviews, which one would you choose? Would you even think about the second one? Placement is of course very important, but so are reviews. And don't forget the overall score is legitimized by their count. 4 stars from hundreds of reviews are more valuable than 5 stars from only a dozen.

Answering reviews

This is actually quite similar to any social media. Algorithms nowadays like active users. Also, when your profile is active, it sends a clear signal to the user that the profile is not abandoned, so all the information that can be found in there is up-to-date. So it's definitely answering to the reviews should be a part of the flow.

Website content

Another thing to have in mind, is that although local pack is different from normal results, the two are still connected. It's not only about making sure the your online presence remains consistent and congruent. It's also that quite few users actually visits the website of businesses they find. And so it's important that the website supports the GBP, and makes sure the user doesn't go back and choose a competitor.

Conclusion

A decent GBP is easy to get. Refining it requires a little research, mostly to make sure you are not missing anything. But overall it's a pretty easy and straightforward way of making sure people will get to know about your business. Ranking outside the local pack is still important, and somewhat more difficult to achieve. And so if you need help with SEO or your GBP, check out our SEO audit offer.

In short: A technical SEO audit checks crawlability, indexation, site architecture, JavaScript rendering, speed, mobile experience, security, structured data, and AI crawler access. Most of it can be done with Google Search Console, PageSpeed Insights, Chrome DevTools, and a free crawler.

What you need before you start

Everything below can be done with free tools. You will need verified access to Google Search Console for the site; without it, roughly a third of the checks are guesswork.

Before you touch anything, create a spreadsheet with four columns: check number, finding, evidence (URL or screenshot), and severity. Fill it as you go.

Section 1: How do you check crawlability and indexation?

This is the foundation. If crawlers cannot reach pages, or Google has decided not to index them, nothing else in the audit matters.

1. Robots.txt configuration

Open yourdomain.com/robots.txt directly in a browser. Confirm it returns HTTP 200, not a 404 or 500. Read the whole file. Look for Disallow: /, which blocks the entire site, and for any rule that catches service pages, the blog, or CSS and JS files needed for rendering. Confirm a Sitemap: directive is present and points to a live sitemap URL.

Record: status code, full file contents, any Disallow rule affecting content, whether the sitemap is declared.

2. XML sitemap health

Open yourdomain.com/sitemap.xml. Confirm it is well-formed XML and returns 200. Take a sample of 15 to 20 listed URLs and check each returns 200, is the canonical version, and is not set to noindex. Confirm the sitemap excludes admin pages, cart pages, thank-you pages, and parameter URLs. Then open Search Console, go to Indexing, then Sitemaps, and compare the discovered URL count against the number of pages you believe the site has.

Record: URL count in sitemap, number of sampled URLs failing, GSC discovered count, last read date.

3. Index coverage and excluded pages

In Search Console, go to Indexing, then Pages. Note the Indexed and Not indexed totals. Open the "Why pages aren't indexed" breakdown and record the count for each reason, paying particular attention to Crawled - currently not indexed, Discovered - currently not indexed, Soft 404, Excluded by noindex tag, and duplicate reasons. Then check that your most commercially important pages appear in the indexed set.

Record: indexed count, not-indexed count, the full reason breakdown with counts, and any key page found in the not-indexed set.

4. HTTP status codes and server errors

Crawl the site with Screaming Frog. Sort the internal URL list by status code. Flag every 4xx and 5xx response that is linked from somewhere on the site or appears in the sitemap. Separately, request a URL that definitely does not exist (yourdomain.com/thispagedoesnotexist) and check the response code in the DevTools Network tab. It must return a true 404. A 404 page returning status 200 is a soft 404 and creates indexable junk.

Record: list of 4xx URLs with source pages, list of 5xx URLs, and whether the 404 page returns a real 404.

5. Redirect chains and loops

In the Screaming Frog crawl, use Reports, then Redirects, then Redirect Chains. A chain is any redirect passing through more than one hop (A to B to C). Also manually test the four host variants and any known legacy URLs. Check whether redirects intended as permanent are 301 rather than 302. Flag any URL that redirects back to itself or into a cycle.

Record: each chain with its hop count, any 302s used for permanent moves, any loops.

6. Crawl budget and index bloat

Compare the total indexed page count from check 3 against the number of pages the site genuinely needs indexed. A large gap is the signal. In Search Console, use the Pages report to list indexed URLs and scan for parameter URLs, filter URLs, tag archives, paginated duplicates, and internal search results pages. Then go to Settings, then Crawl stats, and review what Googlebot is spending requests on by file type and response code.

Record: indexed count versus intended count, categories of low-value indexed URLs with rough counts, average crawl requests per day.

7. Orphan pages

Compare two lists: every URL in the sitemap or your known page inventory, and every URL that Screaming Frog discovered by following internal links. Anything in the first list but not the second is an orphan, reachable only by direct URL or sitemap. Screaming Frog can do this directly if you connect the Search Console API before crawling.

Record: orphan URL list, flagging any that are commercially important.

Section 2: How do you check site architecture and URLs?

8. URL structure and consistency

Export the URL list from your crawl. Review a representative sample of 30 or so for lowercase-only characters, hyphens rather than underscores or spaces, absence of avoidable dynamic parameters, sensible length, and readable slugs. The thing to look for is inconsistency across page types: some URLs hyphenated and some not, some with trailing slashes and some without.

Record: the conventions in use per page type, and any mixed conventions.

9. Canonicalization and duplicate URLs

On five to ten key pages, view the source and find <link rel="canonical">. Confirm it exists, uses an absolute HTTPS URL, and points to the page itself. Then test the duplicate access paths: with and without a trailing slash, with a tracking parameter appended, and the print version if one exists. Each should either return the same canonical or redirect.

Record: per page, whether the canonical is present, self-referencing, and absolute; plus any duplicate path that resolves with 200 and no canonical.

10. Internal linking and link equity flow

In the crawl, look at the inlinks count for each page. Check that key commercial pages receive multiple internal links from relevant content, not just from the footer. Sample the anchor text used for those links and note how much of it is "click here", "read more", or the bare URL.

Record: inlink count for the top ten commercial pages, and a sample of anchor text patterns.

11. Site depth and click distance

Screaming Frog reports crawl depth as the number of clicks from the start URL. Sort by depth and look at what sits at level 4 and beyond. The target is important pages within three clicks of the homepage.

Record: depth distribution (how many URLs at each level), and any commercially important page deeper than three.

12. Pagination handling

Find a paginated series such as a blog index or category listing. Open page 2 and view the source. Check that the canonical on page 2 points to page 2, not back to page 1. Check that pagination links are real <a href> elements in the HTML rather than JavaScript-only controls. Check whether paginated pages carry noindex, and whether a "view all" page exists.

Record: canonical target per paginated page, whether pagination links are crawlable, presence of noindex.

Section 3: How do you check rendering and JavaScript?

Search engines render JavaScript, but not always immediately and not always completely. The purpose of this section is to establish what exists in the raw HTML versus what only appears after scripts run.

13. JavaScript rendering and content parity

Fetch the raw HTML for a key page. In Chrome, "View page source" gives you this, or use curl -s https://yourdomain.com/page. Then open the same page normally and inspect the rendered DOM in DevTools Elements. Compare: is the H1 in the raw HTML? The body copy? The main navigation links? The meta description and canonical? If they only appear in the rendered version, you have a dependency worth documenting. Confirm with the Rich Results Test, which shows you the rendered HTML Google actually produced.

Record: for each of H1, body content, navigation, canonical, and meta tags, whether it is present in raw HTML, rendered DOM, or both.

If you are not sure whether this affects your own site, an audit will establish it along with everything else worth checking.

14. Render-blocking resources

Run the page through PageSpeed Insights. Under Diagnostics, open "Eliminate render-blocking resources" and record the listed files with their estimated savings in milliseconds.

Record: file list, total potential saving, and the current LCP figure for context.

15. Lazy-loading of critical content

Identify the LCP element (PageSpeed names it under "Largest Contentful Paint element"). Then check the HTML for that element. If it is an image carrying loading="lazy", that is the finding. Also confirm that lazy loading is applied to below-the-fold media rather than blanket-applied to every image.

Record: the LCP element, whether it is lazy-loaded, and how lazy loading is applied across the page.

Section 4: How do you check speed and Core Web Vitals?

16. Page speed, mobile and desktop

Run the URL through PageSpeed Insights twice, once for each strategy. Record both Performance scores. Score the site against the lower figure, which is almost always mobile. Do this for at least three page types: homepage, a key service or product page, and a content page. A single homepage test is not representative.

Record: mobile and desktop Performance score per page type, plus the top three listed opportunities.

17. Core Web Vitals

From the same PageSpeed report, record LCP, INP, and CLS. Prefer the field data at the top of the report, which comes from real Chrome users, over the lab data below it. If the field data section is absent, the site has insufficient traffic for the Chrome UX Report and you are working with lab data only. Note that. Then check Search Console, Experience, Core Web Vitals for the site-wide picture across URL groups.

Thresholds: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1.

Record: the three metric values per page, whether they come from field or lab data, and the count of URLs in each GSC status band.

18. Image optimization and next-gen formats

From the PageSpeed report, record the findings under "Properly size images", "Efficiently encode images", "Serve images in next-gen formats", and "Image elements do not have explicit width and height". Then spot-check the hero image in DevTools Network: compare its transferred size and intrinsic dimensions against its rendered display size.

Record: the four diagnostic values with estimated savings, plus the hero image size comparison.

19. Caching, compression, and CDN

Open DevTools, go to Network, reload the page, and click any static asset such as a CSS or JS file. Read the response headers. Look for content-encoding: gzip or br, and a cache-control header with a meaningful max-age. You can do the same from a terminal with curl -I https://yourdomain.com/style.css. Check the asset hostnames and headers for CDN indicators such as cf-ray or x-served-by.

Record: compression method, cache-control values for static assets, and whether a CDN is in use.

20. Third-party script weight

In PageSpeed, open "Reduce the impact of third-party code" and record each third party with its transfer size and main-thread blocking time. Cross-check in DevTools Network by filtering to third-party domains. If a tag manager is installed, open its container and list the tags actually firing.

Record: third-party list with blocking time, total third-party transfer size, and any script loaded synchronously in the head.

Section 5: How do you check mobile and page experience?

21. Mobile responsiveness

Open DevTools, toggle device emulation, and set the viewport to a common mobile size such as 390 by 844. Load the homepage, a service page, a content page, and any form page. Check for horizontal scroll, content overflowing the viewport, text too small to read without zoom, and broken navigation. Test on a real device if you can; emulation misses touch and font-rendering issues.

Record: per page type, whether layout holds, plus screenshots of any breakage.

22. Viewport and tap target sizing

View the source and confirm <meta name="viewport" content="width=device-width, initial-scale=1"> is present and correct. Then, in mobile emulation, inspect the primary navigation links, buttons, and form fields. Google's guidance is a tap target of at least 48 by 48 CSS pixels with 8 pixels of spacing. DevTools shows element dimensions on hover.

Record: viewport meta content, and a list of interactive elements falling below the size or spacing threshold.

23. Intrusive interstitials

Load your key landing pages in mobile emulation with a clean session (use an incognito window so cookies do not suppress pop-ups). Note anything that appears on load or within the first few seconds and covers the main content. Distinguish a small consent banner, which is acceptable, from a full-screen overlay, which is not.

Record: which pages trigger overlays, what triggers them, timing, and how much of the viewport they cover.

Section 6: How do you check security and HTTPS?

24. HTTPS enforcement and SSL certificate

Confirm the site loads over HTTPS. Then request the HTTP version and check in DevTools Network that it redirects to HTTPS in a single hop. Click the padlock in the address bar to see certificate details: issuer, validity dates, and the domain it covers. Run the domain through SSL Labs for the configuration grade; the scan takes a couple of minutes.

Record: redirect behavior and hop count, certificate expiry date, issuer, SSL Labs grade.

25. Mixed content

Load key pages with the DevTools Console open. Mixed content warnings appear there automatically. Search the page source for http:// references in src and href attributes on images, scripts, stylesheets, and iframes.

Record: each mixed-content resource with its URL and type, separating active content (scripts, iframes) from passive (images).

26. Security headers

Run the domain through securityheaders.com, or read the response headers directly with curl -I https://yourdomain.com. Look for Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options or a frame-ancestors CSP directive, and any Content-Security-Policy.

Record: which headers are present and their values. This is a hygiene and trust check rather than a ranking factor, so log it and move on.

27. Exposed sensitive files and endpoints

Request a set of common paths and note the response codes: /.env, /.git/config, /wp-config.php.bak, /backup/, /admin/, /phpinfo.php, and the staging subdomain if you know one exists. Anything returning 200 with real content is a finding. Then search the page source of key pages for API keys or credentials; press Ctrl+F in view-source and search for key, token, secret, and api.

Record: each exposed path with its response code, and any credential found in client-side source.

Section 7: How do you check structured data and directives?

28. Structured data validity

Run the homepage and one URL of each significant page type through the Rich Results Test. Record which schema types are detected, the count of errors, and the count of warnings. Then run the same URLs through the Schema Markup Validator, which validates against schema.org rather than only Google's supported rich result types.

Record: detected types per page type, errors, warnings, and any page with no structured data at all.

29. Meta robots directives

On each key page, view the source and search for <meta name="robots". Then check the HTTP response headers for X-Robots-Tag, which is easy to miss because it never appears in the HTML. Use the Search Console URL Inspection tool on your top five commercial pages to see the indexability verdict Google itself has reached.

Record: the robots directive found per page in both locations, and the URL Inspection verdict for key pages.

30. Open Graph and social meta tags

View the source on your main page types and record whether og:title, og:description, og:image, og:url, og:type, and the Twitter Card tags are present. Confirm the og:image URL resolves and is at least 1200 by 630 pixels. The Facebook Sharing Debugger renders the preview and reports missing tags.

Record: tag presence per template, image dimensions, and any templates sharing an identical og:image.

31. Hreflang implementation

If the site is monolingual, mark this N/A and move on. Otherwise, view the source on a page that exists in multiple languages and record the <link rel="alternate" hreflang="..."> set. Check the language and region codes are valid, that each page references itself, that pairs are reciprocal, and that an x-default exists. The Merkle hreflang tester validates a URL's tags automatically.

Record: hreflang set per sampled URL, missing reciprocals, invalid codes, broken target URLs.

32. WWW, non-WWW, and protocol consistency

Request all four variants: http://domain.com, http://www.domain.com, https://domain.com, https://www.domain.com. Each should redirect in a single hop to one canonical version. Then confirm that this canonical host is the one used in canonical tags, in the sitemap, and in internal links.

Record: the final destination and hop count for each of the four variants, plus any variant resolving with 200.

33. Parameter and faceted URL handling

Identify the parameter patterns the site generates: sorting, filtering, pagination, tracking, session IDs. Search Console's Pages report will show you which of them Google has indexed. For a sample, view the source and check whether they carry a canonical to the clean URL, a noindex, or nothing at all.

Record: parameter patterns in use, how many parameter URLs are indexed, and the handling method applied to each pattern.

Section 8: How do you check AI crawler access?

34. AI crawler directives

Reopen yourdomain.com/robots.txt and search specifically for these user-agents: GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot, and Bytespider. Record whether each is allowed, blocked, or unmentioned. Then establish whether any block was a deliberate decision or an inherited default from a plugin or platform template.

Record: the directive for each user-agent, and whether the site owner intended it.

35. llms.txt and machine-readable signals

Request yourdomain.com/llms.txt and note the response. This is an emerging convention rather than a standard, so absence is not a fault; it is a data point. Separately, check whether core business information (what the company does, pricing, contact details, service descriptions) exists as plain text in the HTML, or whether it is locked inside images, PDFs, or JavaScript-rendered components.

Record: llms.txt status code, and for each of pricing, contact, and service descriptions, whether the information is plain-text accessible.

36. Entity structured data

Run the homepage through the Rich Results Test and the Schema Markup Validator. Look specifically for Organization or LocalBusiness markup and record which fields are populated: name, url, logo, description, and sameAs. The sameAs array should list the brand's profiles on LinkedIn, review platforms, and social networks.

Record: entity type used, fields present, and the full sameAs list.

FAQ

How long does a technical SEO audit take?

For a small site, the first full pass takes four to six hours if you know the tools. Most of that is waiting: crawls, SSL Labs scans, and PageSpeed runs across multiple page types. Larger sites take longer mainly because sampling has to be more careful, not because the checks change.

Do I need paid tools for a technical SEO audit?

No. Every check in this list can be completed with Search Console, PageSpeed Insights, Chrome DevTools, the free Screaming Frog tier, and a handful of free validators. Paid crawlers save time on sites above 500 URLs and give better internal link analysis, but they do not surface a category of problem that free tools miss entirely.

How often should a technical audit be repeated?

After any significant change: a redesign, a platform migration, a CMS upgrade, or a hosting move. Search Console Pages report and Core Web Vitals report are worth checking regularly, since they surface regressions without you having to look for them.

What is the difference between a technical audit and a full SEO audit?

A technical audit covers crawling, rendering, indexation, speed, and security. A full audit adds on-page content, keyword performance, backlink profile, competitor comparison, and conversion factors. Technical is the foundation layer; the rest depends on it working. Running a content audit on a site that Google cannot crawl properly wastes the effort.

Closing

The value of a technical audit is in the record, not the reading. Thirty-six measured findings, each with evidence attached, give you something to sequence and hand to a developer. Thirty-six impressions do not. If you would rather have the data collected and prioritized for you, a technical SEO audit covers all of it, and the implementation can be handled from there.

This article explains what each audit covers, where they overlap, and how to tell which one your site actually needs. No jargon left undefined, and no pressure to buy the bigger package if the smaller one solves your problem.

In short: A technical SEO audit checks whether search engines can crawl, render, and index your site. A full SEO audit covers all of that, plus content, keywords, backlinks, competitors, and conversions. Technical is one slice of the full audit. If a hidden infrastructure fault is hurting you, technical is enough; if you want to know why you are not ranking, you need the full picture.

What is a technical SEO audit?

A technical SEO audit checks the machinery underneath your website. Not the words on the page, but whether search engines can reach those words, read them, and file them correctly. If that machinery is broken, the rest of your SEO effort is wasted, because the page never makes it into the search index in the first place.

Most technical audits look at the same core areas.

Crawlability. Whether search engine bots can move through your site and reach every page that matters. This covers your robots.txt file (the file that tells bots where they may and may not go), your XML sitemap, broken links, and redirect chains that send bots in circles.

Indexation. Whether the pages bots reach actually end up in Google's index. A single stray "noindex" tag can quietly remove an important page from search. Duplicate content and misconfigured canonical tags (the signal that tells Google which version of a page is the original) also sit here.

Speed and Core Web Vitals. How quickly pages load and respond. Google measures three things it calls Core Web Vitals: Largest Contentful Paint (loading, target under 2.5 seconds), Interaction to Next Paint (responsiveness, target under 200 milliseconds), and Cumulative Layout Shift (visual stability, target under 0.1). These are confirmed ranking signals, and they affect conversions too.

Mobile and security. Google indexes the mobile version of your site, not the desktop one, so the mobile experience has to carry all the same content. HTTPS, the secure version of a web connection, is a confirmed ranking factor and a basic trust signal.

Structured data and architecture. Schema markup (code that tells search engines what a page is about) and a logical internal linking structure help both search engines and, increasingly, AI systems understand and surface your content.

The goal of all this is narrow and important: make sure search engines can find, read, and trust your site. A technical audit does not tell you whether you are targeting the right keywords or whether your content is any good. It tells you whether the plumbing works.

What does a full SEO audit cover?

A full SEO audit includes everything above, then keeps going. It treats technical health as the foundation rather than the whole building, and it examines the factors that decide whether a technically sound site actually ranks and earns leads.

The areas a full audit adds:

• On-page SEO: titles, meta descriptions, heading structure, and how well each page is optimised for the term it should rank for.

• Content and keywords: whether you are targeting terms people actually search, where the gaps are, and whether two pages are competing for the same keyword (a problem called keyword cannibalisation).

• Backlinks and authority: the quality and profile of sites linking to you, since links remain one of the strongest signals of trust.

• Competitor analysis: what the sites outranking you are doing differently, and where the realistic openings are.

• Local SEO: for businesses serving a geographic area, the Google Business Profile, citations, and reviews that drive local visibility.

• UX and conversion: whether the traffic you do earn turns into enquiries, or leaks away on a confusing page.

The output is different too. A good full audit does not just list problems; it ranks them by impact and ties them to business outcomes, so you know which three fixes to make first instead of drowning in a hundred minor warnings.

Technical SEO audit vs full SEO audit: the key differences

The clearest way to see the gap is side by side.

The table makes the relationship plain. A technical audit is a subset of a full audit, not a competing product. The question is never which is better; it is which scope matches the problem you are trying to solve.

Which audit does your site actually need?

Start with the symptom.

If your traffic dropped suddenly, you recently migrated to a new domain or platform, or you just launched a redesign, a technical audit is the right first move. Sudden changes usually break something mechanical: a sitemap, a redirect, an accidental noindex tag rolled out across a template. A focused technical pass finds those fast, and they are often cheap to fix once identified.

If your site works fine but has plateaued, if you are new to SEO and want to know where you stand, or if you operate in a competitive market and cannot understand why rivals outrank you, a full audit is the better spend. Those problems rarely come from the plumbing. They come from content that is not competitive, keywords nobody searches, or an authority gap that no amount of technical tidying will close.

There is an honest limit worth stating plainly. A technical audit can hand your site a clean bill of health and you can still rank nowhere. Technical SEO gets you found; it does not get you chosen. Being crawlable and fast is the price of entry, not the thing that wins. If you are not sure which camp your site falls into, a full audit surfaces the technical issues and the content and authority gaps in one pass, then ranks them by what actually moves traffic.

The catch: an audit is only as good as its priorities

There is a version of the technical audit that is close to worthless, and it is the one most commonly sold cheaply. You pay a small fee, a tool crawls your site, and you receive a 200-row spreadsheet of "errors" with no sense of which ones matter. Most of them do not. A handful might be costing you real traffic, and the export does nothing to tell you which.

The value in any audit is not the list of issues; it is the judgement applied to them. Knowing that a redirect chain on a forgotten old URL matters far less than a noindex tag sitting on your main service page is the difference between an audit and a data dump. This holds for technical and full audits alike. Before you pay for either, ask one question: does this come with prioritisation, or just findings? Findings are cheap. Knowing what to do first is the part worth paying for.

Frequently asked questions

Is a technical SEO audit enough on its own?

It depends on the problem. If a mechanical fault is suppressing an otherwise strong site, a technical audit may be all you need. But technical health does not guarantee rankings; it only removes the barriers to them. If your site is technically clean and still not ranking, the answer lies in content, keywords, or authority, none of which a technical audit examines.

How much does a technical SEO audit cost?

Prices range widely, from automated tool exports costing very little to detailed manual audits costing several hundred or more. The price usually reflects how much human analysis and prioritisation is involved. A cheap audit often means a raw tool report; a more thorough one should include a person deciding which issues actually matter and in what order to fix them. A fuller breakdown of what an SEO audit costs covers the ranges in detail.

How long does an SEO audit take?

A focused technical audit on a small site can be done in a day or two. A full audit on a larger or more complex site takes several days, because content, backlinks, and competitor analysis cannot be automated to the same degree. A rushed audit misses the issues that take time to surface, so thoroughness matters more than speed here.

Do I need a technical audit after a redesign or migration?

Yes. Redesigns and migrations are the single most common cause of self-inflicted SEO damage. Templates change, URLs move, redirects get missed, and noindex tags meant for the staging site sometimes ship to the live one. A technical audit shortly after launch catches these before they erode rankings that took years to build.

The two audits answer different questions. A technical SEO audit asks whether search engines can use your site; a full SEO audit asks why it ranks where it does and what to change. Technical is the foundation, a nice start, not the finish line. If this has raised questions about your own site, our 46-point SEO audit covers the technical layer and the six other areas that decide rankings, with every finding ranked by impact rather than dumped in a list. If you rather only focus on technical SEO, we can do that too with our technical SEO audit.

In short: The right time to start investing in SEO is immediately after you have validated product-market fit, defined your ICP tightly enough to know what they search for, and have enough runway to wait six to twelve months for organic results. Pre-PMF, focus on foundation-setting, not content production.

Why Timing Matters More Than Most Founders Realise

SEO is a compounding channel. Results from content you publish today accumulate over months, not days. That compounding is enormously valuable, but it also means that content published at the wrong stage, targeting the wrong audience, compounds in the wrong direction.

If you have not yet validated product-market fit, you do not know which customer you are writing for. You might rank for a cluster of keywords and attract users who churn immediately, which signals poor quality to Google and damages your domain reputation before the right audience ever finds you.

The cost of bad timing is not just wasted effort. It is a handicap you carry into the stages where SEO actually matters.

Stage 1: Pre-PMF (0 to 12 Months, Typically)

At this stage, your job is not to generate inbound traffic. Your job is to understand whether a product people actually want exists, and to talk to users directly to find out.

SEO is a poor tool for this. The feedback loop is too slow. You need signals in days, not months.

That said, there are two things worth doing now that will pay off later.

Set up your technical foundation. Make sure your site is indexable, loads quickly, and has clean URL structures. This takes a few hours and prevents problems that are expensive to fix later. A basic SaaS SEO audit at this stage can surface structural issues before they compound.

Claim and fill your Google Business Profile, if relevant. Even for SaaS businesses with no local footprint, having a verified presence matters for branded search trust.

Do not write content yet. You do not know what to write. Wait until you know who you are writing for.

Stage 2: Post-PMF, Pre-Scale (Typically 12 to 36 Months)

This is the moment most SaaS founders miss. They either jump into aggressive content production before their ICP is defined, or they delay SEO entirely because they are chasing paid channels.

The right move is to start deliberately, not frantically.

After PMF validation, you should be able to answer these four questions with reasonable confidence:

1. Who is your ICP, specifically? Not "small businesses" — which type, which role, which problem.

2. What words does your ICP use when they search for a solution like yours? Not what you call it; what they call it.

3. What is your runway? Do you have 18 months to see organic traffic compound, or 9?

4. Can you commit to consistent output? One piece of quality content per week is more valuable than ten pieces published in a sprint and then nothing.

If you can answer all four clearly, you are ready to start building your SEO programme. If you cannot answer question one or two, pause and do the ICP research first. Everything downstream depends on it.

The Pre-Scale SEO Checklist for SaaS Founders

Before you commission your first content brief or hire a content writer, work through this checklist:

• [ ] PMF is validated: you have paying customers who came back, referred others, or renewed

• [ ] ICP is defined: you know the job title, company size, industry, and core pain of the buyer

• [ ] You have mapped at least one keyword cluster your ICP uses when searching for your category

• [ ] Technical SEO basics are in place: fast load times, no crawl errors, clean site structure

• [ ] You have a blog or resources section that is indexed and ready to receive content

• [ ] You have at least 6 months of runway beyond your current burn rate (SEO takes time)

• [ ] You have one person, internal or external, who owns the SEO workflow

If more than two of these are unchecked, focus there before producing content.

What a 6-Month-Old SaaS Should Actually Do

Assume you are six months in. You have paying customers, early signs of retention, and a clearer picture of your buyer. Here is where to spend your SEO time:

Keyword research focused on problem-aware terms. Your ICP at this stage is likely not searching for your product category by name. They are searching for their problem. "How to reduce churn for B2B SaaS" is a problem-aware query. "Customer success software" is a solution-aware query. Both matter, but problem-aware content builds pipeline earlier.

One cornerstone article per quarter, not one per week. A well-researched 2,000-word article that targets a real query your ICP has is worth more than six thin posts. Depth signals expertise; expertise builds trust; trust earns links.

Build the internal link structure from day one. Every article should link to at least one pillar page on your site. Pillar pages link to cluster articles. This architecture tells Google which pages matter most and accelerates ranking for your most commercial terms.

Do not pursue backlinks aggressively at this stage. Backlinks matter eventually, but at six months, your content is not yet strong enough to earn links at scale. Focus on creating content worth linking to; the links follow.

What a 3-Year-Old SaaS Should Do Differently

By year three, the game has shifted. You have content assets, some domain authority, and probably a better picture of what is already ranking. Now the work looks different:

Audit before adding. Before publishing anything new, understand what you already have. Which pages are getting impressions but not clicks? Which ones rank on page two and could be pushed to page one with a content refresh? Adding more content to a weak foundation is like pouring water into a leaky bucket.

Target commercial-intent terms more aggressively. Your ICP at this stage has likely heard of your category. They are searching "[your category] best tools" or "[competitor] alternative." These terms convert at higher rates and should be prioritised over purely informational content.

Invest in conversion rate optimisation alongside SEO. Traffic that does not convert is a cost, not an asset. By year three, if organic traffic is growing but trial signups are flat, the problem is probably the page, not the keyword.

Build or commission competitor comparison pages. Searches like "[Competitor] vs [Your Product]" have high commercial intent and are often easier to rank for than generic category terms. These pages also serve your sales team as objection-handling assets.

DIY SEO or Hire Someone? The Honest Answer

At the pre-PMF and early post-PMF stages, DIY SEO is often the right call. You cannot brief an agency or freelancer to write for an ICP you have not yet defined. And the foundation-setting work, technical basics, keyword research, site structure, can be done without specialist help if you are willing to learn.

The case for bringing in external expertise gets stronger once you have content producing results. At that point, you need someone who can interpret the data, identify gaps, and build on what works, rather than start from scratch.

A productised audit at this stage gives you a clear picture of where you stand before you commit ongoing spend. That is a better use of budget than months of retainer work on a site that has unresolved structural problems.

FAQ

How long does it take to see results from SEO for a SaaS?

For a new domain with no existing authority, expect six to twelve months before meaningful organic traffic arrives. In competitive categories, eighteen months is realistic. The timeline shortens significantly if you are targeting long-tail, low-competition keywords first and building domain authority steadily through quality content and genuine backlinks.

Should a SaaS startup use paid ads instead of SEO?

Paid and organic serve different roles. Paid delivers immediate traffic with immediate cost; organic delivers compounding traffic with delayed payoff. Early-stage companies often need paid for rapid validation and cash flow, but relying on paid only leaves you exposed to rising CPCs over time. The strongest SaaS companies build both channels, with SEO maturing as the business scales.

What is the biggest SEO mistake early-stage SaaS founders make?

Writing content before the ICP is defined. The second biggest is targeting high-volume keywords that are too competitive for a new domain. Both mistakes produce content that ranks for nothing or attracts the wrong traffic. Start narrow, go deep, and expand once you have traction.

Is SaaS SEO different from traditional SEO?

The core mechanics are the same, but the content strategy differs significantly. SaaS buyers move through longer consideration cycles, research more thoroughly, and rely on comparison content, integration guides, and ROI justification in ways that product or local businesses do not. The keyword clusters you target and the content formats that convert are different as a result.

What does a SaaS SEO audit actually cover?

A good audit covers technical site health, on-page optimisation, keyword mapping against your ICP, internal link structure, backlink profile, and competitor gap analysis. The goal is not a list of problems to fix; it is a prioritised action plan tied to business outcomes.

The decision of when to start SEO for your SaaS is not really about timing. It is about readiness. Build the foundation early, wait for PMF confirmation before scaling content, and make sure your ICP is defined precisely enough that you know what to write and for whom. If you want an outside view of where your site stands before committing to an ongoing strategy, an SEO audit for SaaS is the logical starting point.

A SaaS site has a different SEO surface area from a brochure site. It has an app on a subdomain that should never be indexed, a pricing page that decides half your organic revenue, a features section that is usually one page when it should be twelve, and a trial flow at the end that quietly wastes every ranking you earn. This SaaS SEO audit checklist works through all of it, in the order it makes sense to look.

In short: A SaaS SEO audit covers rendering and app subdomain handling, pricing and feature page structure, funnel-stage keyword coverage, comparison and integration content, trial flow friction, review platform footprint, and AI search visibility. All 52 checks below can be run with free tools.

What do you need before you start?

Everything here runs on free tools, but two things gate the audit. Without verified Google Search Console access you cannot complete the keyword and indexation checks, which is a third of the value. Without knowing your own product's integration list and buyer personas, section 5 is guesswork.

Open a spreadsheet first. Four columns: check number, finding, evidence, severity. Then pick the sample pages you will use throughout and do not change them: homepage, pricing page, one feature page, one integration or use-case page if either exists, the trial or demo page, and one blog post.

One SaaS-specific note before you start. Decide early whether the marketing site and the app live on the same host, a subdomain, or a separate domain, and write it down. Half the technical findings below depend on knowing which is which.

Section 1: How do you check technical SEO on a SaaS site?

The generic technical checks apply, but three things break more often on SaaS sites than anywhere else: client-side rendering, app subdomain handling, and the documentation subdomain.

1. Page speed, mobile and desktop

Run each sample page through PageSpeed Insights on both strategies. Record both Performance scores and judge on the mobile figure. Marketing sites built on React or Next.js frequently ship a JavaScript bundle sized for an application rather than a landing page, so check the "Reduce unused JavaScript" and "Reduce JavaScript execution time" diagnostics specifically.

Record: mobile and desktop score per page, plus unused JavaScript and execution time figures.

2. Core Web Vitals

From the same reports, record LCP, INP, and CLS. Use the field data at the top of the report, drawn from real Chrome users, in preference to the lab data below it. If there is no field section, the site lacks the traffic to appear in the Chrome UX Report; note that and treat the lab numbers as indicative. Pay particular attention to CLS on the pricing page, where a late-loading plan table shifts content at the exact moment somebody is deciding.

Thresholds: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1.

Record: the three values per page, field or lab, and the Search Console Core Web Vitals status bands.

3. HTTPS and SSL certificate

Confirm HTTPS is enforced and that HTTP redirects in a single hop. Check the certificate issuer, coverage, and expiry via the padlock, then run the domain through SSL Labs. Check the app subdomain separately; it frequently has a different certificate and a different configuration from the marketing site.

Record: redirect behavior and hop count, certificate expiry and issuer for both marketing and app hosts, SSL Labs grade.

4. Mobile responsiveness of commercial pages

In DevTools device emulation at 390 by 844, load the pricing page, a feature page, and the trial page. Pricing tables are the usual failure: three or four plan columns that either overflow horizontally or collapse into an order that puts the wrong plan first. Check that plan comparison remains possible, that the trial CTA is reachable without pinch-zooming, and that form fields are usable.

Record: per commercial page, whether the layout holds, how the pricing table degrades, and screenshots of any breakage.

5. JavaScript rendering and content parity

This is the highest-value check on a SaaS site. Fetch the raw HTML for the homepage and a feature page, either through "View page source" or curl -s https://yourdomain.com/page. Then inspect the rendered DOM in DevTools Elements. Compare: is the H1 in the raw HTML? The body copy? The navigation links? The canonical and meta description? Confirm with the Rich Results Test, which shows the rendered HTML Google actually produced.

Record: for each of H1, body copy, navigation links, canonical, and meta tags, whether it appears in raw HTML, rendered DOM, or both.

6. Robots.txt and XML sitemap

Open yourdomain.com/robots.txt and read the whole file, then do the same for the app and docs subdomains, each of which has its own. Look for rules that block feature, integration, or pricing paths. Then open the sitemap, confirm it is valid XML, sample 15 to 20 URLs for 200 status and canonical form, and confirm no app or login URLs are listed.

Record: robots.txt contents per host, any rule affecting marketing pages, sitemap URL count, sampled URL failures, and any app URL found in the sitemap.

7. App subdomain handling

Establish where the application lives and what happens when a crawler reaches it. Request the app root and a logged-out dashboard URL and record the status code and any noindex directive. Then search site:app.yourdomain.com in Google and count the indexed results. Zero is the target. Anything above zero is login walls and empty states appearing in search under your brand.

Record: app host, status codes and robots directives for logged-out app URLs, and the site: indexed count.

8. Canonical tags and duplicate URLs

On each sample page, view the source and confirm a self-referencing absolute HTTPS canonical. Then test the SaaS-specific duplicate paths: the same page with a UTM parameter appended, with and without a trailing slash, and any page that exists under two routes (for example /features/reporting and /product/reporting). Each variant should carry the canonical of the original.

Record: per page, whether the canonical is present, self-referencing, and absolute; plus any duplicate route returning 200 with no canonical.

9. Structured data

Run the homepage, pricing page, and a feature page through the Rich Results Test and the Schema Markup Validator. Record which types are detected. For SaaS the relevant set is SoftwareApplication or Product, Organization, FAQPage where genuine Q and A exists, BreadcrumbList, and Article on blog content.

Record: types detected per page type, error and warning counts, and any commercial page with no structured data at all.

10. Indexation health

In Search Console, go to Indexing, then Pages. Record indexed and not-indexed totals, then open the reason breakdown. On SaaS sites the reasons that matter most are Crawled - currently not indexed on thin feature or integration pages, and Duplicate without user-selected canonical on parameterized URLs. Confirm that pricing, every feature page, and the trial page appear in the indexed set.

Record: indexed and not-indexed counts, the full reason breakdown, and the index status of every commercial page individually.

Section 2: How do you check on-page SEO across the funnel?

SaaS on-page problems are rarely about tags being missing. They are about pages that read as brand positioning when the query behind them is a product search.

11. Title tags

Export the title column from your crawl. Check for missing and duplicate titles first, then read them. The two SaaS-specific failures are feature pages titled "{Product} | Features" rather than naming the capability, and a pricing page whose title does not contain the word "pricing", which is the exact term people search.

Record: missing and duplicate titles, every feature page title that does not name its feature, and whether the pricing title contains "pricing".

12. Meta descriptions

Export the descriptions and check the commercial pages only. Google rewrites the majority of meta descriptions and the tag is not a ranking factor, so this is a click-through exercise, not a site-wide project. Write them properly for pricing, trial, comparison, and top feature pages, where the description functions as ad copy for a decision-stage searcher.

Record: missing or duplicated descriptions on commercial pages, and whether each says something specific rather than restating the brand tagline.

13. Heading structure

Check each sample page has exactly one H1, that headings descend in order, and that the H2s read as an outline. On feature pages, the H2s should name capabilities, not stages of a story; "Real-time reporting" is a heading, "How it works" is a placeholder. On the pricing page, plan names should sit in headings rather than in styled divs.

Record: pages with no H1 or multiple H1s, hierarchy breaks, and the H2 outline for each commercial page.

14. Homepage positioning and the H1

Read the homepage H1 on its own and ask what category of software it describes. "Work better, together" describes nothing. "Project management software for remote teams" describes a category, a use case, and a buyer. Then check whether the ideal customer is named anywhere above the fold. This is the check that most often explains why a product ranks for its brand name and nothing else.

Record: the exact H1 text, whether it contains a category term, and whether the target customer is named above the fold.

15. Pricing page SEO

Confirm the pricing page exists, returns 200, and is not noindex. Check the title and H1 for the word "pricing". Then check whether prices are actually published as text, or hidden behind "Contact sales" or locked inside an image. Published pricing ranks for a decision-stage query and gets quoted by AI answers; hidden pricing forfeits both.

Record: indexability, title and H1 wording, whether prices are plain text, plan names present, and whether an FAQ block exists.

16. Feature page architecture

Map how features are presented. Does each core capability have its own URL, its own title, its own H1, and body copy describing it, or are twelve features listed on a single /features page? One page cannot rank for twelve distinct capability queries. Count how many features the product has and how many have a dedicated indexable page.

Record: total core features, number with a dedicated URL, and the list of features with no page of their own.

17. Content depth on commercial pages

Read the feature and use-case pages as a buyer evaluating three products in a browser with three tabs open. Ask whether the page explains what the feature does, who it is for, what it replaces, and what its limits are. Marketing copy that says "powerful", "flexible", and "intuitive" without a single specific is the finding. Word count is a symptom here, not a target.

Record: per commercial page, a one-line completeness judgement and the questions it fails to answer.

18. Internal linking

In the crawl, check the inlink count for pricing, each feature page, and the trial page. Then check the direction of flow: do blog posts link to the feature pages they are topically about, or do they all link to the homepage? Do feature pages link to each other and to the trial? Run the orphan report to find feature or integration pages nothing points at.

Record: inlink counts for commercial pages, whether blog content links to features, and the orphan list.

If working through this on your own product is more time than you want to spend, a SaaS SEO audit covers the same ground and arrives prioritized.

Section 3: How do you check funnel keyword coverage?

SaaS buyers move through three distinct search modes, and most products are visible in only one of them. This section establishes which.

19. Funnel stage keyword coverage

In Search Console, go to Performance, Search results, set the range to three months, and export all queries. Then bucket them into three groups: awareness ("{category} software", "how to {outcome}"), consideration ("best {category} tools", "{product} vs {competitor}", "{competitor} alternatives"), and decision ("{product} pricing", "{product} review", "{product} free trial"). Count clicks per bucket.

Record: clicks and impressions per funnel stage, and which stage is thinnest.

20. Comparison and "best of" visibility

Search "best {category} software", "{product} vs {top competitor}", and "{top competitor} alternatives" in an incognito window. Record what ranks: your pages, competitor pages, or review platforms and listicles. Then check whether your site has a page targeting each of those query shapes at all. Most products discover here that they have no comparison content and are ceding the highest-intent queries in the category entirely.

Record: per query, the top five results, and whether you have a page targeting it.

21. Ranking keywords overview

Back in the Performance report, sort by impressions and read the top 20 queries. Count how many are non-branded and how many of those sit on page one. This is the plainest measure of whether search is acquiring anybody new.

Record: total clicks, the top 20 queries with position and CTR, and the count of non-branded page-one queries.

22. Branded versus non-branded split

Filter queries containing the brand name and record clicks, then invert the filter and record clicks again. Calculate the split. For a SaaS product a heavily branded profile usually means search is functioning as a login shortcut for existing users rather than as an acquisition channel.

Record: branded clicks, non-branded clicks, and the percentage split.

23. Keyword mapping and cannibalization

List your key pages and, for each, write down the single query it is meant to win. Then look for collisions: two feature pages targeting the same capability term, a blog post competing with the feature page it should be feeding, a use-case page overlapping a feature page. Confirm in the Search Console Pages tab, filtering by query to see which URL Google actually chose.

Record: the page-to-query map, every collision, and which URL Google currently ranks for each contested query.

24. Keyword placement

For each commercial page, check whether its intended query appears in the title, the H1, the first paragraph, and at least one H2. This is a coverage check, not a density calculation; density targets stopped meaning anything years ago. What you are looking for is a page that never plainly says what it is.

Record: per commercial page, the intended query and which of the four positions it occupies.

25. Search intent alignment

Take your top 10 non-branded queries and search each in an incognito window. Note the dominant result format: product pages, guides, listicles, review platforms, or Reddit threads. Compare with the page type you have pointed at that query. A feature page competing in a results set made entirely of listicles will not win by being improved; it needs different content pointed at the query.

Record: per query, the dominant format, your page type, and whether they match.

Section 4: How do you check the trial and demo pages?

Three checks on the pages where organic traffic either becomes revenue or does not.

26. Trial, demo, or signup page SEO

Identify the primary conversion page and confirm it returns 200 and is not noindex. Check whether it targets a query at all; "{product} free trial" and "{product} demo" are real searches with real volume. Read the page as somebody who arrived cold from Google rather than from a nurture email, and ask whether it explains what happens after they click.

Record: indexability, title and H1, whether the offer is stated plainly, and what the page assumes the visitor already knows.

27. Trust signals on conversion pages

Count the trust signals on the pricing and trial pages: customer logos, named testimonials, G2 or Capterra badges with a real rating, security and compliance marks such as SOC 2 or GDPR, "no credit card required", and any guarantee. Organic visitors arrive without the warm-up of an ad sequence or a sales call, so these pages carry more of the persuasion load than the team usually assumes.

Record: the trust signals present on each conversion page, and which of the categories above are absent.

28. CTA clarity and conversion architecture

On each key page, identify the single primary action, check it appears above the fold, and read the button text. Then count competing actions. A feature page offering "Start free trial", "Book a demo", "Download the guide", and "Talk to sales" in the same viewport is offering nothing. Check that the action matches the funnel stage: blog posts should not lead with "Talk to sales".

Record: per page, the primary action, its exact button text, its position, and the number of competing actions.

Section 5: How do you check feature, integration and programmatic pages?

This is where most SaaS products have the largest untouched keyword surface, and it is usually a structural problem rather than a content problem.

29. Integration pages

List every tool your product integrates with. Then check how those integrations are presented: individual pages with their own URL, title, H1, and explanatory copy, or a single /integrations grid of logos. Search "{your product} {integration name}" for three or four of the larger integrations and see whether anything of yours ranks. These queries come from users of the other tool who are actively checking whether you fit their stack.

Record: total integrations, number with a dedicated indexable page, and ranking status for three sampled integration queries.

30. Use case and persona pages

Check whether the site has pages targeting specific buyer types or scenarios: "/for-agencies", "/for-remote-teams", "{category} software for {industry}". Confirm they are genuinely differentiated rather than the homepage with one word swapped, and that they link to the relevant feature pages. Note which of your two or three main personas have no page at all.

Record: existing use-case and persona pages, how differentiated each is, and the personas with no page.

31. Programmatic SEO opportunity

Inventory the repeatable data the product owns: integrations, supported industries, job roles, templates, locations, supported file types. For two or three of these categories, search a sample combination and check whether autocomplete suggests it and whether competitors have built pages for it. Then confirm whether your stack can generate templated pages at all, because a validated opportunity you cannot build is not an opportunity this quarter.

Record: data categories owned, evidence of demand per category, competitor precedent, and whether the CMS supports templated generation.

Section 6: How do you check content and competitors?

Seven checks that place the product against the sites actually occupying its results.

32. Blog and content hub

Confirm a blog or resource hub exists, count published posts, and note the date of the most recent one. Then check the direction of the links: does blog content point at the feature pages it relates to, or does every post end at the homepage? An abandoned blog is a weaker signal than no blog, because the last-updated date is visible.

Record: post count, last publish date, publishing frequency over the last six months, and whether posts link to product pages.

33. Content gap against competitors

Search 10 to 15 of your target non-branded queries manually and record who ranks. Where a competitor ranks and you are absent, open their page and classify it: guide, comparison, integration page, use-case page, glossary entry, template. The gap is usually a content format you have not built rather than a keyword you have not targeted.

Record: query-by-query rankings, and the content formats competitors have that you do not.

34. Identify the top three organic competitors

Search three to five of your primary non-branded terms in an incognito window and note which domains recur in the top five. Then do the same for "best {category} software". Your organic competitors frequently include G2, Capterra, and a handful of blogs, which are not competitors you can acquire but are results you have to work around.

Record: recurring domains with the queries each ranks for, separating product competitors from platforms and publishers.

35. Compare authority

Run your domain and each product competitor through SEOptimer and record the domain strength figure for each. The number is relative and only means anything when the same tool is used across all domains. What you want from it is calibration: whether you are chasing peers or chasing sites with a five-year head start.

Record: domain strength per domain and the approximate gap to the strongest competitor.

36. Review platform profiles

Search your product on G2, Capterra, and Product Hunt. For each, check the profile exists and is claimed, the description is complete, the category is correct, and the screenshots are current. Then record the review count and rating, and do the same for your two main competitors. A product with 12 reviews does not get recommended over one with 400, on the platform or by anything reading it.

Record: per platform, claimed status, completeness, category, review count and rating for you and each competitor.

37. Competitor content benchmarking

Open your top two product competitors and count: feature pages, integration pages, use-case pages, comparison pages, and blog posts published in the last six months. Put the numbers next to your own. This produces the clearest single table in the audit and usually explains the ranking difference without further analysis.

Record: the page-type counts for each competitor and for you, side by side.

38. SERP feature opportunities

Search 5 to 10 target queries and note which features appear above the organic results: AI Overview, featured snippet, People Also Ask, video, and review platform listings in the top three. Record which competitor content is winning the snippets and what format it is in.

Record: per query, the SERP features present, whether you appear in any, and which domain wins each snippet.

Section 7: How do you check the backlink profile?

Three checks. Search Console is limited compared with a paid backlink tool, but it is accurate about your own domain.

39. Referring domains

Go to Links, then Top linking sites. Record the total and scan the top 20, noting what each linking site actually is. For SaaS, the healthy pattern includes review platforms, integration partners' directories, tech press, and newsletters. A count inflated by one syndicated directory listing is not a link profile.

Record: total linking sites, total external links, and the top 20 domains with a note on each.

40. Anchor text distribution

Open Links, then Top linking text. Bucket the anchors into branded, exact-match commercial, generic, and bare URL. A product with organic coverage is branded-heavy, because journalists and partners link with the product name. A profile dominated by exact-match commercial anchors is a bought profile, whether or not the current team bought it.

Record: the anchor list with an approximate percentage per bucket.

41. Competitor link gap

Compare your referring domain count with your two main competitors using the domain strength figures from check 35 and their visible review platform and partner directory presence. Then list the specific link sources they have that you do not: integration partner directories, category listings, tech press coverage, podcast or newsletter mentions.

Record: the approximate gap, and a named list of link sources competitors hold and you do not.

Section 8: How do you check UX and conversion?

Rankings that do not convert to trials are a cost center. Five checks, all quick.

42. Signup and trial flow friction

Start a trial signup yourself in an incognito window and count the required fields. Note whether a credit card is required before the trial begins, whether social or SSO login is offered, how many steps there are before the product is usable, and whether email verification blocks the first session. Cold organic traffic drops off at each of these in a way that warm traffic does not.

Record: field count, credit card requirement, login options, step count, and where verification sits in the flow.

43. Page layout and readability

Read the feature and pricing pages at mobile width. Look for paragraphs longer than four lines, feature descriptions written as prose where a list would work, and comparison information that cannot be scanned. Buyers scan before they read; a page that requires reading to be understood loses to one that does not.

Record: per commercial page, the specific sections that are dense or unscannable.

44. Engagement metrics

In GA4, go to Reports, Engagement, Pages and screens, and filter to organic traffic only. Record engagement rate and average engagement time for the homepage, pricing page, and top feature pages. Remember GA4's engagement rate is the inverse of the old bounce rate; a 40% engagement rate means 60% of sessions were not engaged.

Record: engagement rate and average engagement time per commercial page, organic sessions only.

45. Accessibility basics

Check the lang attribute on the <html> element, whether form inputs on the signup page have associated labels, whether images carry alt text, and whether the primary CTA colors pass contrast. Beyond the obvious reasons to care, enterprise procurement increasingly asks for a VPAT or an accessibility statement, and finding out during a deal is worse than finding out now.

Record: lang attribute present, labelled inputs on key forms, images missing alt text, and any failing contrast on primary actions.

46. Funnel coherence

Trace one journey end to end: a blog post, to the feature page it relates to, to pricing, to trial. At each step, ask whether there is an obvious next action and whether the messaging carries over. Most SaaS funnels break at the first joint, where blog content offers no route into the product at all.

Record: the traced path, and the specific step where the journey breaks.

Section 9: How do you check AI search visibility?

SaaS is the category most exposed to answer engines, because "what is the best tool for X" is exactly the question buyers now type into ChatGPT before they open Google. Six manual checks.

47. Recommendation presence in answer engines

Ask ChatGPT, Perplexity, and Gemini the questions a buyer would: "best {category} software", "best {category} tool for {use case}", "{category} tools for startups". Note whether your product appears and where in the list. Then ask "{your product} vs {top competitor}" and check whether the engine has enough accurate information to compare fairly. Record which sources each answer cites, because that list is where the recommendation is actually being decided.

Record: per engine and query, whether the product appears, its position, and the cited sources.

48. Google AI Overview presence

Search your category, comparison, and "best X for Y" queries in an incognito window. Note whether an AI Overview appears and expand the citation list. Comparison and alternatives queries trigger overviews often and sit at the highest intent, so weight those. The queries where an overview appears and cites only competitors are your priority list.

Record: per query, whether an overview appears, the cited domains, and whether yours is among them.

49. Review platform citation footprint

This extends check 36 into the AI dimension, because the engines lean heavily on these sources. Compare your G2 and Capterra review volume, average rating, and date of the most recent review against your two main competitors. Then search Reddit for your category and your product name, and read the sentiment; Reddit is cited disproportionately often by answer engines.

Record: review volume, rating, and recency for you and each competitor, plus Reddit mention count and sentiment.

50. Answer-ready product content

Check whether pricing exists as plain text rather than an image or a "contact us" wall, whether a comparison or alternatives page exists for engines to quote, and whether feature pages answer their core question in the first paragraph. Engines cannot compare what they cannot read, and cross-reference this with check 5: content that only exists after JavaScript execution is content some engines never see.

Record: whether pricing is plain text, whether comparison content exists, and per feature page, how far down the direct answer sits.

51. Product entity and structured data

Run the homepage and key pages through the Rich Results Test and the Schema Markup Validator. Look for SoftwareApplication or Product, and Organization with a populated sameAs array linking to your G2, Capterra, LinkedIn, and Crunchbase profiles. The sameAs array is the thing most often left empty, and it is what ties your site to your off-site review footprint in a way machines can follow.

Record: markup types found, missing fields, and the full sameAs list if present.

52. AI crawler access and documentation indexability

Open yourdomain.com/robots.txt and search for GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot, and Bytespider, recording whether each is allowed, blocked, or unmentioned. Then do the same for the docs or help subdomain, and check whether documentation is indexable at all. Engines cite docs constantly when answering "how do I do X in {product}", and gated or noindex docs forfeit all of it. Finally, request yourdomain.com/llms.txt and note the response.

Record: the directive for each user-agent on each host, whether any block was intended, docs indexability, and the llms.txt status code.

FAQ

How long does a SaaS SEO audit take?

Five to eight hours for a first full pass if you know the tools, spread over a couple of days. The rendering check and the feature page inventory take the longest. The AI search section takes under an hour and is usually where the surprises are, because most teams have never asked ChatGPT what it says about their product.

What is different about auditing a SaaS site?

Four things: client-side rendering can hide content from crawlers entirely, the app subdomain has to be excluded from the index without catching the marketing site, pricing and feature page structure decides most of the commercial keyword surface, and review platforms carry more weight than backlinks for both rankings and AI recommendations.

Do I need paid SEO tools for this?

No. Every check above runs on Search Console, PageSpeed Insights, Chrome DevTools, the free Screaming Frog tier, GA4, and free validators. Paid tools save real time on keyword gap analysis and backlink data once you are past a few hundred URLs, but they do not surface a category of problem the free set misses.

How is this different from a general website audit?

A website SEO audit covers local SEO, generic conversion checks, and a standard keyword review. This one drops local entirely and replaces it with funnel-stage keyword mapping, trial and pricing page checks, integration and programmatic opportunity, and review platform footprint. The technical layer also adds rendering and app subdomain checks that a brochure site never needs.

When should a SaaS company run its first audit?

Once there is a marketing site with more than a handful of pages and Search Console has three months of data. Before that there is nothing to measure. If you are earlier than that, the question is when to start SEO at all, which is a different decision.

Closing

Most SaaS SEO problems are structural rather than cosmetic: one features page instead of twelve, pricing behind a contact form, docs set to noindex, a trial flow that asks for a credit card. Those are decisions, and decisions are cheaper to change than rankings are to earn. If you would rather have the whole picture gathered and prioritized for you, a SaaS SEO audit covers all 52 points, and the implementation can be handled from there.

The logic seems reasonable: buy traffic, get sales. But if your product pages are slow, your descriptions are thin, and your site has no structured data, paid visitors bounce at roughly the same rate as organic ones. You are paying for a bad result, not avoiding it.

In short: Organic search drives around 43% of e-commerce traffic, making it the single largest channel. Running ads on a site that isn't ready to convert means paying per click to confirm the problem. The better sequence: run an seo audit, fix the foundation, then amplify with ad spend.

Where Does E-Commerce Traffic Actually Come From?

Organic search is the dominant traffic source for online stores, accounting for roughly 43% of all e-commerce traffic. Social media, direct visits, email, and paid search each contribute, but none individually comes close.

This matters for budget allocation. If nearly half your potential visitors arrive through search and your site ranks poorly for the terms your customers actually use, that is not a paid advertising problem. It is an SEO problem. Ads can fill the gap temporarily; they cannot solve it structurally.

Most store owners treat organic traffic as a bonus. In practice, it is the baseline that everything else builds on.

What Happens When You Run Ads on a Broken Site

Paid traffic is not a different kind of visitor. Someone who clicks an ad lands on the same product page, faces the same three-second load time on mobile, and sees the same thin 40-word description as anyone who arrived from search.

If those pages do not convert organic visitors, they will not convert paid ones either. The cost-per-acquisition stays high and the conversion rate stays low, not because the ad targeting is wrong, but because the site itself is not ready.

The issues that hurt organic rankings are the same ones that hurt conversion: poor content quality, missing schema markup, slow Core Web Vitals, no mobile optimisation. These are the same problems covered in the e-commerce SEO checklist. Fixing them improves every channel simultaneously, including paid.

The ROI Gap: SEO vs Paid Over 12 Months

The honest comparison here is not "SEO is free and ads cost money." SEO takes time and investment to do properly. But the compounding effect is real and the maths eventually favours it.

Ad spend produces results in direct proportion to budget. When the budget stops, the traffic stops. SEO rankings accumulate over time; a category page that ranks well in month nine continues generating traffic in month eighteen without an additional cost per click.

E-commerce SEO delivers around 317% ROI with a break-even point at roughly nine months, based on available industry benchmarks. Over the same period, paid search CPCs rose approximately 13% year-over-year in 2025. The cost of buying traffic is rising; the cost of ranking well is not.

Neither channel is the right answer in isolation. The argument is about sequence, not which one to choose permanently.

What an SEO Audit Finds That an Ad Dashboard Doesn't

An ad dashboard tells you what is happening: click-through rate, cost per acquisition, ROAS, conversion rate. It does not tell you why.

An SEO audit examines the underlying site. Crawlability problems that prevent pages from being indexed. Content gaps where competitors rank and you do not. Technical debt slowing down page loads. Keyword coverage mismatches between what you target and what people search for. Backlink patterns that hold the domain back.

Fix the underlying site and every channel benefits. This is what most people actually mean when they talk about an e-commerce SEO audit and why we frame ours across 46 points covering technical health, content, keywords, backlinks, and competitor positioning, not just rankings.

An ad dashboard cannot surface any of this. It measures the outcome; the audit identifies the cause.

The Right Order: Audit, Fix, Then Amplify

The sequence that produces the best return on total marketing spend is not complicated.

First, audit the site. Identify what is broken, what is missing, and where the gaps are relative to the competitors who are outranking you. This is the diagnostic phase; without it, fixes are guesses.

Second, fix the issues. Product page content, category page copy, page speed, schema markup, internal linking structure. None of these are instant, but all of them are finite. There is a bottom to the list.

Third, run ads. At this point, paid traffic lands on pages that are built to convert. Cost per acquisition drops. Organic rankings improve in parallel. Both channels perform better because the foundation is solid.

The reverse order, ads first and site optimisation later, means paying to send traffic to a store that is not ready for it.

When Ads Do Make Sense (Even Before SEO Is Perfect)

This is not a case against advertising. There are situations where paid campaigns make sense before SEO work is complete.

New product launches are the clearest example. A product with no ranking history cannot rely on organic search. Ads bridge that gap while organic authority builds. Seasonal or time-limited promotions are another case; organic search cannot respond fast enough to a two-week sale, and paid can. Testing keyword intent before committing budget to a content strategy is also a legitimate use of paid campaigns.

The distinction is purpose. Ads used for testing, timing-sensitive promotions, or bridging a new launch are a deliberate tool. Ads used as a substitute for a site that doesn't perform are an ongoing cost attached to a fixable problem.

FAQ

Should I stop running ads while fixing my SEO?

No. Pausing profitable ad campaigns while working on SEO is rarely necessary. The two can run in parallel. The goal is to make the site better so that both channels produce better results; that process does not require switching paid off. If campaigns are unprofitable before SEO is addressed, that is worth examining separately.

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

For most e-commerce sites, meaningful movement in organic rankings begins between three and six months. Stable rankings with compounding traffic growth typically require nine to twelve months. This assumes technical issues are identified and resolved early; unaddressed problems extend that timeline considerably.

What is the difference between an SEO audit and a marketing audit?

A marketing audit reviews channel performance: spend, efficiency, and campaign results. An SEO audit examines the site itself; crawlability, indexation, content quality, keyword coverage, technical performance, and backlink profile. For e-commerce businesses, the SEO audit belongs first because site-level problems affect every channel including paid.

Is organic traffic really free?

Not exactly. Organic traffic has no cost per click, but generating it requires investment in content, technical work, and time. The difference from paid is that the investment is largely upfront, and the traffic it produces does not stop when the spend stops. Over a 12-to-24 month horizon, the unit economics tend to look significantly different.

If you are currently spending on ads and have not looked closely at how the site is performing on search, an e-commerce SEO audit is a useful starting point. The audit takes a few days; the issues it identifies, fixed once, continue paying off long after the work is done. If you want a sense of what we typically find in stores at different stages, the e-commerce SEO checklist is a useful read first.

Most ecommerce SEO problems are structural. A store rarely loses organic traffic because of one bad title tag. It loses traffic because the same product sits at four different URLs, category pages contain nothing but a product grid, and filtered views have quietly generated eleven thousand indexable pages. This ecommerce SEO audit checklist covers the 52 checks that surface those problems. It is deliberately limited to data gathering: what to look at, which tool to use, and what to write down. Deciding what the numbers mean, and what to fix first, is a separate job that gets much easier once the data is in front of you.

In short: An ecommerce SEO audit covers eight areas: technical health, on-page elements, product and catalog structure, keyword coverage, competitors, backlinks, conversion UX, and AI search visibility. Running all 52 checks yourself takes roughly four to eight hours for a mid-sized store, using Google Search Console, PageSpeed Insights and a crawler.

What do you need before you start?

Five tools cover almost everything. Only one of them costs money, and there is a free tier that will get you through a small store.

Two decisions to make before you begin. First, pick your sample: the homepage, your three biggest category pages, five to ten representative product pages (including one with variants and one out of stock), and one blog or guide page if you have them. Auditing every product page on a 4,000-SKU store is not useful and not necessary. Second, set your Search Console date range to the last three months and keep it consistent across every check, otherwise the numbers will not line up later.

If you have already run a general technical review, several checks below will look familiar. The overlap is intentional; the technical SEO audit checklist goes deeper on crawling, rendering and security, while this one covers the catalog-specific layer that a generic audit misses.

Technical SEO checks (1 to 12)

Ecommerce platforms generate URLs faster than anyone can manage them. This section is about finding out how many exist and which ones search engines are actually spending time on.

1. Page speed. Run PageSpeed Insights on the homepage, your top category page and a top product page, on both mobile and desktop. Record all six performance scores. Product pages are usually the slowest because of image weight and review widgets.

2. Core Web Vitals. From the same PageSpeed runs, record LCP, INP and CLS for each page. Note whether the results come from field data (real users) or lab data only, since a store with low traffic will often have no field data at all.

3. HTTPS and SSL. Load the http:// version of the homepage and record whether it returns a 301 to https://. Check the certificate expiry date and issuer. Run SSL Labs if you want the full picture.

4. Mobile rendering. Open a product page on an actual phone, not just DevTools device mode. Record whether the image gallery swipes, whether size and color selectors are tappable, whether the add-to-cart button is reachable, and whether category filters work on touch.

5. XML sitemap and robots.txt. Fetch /sitemap.xml and /robots.txt directly. Record the total URL count, whether the sitemap is split by type (products, collections, pages, blog), and whether any product or collection path appears in a Disallow rule.

6. Canonical tags. Find a product that belongs to more than one collection and load it via both paths, for example /products/item and /collections/collection/products/item. Record the canonical URL each version returns. This single check catches the most common duplication problem in ecommerce.

7. URL structure. Export the full URL list from your crawler. Record the maximum click depth, how many URLs contain query parameters, and whether any category URLs use numeric IDs instead of readable slugs.

8. Product schema. Run three or four product pages through the Rich Results Test. Record which fields are present: name, image, sku, brand, offers with price, priceCurrency and availability, and aggregateRating. Note errors separately from warnings.

9. Pagination. Open a category page with more products than fit on one screen. View the raw page source (not the rendered DOM) and record whether links to page two and beyond exist as standard <a href> elements. If products load via infinite scroll or a JavaScript "Load More" button with no fallback links, write that down.

10. Tag and filter pages. Click a filter on a category page and record whether the URL changes. If it does, run a site: search in Google for that URL pattern and record how many are indexed. Check one of those pages for a noindex directive or a canonical pointing back to the parent category.

11. Redirect chains and broken links. Crawl the site and export the response codes report. Record the number of 3xx responses, the longest redirect chain in hops, and the count of internal 4xx links along with which pages they sit on.

12. Crawl budget and index bloat. In Search Console, open Indexing then Pages. Record the indexed count, the not-indexed count, and the breakdown by reason, particularly "Crawled - currently not indexed" and "Discovered - currently not indexed". Then compare the indexed count against your actual product plus category count.

On-page checks for product and category pages (13 to 20)

These are standard on-page checks, but the volume changes how you run them. On a store with 2,000 products you are looking at a crawl export, not individual pages.

13. Title tags. From the crawl export, record how many titles are missing, duplicated, over 60 characters, or under 30. Sort duplicates by count to see whether the pattern is template-driven.

14. Meta descriptions. Same export. Record missing and duplicate counts, and check whether product descriptions are hand-written or auto-pulled from the first line of body copy.

15. Heading structure. Record pages with zero H1s and pages with more than one. On product pages, check whether the H1 matches the product name and whether H2s break the description into sections.

16. Image optimization and alt text. Export the images report. Record the number of images missing alt text, the number over 100KB, and which formats are in use. Note whether product photos carry descriptive alt text or filenames like IMG_3421.

17. Internal linking. Export the inlinks report. Record the average number of internal links pointing to product pages, identify any orphan pages, and note whether the homepage links directly to your main categories.

18. Category page content. For your top five categories, record the word count of text outside the product grid. Many stores score zero here, which is worth knowing precisely.

19. Content depth versus competitors. Search your three main category keywords. For each of the top three ranking pages, record the word count and what content types appear: buying guides, FAQs, comparison tables, video.

20. Open Graph tags. View source on a product page and record whether og:title, og:description, og:image, og:type and og:url are present, and whether og:image resolves to the primary product photo.

Product and catalog checks (21 to 28)

This is the section a generic SEO audit does not have, and it is usually where the largest problems sit.

21. Product page SEO quality. Take ten sample products and record five things per page in a single table: title tag, meta description, H1, canonical URL, and whether product schema is present. Reviewing them as a unit makes template-level failures obvious.

22. Product description depth. For those same ten products, record the description word count. Then take one distinctive sentence from each, search it in Google inside quotation marks, and record how many other sites return the identical text. That tells you whether the copy is manufacturer-supplied.

23. Category architecture. Map the hierarchy from the navigation menu and breadcrumb trails. Record how many levels deep it goes, how many categories are reachable from the main navigation, and whether subcategories exist as real pages or only as filters.

24. Variant handling. On a product with multiple sizes or colors, click through each variant and record whether the URL changes, whether the canonical changes with it, and whether variant images have their own alt text.

25. Out-of-stock and discontinued products. Find an out-of-stock product and record its HTTP status code and whether the page offers a back-in-stock option. Then find a product that has been discontinued and record whether the URL 404s, redirects, or still resolves.

26. Faceted navigation. Count the filter dimensions on your largest category page and the number of options within each. Apply two filters at once and record whether the resulting URL is crawlable and indexable. Check robots.txt and meta robots for any rules covering those parameters.

27. Product image SEO. Beyond alt text, record image filenames, how many angles each flagship product has, whether an image sitemap exists, and whether the schema image field points to the primary photo.

28. Reviews on product pages. Disable JavaScript or compare raw source against the rendered page, and record whether review text appears in the HTML or only loads from a third-party widget. Record the review count and average rating for your top products, and whether AggregateRating schema is present.

If pulling all of this on a large catalog is more work than you want to take on, our ecommerce SEO audit runs the same 52 checks and returns the findings written up.

Keyword, competitor and backlink checks (29 to 41)

Everything here is comparative. The point is not what your store ranks for in isolation, but where the gap sits between you and the stores taking your traffic.

29. Current ranking queries. In Search Console, open Performance then Search results. Sort by impressions and record the top 20 queries with position, CTR and clicks. Tag each one as branded, product, category, or informational.

30. Category keyword coverage. List your five to ten core categories. Search each one the way a buyer would, in incognito, and record whether your store appears anywhere in the top 20 and which page ranks.

31. Long-tail and modifier keywords. For each core category, record the Google autocomplete suggestions and the "People Also Ask" questions. Note which modifier types appear: brand, material, color, price, use case, audience. Then record whether you have a page targeting each pattern.

32. Quick-win keywords. In Search Console, filter Performance to positions 4 through 20 and sort by impressions. Record the queries with meaningful impressions and the page currently ranking for each.

33. Keyword gap. Using your competitor list from check 35, record product and category keywords where competitors have visibility and you have none.

34. Branded versus non-branded split. In Search Console, filter queries containing your brand name and record the click total. Compare against total clicks and record the ratio.

35. Top three organic competitors. Search your core category keywords in incognito and record which domains appear repeatedly in the top five. Include marketplaces such as Amazon or Etsy if they show up, since they compete for the same clicks whether or not you consider them rivals.

36. Domain strength comparison. Run your domain and each competitor through the same tool, whichever you use, and record the authority score, referring domain count and indexed page count side by side.

37. SERP features and shopping carousels. For your top ten commercial keywords, record which features appear: shopping carousel, product knowledge panel, image pack, People Also Ask, featured snippet. Record whether your products appear in any of them and which competitors do.

38. Content gap. Record the content types competitors publish that you do not: buying guides, "best of" roundups, comparison articles, how-to content, video.

39. Backlinks and referring domains. Record total backlinks and unique referring domains for your store and each competitor from check 35.

40. Toxic backlinks. Scan your referring domain list and record any obvious patterns: irrelevant foreign-language sites, link networks, repeated exact-match anchor text.

41. Competitor link gap. Record domains that link to at least two competitors but not to you, sorted by relevance.

Cart, checkout and conversion checks (42 to 46)

Organic visitors arrive cold. They have no ad context, no prior brand exposure, and no reason to trust the store yet.

42. Navigation. Record the number of top-level navigation items, whether a search bar is visible without scrolling, whether breadcrumbs appear on product pages, and whether the menu structure matches the category hierarchy from check 23.

43. Cart and checkout indexation. Load /cart and /checkout and record whether each carries a noindex directive. Run a site: search for cart and checkout URLs and record how many are indexed. Note whether checkout hands off to a different domain.

44. Trust signals. On a product page, record which of these are visible: payment method icons, return policy link, shipping cost or threshold, delivery timeframe, customer reviews, third-party trust badge, and a contact method that is not a form.

45. Layout and readability. On mobile, record whether price, availability and the add-to-cart button are visible without scrolling, and how far down the page the product description begins.

46. Conversion funnel trace. Walk the full path yourself: Google result, category page, product page, add to cart, checkout. Record the number of clicks, the number of form fields at checkout, whether guest checkout exists, and any point where the next action is unclear.

AI search and answer engine checks (47 to 52)

Shopping queries increasingly resolve inside an AI answer rather than a results page. These checks establish whether your products appear there at all.

47. AI Overviews. In incognito, search four to six high-intent commercial queries covering your top categories, "best [product] for [use case]" phrasing, and flagship product names. Record whether an AI Overview appears, which sources it cites, and whether your domain is among them.

48. Assistant recommendations. Ask ChatGPT in search mode, Perplexity and Gemini the same category and use-case shopping questions. Record whether your brand or products are recommended, which competitors are, and which sources each engine cites. The cited sources matter more than the recommendation itself; they show you what needs to change.

49. Product structured data for AI. This extends check 8. Record whether gtin or sku identifiers are present, whether Organization markup includes sameAs links, and whether BreadcrumbList exists on category pages. Flag any product where price, stock or rating is visible on the page but absent from the markup.

50. Review signal strength. For your top five products, record review count, date of the most recent review, and average rating. Record the same for the equivalent competitor products. Note whether ratings appear in Google Shopping results and whether you have a third-party review profile.

51. Buying guide and comparison content. Record whether the store publishes "best [product] for [use case]" guides, "[A] vs [B]" comparisons, or gift guides. For any that exist, record whether the recommendation appears in the first hundred words and whether a comparison table is present.

52. AI crawler access and feed health. Check robots.txt for rules covering GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended and CCBot, and record whether each is allowed, blocked, or unaddressed. Check whether /llms.txt exists. In Google Merchant Center, record the product feed status and the number of disapproved items.

Frequently asked questions

How long does an ecommerce SEO audit take?

Four to eight hours for a store with a few hundred products, assuming Search Console access and a working crawl. Larger catalogs take longer, mainly because export files get unwieldy and faceted navigation takes real time to map. The crawl itself can run unattended, so plan around it rather than waiting on it.

Which checks matter most for Shopify stores?

Checks 6, 10 and 24. Shopify serves the same product at both /products/ and /collections/.../products/ paths, generates an indexable URL for every tag within a collection, and handles variants in ways that vary by theme. These three account for most Shopify duplication problems. Check 23 also matters, since Shopify has no true parent-child collection structure.

Do I need paid tools to run this?

No, though a crawler makes checks 7, 11, 13 to 17 considerably faster. Screaming Frog is free up to 500 URLs, which covers a small store completely. Everything else on this list runs on Search Console, PageSpeed Insights, the Rich Results Test, and your browser.

How often should I run this?

Once fully, then quarterly for the technical and index checks, which are the ones that drift as the catalog changes. Product and content checks are better handled continuously as you add SKUs. Re-run the full checklist after any platform migration, theme change or major catalog restructure.

Gathering the data is the part most stores skip, and it is the part that makes every later decision straightforward. Work through the 52 checks, record the results in one place, and the priorities tend to declare themselves. If you would rather not spend the weekend on export files, an ecommerce SEO audit covers the same ground and comes back with the findings and a fix order.

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 <head> 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 <head> 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.

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:

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:

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:

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 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:

1. 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.

2. 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.

3. 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.

1. The application loader delegates the task to the system class loader.

2. The system loader delegates the task to the bootstrap class loader.

3. 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.

4. 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.

5. 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:

1. 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.

2. Preparation: Once the bytecode is verified, the JVM starts allocating and getting the static variables of the class making them ready to initialize.

3. 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.

4. 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.

1. 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.

2. 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.

3. But if the app loader is not an initiating loader of B, the JVM asks the app loader to load B.

4. Now all delegation steps explained before follow.

5. 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.

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:

1. 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.

2. 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.

3. 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:

1. 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.

2. 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.

3. 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:

1. It can be called manually, explicitely.

2. 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:

1. Custom class loader

2. Custom cache memory to save already loaded classes

3. A transformer

Now, lets say there is a Class A:

1. 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.

2. A hasn't been loaded before, so the loadClass method of my custom class loaders gets called normally.

3. 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).

4. When the A class gets modified, a file watcher gets its new bytecode and changes the name of the new class version to A1.

5. Then the custom cache gets modified, so next time the loadClass method gets called for A, A1 is returned instead.

6. 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.