Metricum Lab
EN UA
Menu
Home
About
Services
Online Tools
Blog
Process
FAQ
Contact
Privacy Policy
Terms
Cookies

Technical SEO · Checklist

Technical SEO Audit Checklist 2026: 42 Checks, Tools & Pass/Fail Criteria

Start with a baseline, collect evidence by URL or template, and close a finding only after you can repeat the original test. Each check gives you the tool, exact location, sample rule, pass criteria and evidence to save.

Metricum LabPublishedUpdated32 min read · 42 checks
Technical SEO Audit Checklist 2026: 42 Checks, Tools & Pass/Fail Criteria

Treat every finding as evidence, not intuition

  • Treat Search Console’s Page indexing report as a pattern detector, not a “fix every Not indexed URL” queue. Expected redirects, duplicates and retired URLs can be correct.
  • A technical finding is implementation-ready only when it names the affected URL or template, observed state, expected state, owner, evidence and acceptance test.
  • Use Google thresholds only where Google publishes them. Crawl depth, inlink counts and resource budgets are audit heuristics, not Google ranking factors.
  • Normal crawlable HTML remains the baseline for Search. Do not create a parallel Markdown or llms.txt copy just to “optimize for AI”.

From discovery to verified fix

The eight systems below form one audit loop. A page can be fast and valid but still fail if Google cannot discover, crawl, render or canonicalize it correctly.

011. Build the audit baseline before changing anything1–5022. Indexation: prove which URLs Google can and should index6–11033. Crawlability, robots.txt, sitemaps and host health12–16044. HTTP status codes, redirects and canonical consistency17–23055. Site architecture and internal linking24–28066. JavaScript rendering and rendered-content parity29–33077. Core Web Vitals and browser-level performance checks34–38088. Structured data, hreflang and final verification39–42

Fix impact before polish

Use this as an implementation triage model, not a Google ranking rule. Prioritize issues that block discovery, rendering or indexation before low-impact cleanup.

Open these tools before the audit

Google Search Console

Indexation, URL Inspection, Crawl Stats and performance evidence

Open tool ↗

Screaming Frog SEO Spider

Raw and JavaScript crawling, status/canonical/internal-link analysis, plus optional GSC, GA4 and PageSpeed API data in the same crawl

Open tool ↗

Chrome DevTools

HTTP headers, network requests, rendered DOM and performance diagnosis

Open tool ↗

PageSpeed Insights

Core Web Vitals field data and lab diagnostics

Open tool ↗

Use one implementation-ready row per finding

Do not hand developers a screenshot-only deck. Put every issue into a backlog where the expected state, evidence, owner and acceptance test are explicit.

FieldWhat to enterExample
URL / patternExact URL or deterministic template pattern/products/*
Issue IDStable identifier used in tickets and verification exportsIDX-07
Observed stateMeasured failure with tool and dateGSC: noindex; 2026-08-21
Expected stateTestable result, not “fix SEO”200 + indexable + self-canonical
EvidenceExport row, screenshot, HAR or crawl filebaseline/indexing.csv
PriorityP1 blocker → P4 cleanup using the matrix aboveP1
OwnerTeam or named function responsible for implementationFrontend / Platform / SEO
Acceptance testExact repeatable check that closes the issueJS crawl + URL Inspection live test pass

Checks 1–5

1. Build the audit baseline before changing anything

Freeze the evidence before you touch the site. Use the same scope, date window and crawler settings again after implementation so the before/after comparison is meaningful.

1
Diagnostic check

Verify the correct Search Console property and access level

Without the right property you can audit the wrong protocol, subdomain or path and miss root-level crawl data.

ToolGoogle Search Console
Exact locationSearch Console → property selector → Settings → Ownership verification

Steps

  1. Confirm whether you are using a Domain property or a root URL-prefix property. For crawl diagnostics, prefer a Domain property or root-level URL-prefix property.
  2. Open Settings → Users and permissions and confirm your account is Owner or Full user before relying on URL Inspection and indexing workflows.
  3. Write the exact property name into the audit sheet, including protocol if it is a URL-prefix property.

Pass when

  • The property covers the production host you are auditing.
  • You can open Page indexing and URL Inspection without permission errors.
Evidence
Screenshot Settings → Ownership verification and record the property string.
SourceGoogle Search Console Help — URL Inspection tool · Google Search Console Help — Crawl Stats report
2
Diagnostic check

Export the Page indexing baseline

Use this report to spot patterns and unexpected changes. The total number of “Not indexed” URLs is not a site-quality score and is not a queue that must reach zero.

ToolGoogle Search Console
Exact locationIndexing → Pages

Steps

  1. Open Indexing → Pages and use All known pages unless the audit is intentionally scoped to one sitemap.
  2. Record Indexed and Not indexed totals with the audit date, but do not set “100% indexed” as the target.
  3. Open the largest or business-relevant reason rows. Sample URLs by template and classify each as expected or unexpected.
  4. The Page indexing report is aggregated and can lag. For the current state of one URL, use URL Inspection.
  5. Save the export as YYYY-MM-DD_gsc_page-indexing.csv and never overwrite the baseline file.

Pass when

  • Dated totals, reason-level samples and template classifications are saved.
  • Expected exclusions are documented; unexpected spikes or important affected templates have an owner.
Export / save
Export each important reason table and keep the original CSV unchanged.
SourceGoogle Search Console Help — Page indexing report · Google Search Off the Record — How to read the Indexing Report
3
Diagnostic check

Save a search-performance baseline for affected landing pages

Technical changes are easier to evaluate when the audit includes the pages that already earn impressions and clicks.

ToolGoogle Search Console
Exact locationPerformance → Search results → Pages

Steps

  1. Choose a stable comparison window: last 28 days vs previous 28 days for recent changes, or last 3 months vs previous period for lower-volume sites.
  2. Open the Pages tab and export clicks, impressions, CTR and average position.
  3. Mark the top landing pages by impressions and revenue/business importance. These URLs become your priority sample for every later check.

Pass when

  • A dated landing-page export exists.
  • Priority URLs are tagged before crawling begins.
Export / save
Export CSV/Google Sheets and add a Priority column outside the raw export.
SourceGoogle Search Central — In-depth guide to how Google Search works
4
Diagnostic check

Create one URL inventory from sitemap, crawl and analytics/Search Console

A single source rarely contains every important URL: sitemaps omit accidental URLs, crawlers miss orphans, and Search Console contains historical URLs.

ToolScreaming Frog + sitemap + Search Console
Exact locationSEO Spider → Mode: Spider; also download XML sitemaps

Steps

  1. Download every production XML sitemap listed in robots.txt and Search Console.
  2. Run a standard crawl from the canonical homepage with default crawlable internal links enabled.
  3. Merge URLs from: sitemap files, crawler Internal HTML export, GSC Pages export and any revenue/conversion landing-page list.
  4. Normalize only for analysis; keep the original URL strings in a separate column so case, slash and parameter differences are visible.

Pass when

  • Every business-critical page appears in the master inventory.
  • URLs discovered only by GSC, sitemap or analytics are flagged as potential orphans.
Export / save
Create master-urls.csv with columns Source, URL, Priority, Expected indexable?, Notes.
SourceGoogle Search Central — Build and submit a sitemap · Screaming Frog — SEO Spider configuration
5
Diagnostic check

Run a raw-HTML crawl and a JavaScript-rendered crawl

Comparing the two crawls shows which content, links and metadata depend on JavaScript.

ToolScreaming Frog SEO Spider
Exact locationConfiguration → Spider → Rendering

Steps

  1. Run crawl A with Rendering = Text Only and save the project file.
  2. Run crawl B with Rendering = JavaScript, using the same start URL, crawl scope, limits and user-agent assumptions.
  3. Use Configuration → Spider → Extraction → Store HTML / Store Rendered HTML so original and rendered output can be compared.
  4. Optional: connect Google Search Console, Google Analytics 4 and PageSpeed Insights under Configuration → API Access when those data sources are available.
  5. Keep the exports separate and add Rendering = raw or js to downstream worksheets.

Pass when

  • Both crawls use equivalent scope and configuration apart from rendering.
  • Differences in content, links, canonicals, titles and status handling can be traced to specific URLs or templates.
Export / save
Save both crawl project files plus Internal HTML and JavaScript-tab exports.
SourceScreaming Frog — SEO Spider configuration · Screaming Frog — How to crawl JavaScript websites · Google Search Central — Understand JavaScript SEO basics

Checks 6–11

2. Indexation: prove which URLs Google can and should index

Do not optimize the size of the “Not indexed” bucket. Look for unexpected patterns by template or reason, then use URL Inspection when you need the current state of a specific URL.

6
Diagnostic check

Compare expected indexable URLs with Google’s indexed totals

A gap between expected canonical pages and indexed pages is the fastest way to quantify the indexation problem.

ToolMaster URL inventory + Search Console
Exact locationMaster inventory → Expected indexable?; Search Console → Indexing → Pages

Steps

  1. Count only URLs that should be canonical search landing pages.
  2. Compare that count with Indexed in Search Console, then investigate by template rather than expecting an exact one-to-one match.
  3. Create a gap list for expected-indexable URLs that appear in a Not indexed reason.

Pass when

  • All critical expected-indexable URLs have a known indexation state.
  • Duplicates and intentionally noindexed URLs are excluded from the target count.
SourceGoogle Search Console Help — Page indexing report
7
Diagnostic check

Review every material “Not indexed” reason by template

A reason label is not a diagnosis. The useful signal is an unexpected pattern: growth after a release, a whole template affected, or important URLs appearing in the wrong bucket.

ToolGoogle Search Console
Exact locationIndexing → Pages → Why pages aren’t indexed → click a reason

Steps

  1. Prioritize unexpected growth, large reason groups and any reason that contains business-important URLs.
  2. Sample at least 5 URLs per reason and template as an audit rule of thumb, not a Google requirement. Increase the sample when the results are mixed.
  3. Classify each sample as Expected exclusion, Technical defect, Content/duplication issue, or Needs deeper inspection.
  4. Do not treat “Crawled - currently not indexed” as a ready-made technical root cause. Inspect content value, canonical signals, internal linking and the wider site pattern.

Pass when

  • Every high-volume reason has a classification and sample URLs.
  • No business-critical URL is left in an unexplained exclusion bucket.
Export / save
Add Reason, Template, Expected?, Root cause, Owner to the audit backlog.
SourceGoogle Search Console Help — Page indexing report · Google Search Off the Record — How to read the Indexing Report
8
Diagnostic check

Compare indexed URL data with a live test

The indexed version shows what Google previously stored; the live test shows the current technical state. Confusing them creates false conclusions.

ToolGoogle Search Console
Exact locationPaste full URL in top inspection bar → Page indexing → Test live URL

Steps

  1. For each priority issue, inspect the indexed version first and note Last crawl, Crawled as, Crawl allowed, Indexing allowed and Google-selected canonical.
  2. Click Test live URL and compare the current fetch/indexability state.
  3. Use View crawled page to inspect returned HTML when the indexed snapshot is available.
  4. Record whether the problem exists in the indexed snapshot, the live version, or both.

Pass when

  • Priority URLs have both indexed-state and live-state evidence.
  • Google-selected canonical is recorded where available.
Evidence
Save the inspection verdict together with the canonical and crawl fields behind it.
SourceGoogle Search Console Help — URL Inspection tool
9
Google guidance / documented limit

Find accidental meta robots and X-Robots-Tag noindex directives

A noindex directive removes a page from Google after Google can crawl and see that directive. Blocking the same URL in robots.txt can prevent Google from seeing noindex.

ToolScreaming Frog + Chrome DevTools
Exact locationSEO Spider → Directives tab; Chrome DevTools → Network → document request → Headers

Steps

  1. Export URLs with noindex from the crawler Directives tab.
  2. For priority URLs, inspect both <meta name="robots"> in HTML and the X-Robots-Tag response header in Network → Headers.
  3. Check whether any noindexed URL is also blocked in robots.txt; that combination prevents reliable processing of the noindex directive.
  4. Compare the noindex list with the sitemap; indexable sitemap URLs should not carry noindex.

Pass when

  • No priority canonical URL returns noindex.
  • Intentionally noindexed URLs remain crawlable unless there is a separate reason to block crawling.
Export / save
Export Directives → noindex URLs and join against the sitemap inventory.
SourceGoogle Search Central — Block Search indexing with noindex
10
Google guidance / documented limit

Test soft 404s and “empty 200” pages

A missing or empty page that returns 200 can be interpreted as a soft 404 and excluded from Search.

ToolSearch Console + browser/DevTools
Exact locationIndexing → Pages → Soft 404; DevTools → Network → document → Status

Steps

  1. Open each reported template and confirm what a human sees.
  2. If content is permanently gone with no replacement, return HTTP 404 or 410.
  3. If there is a clear replacement, use a permanent server-side redirect to that specific replacement rather than the homepage.
  4. For SPAs, test a random invalid route and confirm the server does not return a generic 200 shell for a nonexistent page.

Pass when

  • Nonexistent URLs return 404/410 or a specific justified redirect.
  • Valid pages do not render blank/near-blank content to Googlebot.
Verify
Re-test the URL in URL Inspection after deployment and confirm the HTTP behavior.
SourceGoogle Search Central — Troubleshoot crawling errors and soft 404s · Google Search Central — Fix Search-related JavaScript problems
11
Diagnostic check

Investigate “Google-selected canonical” mismatches on priority pages

Google may choose a different canonical when your signals conflict or the pages are too similar.

ToolGoogle Search Console + crawler
Exact locationURL Inspection → Page indexing → Google-selected canonical

Steps

  1. Record User-declared canonical and Google-selected canonical for every priority mismatch.
  2. Check whether the preferred canonical is 200, indexable, internally linked and present in the sitemap.
  3. Check duplicate variants for redirects, canonical tags and substantially similar primary content.
  4. Fix conflicting signals before requesting reindexing.

Pass when

  • Priority pages either self-canonicalize and are selected by Google, or the alternate canonical is intentional and documented.
SourceGoogle Search Central — How to specify a canonical URL · Google Search Console Help — URL Inspection tool

Checks 12–16

3. Crawlability, robots.txt, sitemaps and host health

Separate discovery from indexing. This block checks whether Googlebot can request the right URLs and resources, whether robots rules match intent, and whether sitemaps describe the canonical URL set.

12
Google guidance / documented limit

Verify robots.txt is available at the host root

An unavailable robots.txt can disrupt crawling, while a robots rule cannot be used as a reliable noindex mechanism.

ToolBrowser + curl + Search Console
Exact locationOpen https://example.com/robots.txt; Search Console → Settings → robots.txt report (when available)

Steps

  1. Request /robots.txt on every production host that serves crawlable content.
  2. Confirm it is a plain-text file at the root, reachable without authentication or redirect loops.
  3. Use curl -I https://example.com/robots.txt to record the HTTP response.
  4. Confirm sitemap declarations use absolute production URLs.

Pass when

  • robots.txt is consistently reachable and its rules match the intended production environment.
  • No staging Disallow: / rule is present on production.
Evidence
Keep a copy of the production robots.txt in the audit evidence folder.
SourceGoogle Search Central — Introduction to robots.txt · Google Crawling Infrastructure — Update your robots.txt file
13
Google guidance / documented limit

Test every broad Disallow rule against real URL samples

A short wildcard or directory rule can silently block thousands of valid URLs.

Toolrobots.txt + URL Inspection + crawler
Exact locationrobots.txt file; URL Inspection → Crawl allowed?

Steps

  1. List every Disallow rule that can match HTML pages, CSS, JavaScript or API endpoints required to render indexable pages.
  2. For each broad rule, generate at least 3 matching URLs: intended block, edge case, and a URL that must stay crawlable.
  3. Inspect priority URLs in Search Console and confirm Crawl allowed? = Yes.
  4. Do not use robots.txt to hide sensitive content; use authentication or access control.

Pass when

  • No indexable template or essential rendering resource is unintentionally blocked.
  • Blocked URLs are blocked for a documented crawl reason, not as a substitute for noindex.
SourceGoogle Search Central — Introduction to robots.txt · Google Search Console Help — URL Inspection tool
14
Google guidance / documented limit

Validate sitemap format, status and Google size limits

Invalid or oversized sitemaps reduce the reliability of URL discovery and reporting.

ToolBrowser + Search Console + crawler
Exact locationSearch Console → Indexing → Sitemaps; open sitemap URL directly

Steps

  1. Confirm every submitted sitemap returns 200 and valid XML.
  2. Count URLs and uncompressed file size for each sitemap.
  3. Google’s documented maximum for one sitemap is 50,000 URLs or 50 MB uncompressed. Split files before either limit is exceeded.
  4. If using a sitemap index, verify every child sitemap is production, current and reachable.

Pass when

  • Each sitemap is ≤50,000 URLs and ≤50 MB uncompressed.
  • Search Console reports the sitemap as successfully processed.
Export / save
Save sitemap URL, URL count, file size, lastmod coverage and Search Console status.
SourceGoogle Search Central — Build and submit a sitemap
15
Metricum Lab audit target

Keep only canonical, indexable 200 URLs in XML sitemaps

A sitemap is a canonicalization hint and discovery source; filling it with redirects, errors or noindex URLs sends conflicting signals.

ToolScreaming Frog + sitemap export
Exact locationSEO Spider → Sitemaps/Response Codes/Canonicals; compare with sitemap URL list

Steps

  1. Join sitemap URLs with crawler status code, indexability and canonical target.
  2. Flag any sitemap URL returning 3xx, 4xx, 5xx, noindex, robots block or canonical to another URL.
  3. Remove those URLs from generated sitemaps or fix the underlying page when it should be canonical.
  4. Verify new canonical URLs are added automatically when published.

Pass when

  • 100% of submitted sitemap URLs are intended canonical URLs in your own audit target.
  • No sitemap URL is a known redirect/error/noindex/alternate canonical.
Export / save
Create sitemap-quality.csv with URL, Status, Indexability, Canonical, Issue.
SourceGoogle Search Central — Build and submit a sitemap · Google Search Central — How to specify a canonical URL
16
Diagnostic check

Check Google crawl host availability and response-time spikes

Server instability can prevent crawling even when every on-page directive is correct.

ToolGoogle Search Console
Exact locationSettings → Crawl stats → Host status / Crawl requests / Average response time

Steps

  1. Confirm Host status shows no recent significant availability issue.
  2. Open Crawl responses and review 5xx, DNS, robots.txt unavailable and redirect-loop patterns.
  3. Compare Average response time spikes with deploys, incidents and crawl-request drops.
  4. Crawl Stats is an advanced report and is most useful on larger sites or root-level properties.

Pass when

  • No unexplained host-availability incident affects priority crawl periods.
  • 5xx and network-error spikes have an incident owner and remediation.
Export / save
Record incident date, response category, affected host and engineering ticket.
SourceGoogle Search Console Help — Crawl Stats report

Checks 17–23

4. HTTP status codes, redirects and canonical consistency

Start with intent. A 404 can be correct, a redirect can be wrong, and a 200 can still be a soft 404. Map each URL state to what the page is supposed to do before prescribing a fix.

17
Diagnostic check

Export all internal status codes and classify them by intent

HTTP status is evidence, not a verdict. A deliberate 404 can be correct; the defect is a status that conflicts with the URL’s intended state or still receives valuable internal/search signals.

ToolScreaming Frog SEO Spider
Exact locationResponse Codes tab → filters 2xx / 3xx / 4xx / 5xx

Steps

  1. Export internal URLs for each non-2xx status class and include source/inlink data so the generating page or template is visible.
  2. Classify 404/410 URLs as Expected gone, Broken internal link, Valuable legacy URL, or Needs redirect.
  3. Do not mass-redirect unrelated 404s to the homepage. If the old URL still has clicks, impressions, backlinks or a clear replacement, restore it or use a permanent redirect to the closest equivalent.
  4. Treat unexplained 5xx responses on crawlable production URLs as an engineering incident and record the affected scope and time window.

Pass when

  • Every recurring non-2xx pattern has an intended state and owner.
  • Broken internal links are fixed at the source; valuable legacy URLs have a relevant restore/redirect decision; expected 404/410 URLs remain intentionally gone.
Export / save
Bulk Export → Response Codes → Client Error (4xx) Inlinks and Server Error (5xx) Inlinks.
SourceGoogle Search Central — Redirects and Google Search · Google Search Central — Troubleshoot crawling errors and soft 404s · Google Search Central — How to perform a technical SEO audit
18
Metricum Lab audit target

Remove redirect chains from internal links

Google can follow redirect chains, but every extra hop adds latency, crawl requests and another failure point.

ToolScreaming Frog SEO Spider
Exact locationReports → Redirects → Redirect Chains (or equivalent redirect-chain export)

Steps

  1. Export redirect chains and sort by chain length.
  2. Update internal links, canonicals, hreflang and sitemap references to point directly to the final 200 URL.
  3. Keep legacy external-entry redirects where needed, but remove avoidable internal hops.
  4. Use one hop as the audit target for normal internal navigation; document exceptions such as controlled migrations.

Pass when

  • Internal links resolve directly to the final canonical URL or use at most one justified redirect hop.
Export / save
Give engineering Source URL → Current target → Final target → Hop count.
SourceGoogle Search Central — Redirects and Google Search
19
Metricum Lab audit target

Force one HTTPS/host variant in a single server-side hop

Multiple accessible host/protocol variants multiply duplicate URLs and weaken signal consistency.

Toolcurl + browser + crawler
Exact locationTest http/https and www/non-www variants of the homepage and a deep URL

Steps

  1. Request http://, https://, www and non-www variants that are technically possible for the site.
  2. Confirm every non-preferred variant permanently redirects to the exact preferred equivalent URL.
  3. Avoid redirecting every old deep URL to the homepage; preserve the page-level path when a real equivalent exists.
  4. Update internal links so users and crawlers do not need these normalization redirects.

Pass when

  • Only one host/protocol version returns 200 for canonical pages.
  • Non-preferred variants use a permanent server-side redirect to the equivalent preferred URL.
SourceGoogle Search Central — Redirects and Google Search · Google Search Central — How to specify a canonical URL
20
Metricum Lab audit target

Audit trailing slash, case and parameter duplicates

The same content available under multiple syntactic URLs creates crawl waste and canonical conflicts.

ToolCrawler + server tests
Exact locationSEO Spider → URL / Canonicals; manually test known URL variants

Steps

  1. Test /page and /page/ when your stack can serve both.
  2. Test uppercase/lowercase path variants on case-sensitive and case-insensitive routes.
  3. Test common tracking and sorting parameters such as utm_*, sort, filter or session IDs.
  4. Choose one canonical format and make internal links, sitemap, canonical tags and redirects consistent with it.

Pass when

  • One preferred URL format is used internally.
  • Duplicate variants either redirect, canonicalize correctly, or are intentionally distinct.
SourceGoogle Search Central — How to specify a canonical URL
21
Metricum Lab audit target

Require a valid self-referential canonical on indexable pages

Self-canonicals make the preferred URL explicit and expose template mistakes early.

ToolScreaming Frog SEO Spider
Exact locationCanonicals tab → Missing / Multiple / Non-indexable Canonical filters

Steps

  1. Export indexable HTML URLs with missing canonicals.
  2. Export pages with multiple canonical elements or conflicting HTTP-header canonicals.
  3. For canonical pages, verify the canonical is absolute, uses the preferred protocol/host and resolves to the same normalized URL.
  4. For duplicates, document why they canonicalize elsewhere.

Pass when

  • Every intended canonical HTML page has one clear canonical target.
  • No page emits conflicting canonical signals.
Export / save
Export Canonicals issues and group by page template.
SourceGoogle Search Central — How to specify a canonical URL
22
Metricum Lab audit target

Validate every canonical target is itself crawlable, indexable and 200

A canonical that points to a redirect, 404, noindex or blocked URL is internally contradictory.

ToolScreaming Frog SEO Spider
Exact locationCanonicals tab → Canonical Link Element 1; join target URL to status/indexability

Steps

  1. Extract all unique canonical targets.
  2. Crawl those targets and join HTTP status, robots status and indexability.
  3. Flag canonical targets that redirect, return error, are noindex or are blocked by robots.txt.
  4. Fix at the template level when the same defect repeats.

Pass when

  • All canonical targets for indexable pages resolve to valid preferred URLs without contradictory directives.
SourceGoogle Search Central — How to specify a canonical URL · Google Search Central — Block Search indexing with noindex
23
Google guidance / documented limit

Make redirects, canonicals, sitemaps and internal links agree

Google treats redirects and rel=canonical as strong canonical signals and sitemap inclusion as a weaker signal; conflicting signals reduce clarity.

ToolMaster URL inventory
Exact locationJoin final URL, redirect target, canonical target, sitemap flag and internal inlinks

Steps

  1. For each duplicate URL family, define one Preferred URL.
  2. Check that permanent redirects point to it where appropriate.
  3. Check that rel=canonical points to it, the sitemap contains it, and internal links use it.
  4. Create a conflict flag if any signal points elsewhere.

Pass when

  • Priority URL families have one preferred URL supported by all controllable signals.
Export / save
Build a signal-consistency table: Variant → Redirect → Canonical → Sitemap → Internal link target.
SourceGoogle Search Central — How to specify a canonical URL

Checks 24–28

5. Site architecture and internal linking

Audit the link graph, not the menu screenshot. Important pages need crawlable contextual paths from relevant hubs; depth and inlink counts are triage signals, not Google thresholds.

25
Metricum Lab audit target

Find orphan and near-orphan pages

Pages in sitemaps or Search Console but absent from the internal link graph are harder for users and crawlers to discover contextually.

ToolScreaming Frog + master inventory
Exact locationCrawl export → Inlinks; merge with sitemap/GSC URLs

Steps

  1. Join the master URL inventory to the crawler’s Unique Inlinks data.
  2. Treat an expected-indexable URL with 0 crawlable internal inlinks as an orphan.
  3. For priority pages, use fewer than 3 unique internal inlinks as a review trigger, not a Google rule. Check whether the links are contextual and relevant before adding more.
  4. Add contextual links from relevant hubs or supporting pages instead of placing every URL in global navigation.

Pass when

  • No important indexable page has 0 crawlable internal inlinks.
  • Priority pages with fewer than 3 unique inlinks have either a documented reason or a contextual-link action.
Export / save
Create orphan-pages.csv with URL, Source found, Inlinks, Suggested hub, Owner.
SourceGoogle Search Central — SEO link best practices for Google · Google Search Console Help — Page indexing report · Screaming Frog — Internal Linking Audit With the SEO Spider
26
Metricum Lab audit target

Measure crawl depth for business-critical pages

Depth is not a fixed Google ranking rule, but it is a useful architecture diagnostic: important pages should not require a long chain of navigation.

ToolScreaming Frog SEO Spider
Exact locationInternal tab → Links → Crawl Depth column

Steps

  1. Filter to priority indexable HTML pages and sort Crawl Depth descending.
  2. Flag priority URLs deeper than 3 clicks for review. Treat this as an architecture heuristic, not a Google limit.
  3. Trace the click path and look for missing hub links, over-nested taxonomy, faceted paths or pages that are only linked from low-value templates.
  4. Prefer a relevant contextual route that brings important pages within roughly 1–3 clicks of a major hub when the information architecture allows it.

Pass when

  • Priority pages are reachable within the documented 1–3-click working target or have a justified information-architecture exception.
SourceGoogle Search Central — SEO link best practices for Google · Screaming Frog — Internal Linking Audit With the SEO Spider
27
Metricum Lab audit target

Eliminate broken internal links at the source

A 404 itself can be normal; an internal link that repeatedly sends users and crawlers to a 404 is a fixable defect.

ToolScreaming Frog SEO Spider
Exact locationBulk Export → Response Codes → Client Error (4xx) Inlinks

Steps

  1. Export every 4xx destination with source inlinks.
  2. Fix the source template/link first; add a redirect only when there is a real replacement and legacy traffic requires it.
  3. For typo URLs, correct the href rather than relying on a redirect forever.
  4. Re-crawl the source templates after deployment.

Pass when

  • 0 unintended internal links point to 4xx URLs in the final verification crawl.
Export / save
Send developers Source page, Anchor, Broken target, Correct target.
SourceGoogle Search Central — Troubleshoot crawling errors and soft 404s · Google Search Central — SEO link best practices for Google
28
Diagnostic check

Review anchor text and image-link alt text for context

Descriptive anchors help users and Google understand the destination; generic repeated anchors lose context.

ToolScreaming Frog + manual review
Exact locationInlinks/All Inlinks export; inspect image links in HTML

Steps

  1. Export inlinks for priority pages and review the anchor distribution.
  2. Replace ambiguous anchors like “click here” where a descriptive phrase is natural.
  3. For linked images, verify useful alt text describes the image/destination context when appropriate.
  4. Avoid mechanically forcing exact-match keywords into every internal anchor.

Pass when

  • Priority pages receive understandable contextual anchors from relevant pages.
  • Image links that carry navigation meaning have useful alt attributes.
SourceGoogle Search Central — SEO link best practices for Google

Checks 29–33

6. JavaScript rendering and rendered-content parity

Normal crawlable HTML is still the safest baseline for Search. Compare the server response with the rendered DOM so you can see exactly which content, links and directives depend on JavaScript.

29
Diagnostic check

Compare primary content in raw HTML and rendered HTML

Search systems are built to process normal HTML. The audit question is whether JavaScript changes or hides essential meaning, navigation or directives between the response and the rendered DOM.

ToolScreaming Frog + View Source + DevTools
Exact locationRaw crawl vs JS crawl; SEO Spider lower pane → Original HTML / Rendered HTML

Steps

  1. Choose the homepage, one category/service page and at least 3 representative content/detail templates.
  2. Compare H1, primary body copy, crawlable links, title, meta description and canonical in the original response and rendered output.
  3. Record fields that JavaScript adds, removes or changes, and identify the component/template responsible.
  4. Keep normal HTML as the primary crawlable version. Do not build a second Markdown or llms.txt content copy as a substitute for accessible HTML.

Pass when

  • Essential content and links are present in rendered HTML and do not disappear after hydration.
  • Critical metadata is stable between raw and rendered states unless the change is intentional.
Export / save
Use JavaScript-tab filters plus Original HTML/Rendered HTML exports for repeated template defects.
SourceGoogle Search Central — Understand JavaScript SEO basics · Screaming Frog — SEO Spider configuration · Google Search Off the Record — Should I use markdown for my site?
30
Metricum Lab audit target

Keep canonical and core metadata stable in initial HTML where possible

Google can process JavaScript-generated metadata, but its guidance favors clear, stable signals and server/prerendered output is simpler to process.

ToolView Source + crawler
Exact locationBrowser → View page source; SEO Spider → JavaScript filters

Steps

  1. Check title, meta robots and rel=canonical in the initial HTML response.
  2. Compare them with the rendered DOM.
  3. Flag canonical-only-in-rendered-HTML and metadata changed by JavaScript patterns.
  4. Fix framework templates so the server/prerendered HTML emits the final intended values.

Pass when

  • Canonical and indexing directives do not depend on late client-side mutation on priority pages.
SourceGoogle Search Central — Understand JavaScript SEO basics · Google Search Central — How to specify a canonical URL · Screaming Frog — SEO Spider configuration
31
Diagnostic check

Check blocked or failed JavaScript/CSS/API resources needed for content

Google’s renderer needs access to important resources; failed resource requests can produce blank or incomplete rendered output.

ToolURL Inspection + Chrome DevTools
Exact locationURL Inspection → View tested/crawled page → More info; DevTools → Network

Steps

  1. Test a priority page live in URL Inspection and review loaded resources/rendered HTML.
  2. In DevTools Network, reload with Disable cache enabled and filter failed requests by Status.
  3. Check robots rules for JS/CSS/API paths that are essential to render primary content.
  4. Treat authentication/CORS/5xx failures on public rendering resources as engineering defects.

Pass when

  • No essential rendering resource is unintentionally blocked or failing for the public page.
SourceGoogle Search Central — Fix Search-related JavaScript problems · Chrome for Developers — Network features reference
33
Google guidance / documented limit

Check oversized HTML/resources against Googlebot’s current fetch byte limit

Google Search currently fetches up to 2 MB for an individual URL, while PDFs have a 64 MB limit. Bytes after the cutoff are not fetched, so essential HTML content or directives must not sit beyond it.

ToolChrome DevTools + curl
Exact locationDevTools → Network → document/resource → Size; or curl output size

Steps

  1. Measure the response size of unusually large HTML documents and critical fetched resources rather than guessing from source-line count.
  2. For HTML approaching 2 MB, inspect whether the title, canonical, robots directives, primary content and important links all appear before the cutoff.
  3. Each subresource URL has its own fetch limit. The 2 MB figure is not a total page-weight budget.
  4. Reduce server-generated payload or split non-essential data if critical crawlable content risks being beyond the fetched bytes.

Pass when

  • HTML needed for indexing is below the 2 MB fetch limit and no essential content/directive is placed beyond that boundary.
Evidence
Record HTML transfer/body size for the largest templates and note whether critical content appears before the 2 MB boundary.
SourceGoogle Search Central Blog — Inside Googlebot: crawling, fetching, and bytes processed · Chrome for Developers — Network features reference

Checks 34–38

7. Core Web Vitals and browser-level performance checks

Judge Core Web Vitals with field data when it is available, then use lab tools to diagnose the cause. The published thresholds apply at the 75th percentile; resource-size budgets below are internal triage rules.

34
Google guidance / documented limit

Check PageSpeed Insights field data for both mobile and desktop

Core Web Vitals are evaluated from real-user field data when available; a single Lighthouse run is only a lab sample.

ToolPageSpeed Insights
Exact locationhttps://pagespeed.web.dev/ → enter URL → Mobile / Desktop

Steps

  1. Test the homepage plus at least one representative URL from each high-traffic template.
  2. Read Discover what your real users are experiencing before the lab diagnostics.
  3. Record whether data is URL-level or origin-level and do not present origin data as if it were specific to one page.
  4. Save LCP, INP and CLS at the 75th percentile for mobile and desktop separately.

Pass when

  • Field-data scope (URL or origin) is recorded.
  • Mobile and desktop values are stored separately.
Export / save
Create cwv-baseline.csv with URL, Scope, Device, LCP, INP, CLS, Date.
Sourceweb.dev — Web Vitals: Core Web Vitals thresholds
35
Google guidance / documented limit

Target LCP ≤ 2.5 seconds at the 75th percentile

Largest Contentful Paint measures when the largest visible image/text/video element is rendered.

ToolPageSpeed Insights + Chrome DevTools
Exact locationPSI field data; DevTools Performance trace for diagnosis

Steps

  1. Record the field LCP value and whether it passes.
  2. In a slow lab trace, identify the LCP element and separate server/TTFB delay, resource-load delay, resource duration and render delay.
  3. If the LCP is an image, verify it is discoverable early, not lazy-loaded above the fold, appropriately sized and compressed.
  4. Retest the same template after changes, not a different “easy” URL.

Pass when

  • Good threshold: LCP ≤2.5 s at p75.
  • Poor threshold begins above 4.0 s; 2.5–4.0 s needs improvement.
Sourceweb.dev — Web Vitals: Core Web Vitals thresholds
36
Google guidance / documented limit

Target INP ≤ 200 ms at the 75th percentile

INP measures responsiveness across user interactions and replaced FID as a Core Web Vital.

ToolPageSpeed Insights + Chrome DevTools Performance
Exact locationPSI field data; DevTools → Performance

Steps

  1. Record field INP at p75.
  2. Reproduce slow interactions such as menu open, filter change, accordion, add-to-cart or form typing in the Performance panel.
  3. Look for long main-thread tasks, heavy event handlers and rendering work after input.
  4. Split expensive tasks or reduce unnecessary JavaScript rather than only optimizing page load.

Pass when

  • Good threshold: INP ≤200 ms at p75.
  • Poor threshold: >500 ms.
Sourceweb.dev — Web Vitals: Core Web Vitals thresholds
37
Google guidance / documented limit

Target CLS ≤ 0.1 at the 75th percentile

CLS quantifies unexpected visual movement; common causes include unsized media and injected content.

ToolPageSpeed Insights + Chrome DevTools
Exact locationPSI field data; DevTools Performance/Layout Shift diagnostics

Steps

  1. Record field CLS at p75.
  2. Navigate and interact with the page long enough to trigger banners, fonts, lazy content and consent UI.
  3. Reserve width/height or aspect-ratio for images, video, iframes and dynamic slots.
  4. Do not insert new content above content the user is already reading unless triggered by the user.

Pass when

  • Good threshold: CLS ≤0.1 at p75.
  • Poor threshold: >0.25.
Sourceweb.dev — Web Vitals: Core Web Vitals thresholds
38
Metricum Lab audit target

Use DevTools Network to find oversized and blocking resources

A concrete resource list is more actionable than “make the site faster.” This is an audit budget, not a Google ranking threshold.

ToolChrome DevTools
Exact locationDevTools → Network → check Disable cache and Preserve log → reload

Steps

  1. Enable Disable cache to approximate a first visit and Preserve log when redirects or navigation are part of the test.
  2. Sort by Size and Time; inspect JS, CSS, Img and Fetch/XHR separately.
  3. Capture the 10 largest first-load requests with URL, resource type, transferred size, initiator, blocking/priority behavior and owner.
  4. Use internal byte budgets only to prioritize review. They are not Google ranking thresholds and should be adjusted to the product and connection profile.
  5. Export a sanitized HAR when engineers need timing and header evidence; remove cookies, authorization headers and other secrets before sharing.

Pass when

  • The 10 largest first-load requests have an owner/justification, and any internal budget used in the backlog is labeled as a team target rather than a Google requirement.
Export / save
Network panel → Export HAR (sanitized) plus a top-10 resource table.
SourceChrome for Developers — Network features reference

Checks 39–42

8. Structured data, hreflang and final verification

Finish by validating machine-readable signals and language targeting, then repeat the baseline tests. A ticket is closed when the acceptance evidence changes, not when code is merely deployed.

39
Google guidance / documented limit

Validate structured data against Google’s supported features

Valid JSON-LD is not enough: the markup must match visible page content and the requirements for the specific search feature.

ToolGoogle Rich Results Test
Exact locationhttps://search.google.com/test/rich-results → URL

Steps

  1. Test representative URLs for every template that emits structured data.
  2. Fix critical Rich Results Test errors first, then review warnings/recommended properties.
  3. Confirm markup describes content visible to users and uses the most specific relevant type supported by Google.
  4. After deployment, inspect a live URL in Search Console to verify what Google sees.

Pass when

  • 0 critical structured-data errors on templates intended for rich-result eligibility.
  • Markup matches visible page content and is crawlable/indexable.
Evidence
Save the Rich Results Test result or issue list for each template.
SourceGoogle Search Central — General structured data guidelines · Google Search Console — Rich Results Test · Google Search Console Help — URL Inspection tool
40
Google guidance / documented limit

Validate reciprocal hreflang pairs for every localized page

Each language version should list itself and all alternates; broken pairs can prevent Google from understanding the relationship.

ToolCrawler + page source + sitemap
Exact locationInspect <link rel="alternate" hreflang>; compare EN/UA URL pairs

Steps

  1. For each localized canonical page, confirm hreflang=en and hreflang=uk point to the correct canonical language URLs.
  2. Confirm the alternate page links back to the original page; language relationships must be reciprocal.
  3. Use absolute URLs and keep only live canonical 200 pages in the hreflang set.
  4. If x-default is used, point it to the intentional default/fallback page.

Pass when

  • Every EN/UA pair is reciprocal, self-referential within the set and points to canonical 200 URLs.
Export / save
Create hreflang-pairs.csv with EN URL, UK URL, reciprocal?, status, canonical.
SourceGoogle Search Central — Tell Google about localized versions of your page
41
Google guidance / documented limit

Keep each translated page self-canonical instead of canonicalizing translations to one language

Fully translated language versions are separate localized pages, not duplicates that should collapse into one canonical URL.

ToolCrawler + source
Exact locationCanonicals + hreflang export

Steps

  1. Check the English page canonical points to the English URL.
  2. Check the Ukrainian page canonical points to the Ukrainian URL.
  3. Use hreflang to connect the versions instead of cross-language canonicals.
  4. Confirm the body content is translated as well as the navigation and template chrome.

Pass when

  • Each language page self-canonicalizes and is connected through hreflang.
  • Primary content and interface/navigation text are localized consistently.
SourceGoogle Search Central — Tell Google about localized versions of your page · Google Search Central — How to specify a canonical URL
42
Diagnostic check

Re-run the crawl and Search Console samples after fixes

A change is verified only when the same test that exposed the defect now produces the expected result. Deployment by itself is not acceptance evidence.

ToolSame tools used in the baseline
Exact locationRepeat raw crawl + JS crawl + URL Inspection samples + sitemap/robots checks

Steps

  1. Re-run the raw and JavaScript crawls with the same start URL, scope and configuration used for the baseline.
  2. Compare the before/after URL sets for 4xx, 5xx, redirects, noindex, canonical conflicts, orphans and raw/rendered differences; headline counts alone can hide regressions.
  3. For P1/P2 fixes, retest representative affected URLs with the original diagnostic path and a live URL Inspection where applicable.
  4. Request indexing only after the live page is correct; repeated requests for the same unchanged URL are not a substitute for fixing discovery or quality.
  5. Close the item only when the backlog contains the affected scope, expected result and before/after evidence that satisfies the acceptance test.

Pass when

  • Every critical fix has repeatable before/after evidence for the original failure mode.
  • The verification crawl shows no new regression in the corrected template or URL set.
Export / save
Store final-crawl project, verification CSVs and issue-level before/after evidence.
SourceGoogle Search Console Help — URL Inspection tool · Google Search Console Help — Page indexing report · Google Search Central — How to perform a technical SEO audit

Reference desk

Primary sources used in this checklist

Limits and Google-specific behavior are linked to first-party documentation. Tool-specific steps link to the vendor documentation where appropriate.

  1. Google Search CentralIn-depth guide to how Google Search works ↗
  2. Google Search Console HelpPage indexing report ↗
  3. Google Search Console HelpURL Inspection tool ↗
  4. Google Search CentralBlock Search indexing with noindex ↗
  5. Google Search CentralIntroduction to robots.txt ↗
  6. Google Crawling InfrastructureUpdate your robots.txt file ↗
  7. Google Search CentralBuild and submit a sitemap ↗
  8. Google Search Console HelpCrawl Stats report ↗
  9. Google Search CentralRedirects and Google Search ↗
  10. Google Search CentralHow to specify a canonical URL ↗
  11. Google Search CentralTroubleshoot crawling errors and soft 404s ↗
  12. Google Search CentralSEO link best practices for Google ↗
  13. Google Search CentralUnderstand JavaScript SEO basics ↗
  14. Google Search CentralFix Search-related JavaScript problems ↗
  15. Google Search Central BlogInside Googlebot: crawling, fetching, and bytes processed ↗
  16. web.devWeb Vitals: Core Web Vitals thresholds ↗
  17. Google Search CentralTell Google about localized versions of your page ↗
  18. Google Search CentralGeneral structured data guidelines ↗
  19. Google Search ConsoleRich Results Test ↗
  20. Chrome for DevelopersNetwork features reference ↗
  21. Screaming FrogSEO Spider configuration ↗
  22. Screaming FrogHow to crawl JavaScript websites ↗
  23. Google Search Off the RecordHow to read the Indexing Report ↗
  24. Google Search CentralHow to perform a technical SEO audit ↗
  25. Google Search Off the RecordShould I use markdown for my site? ↗
  26. Screaming FrogInternal Linking Audit With the SEO Spider ↗

Need implementation support?

Need the audit turned into an implementation backlog?

Metricum Lab can convert the crawl, Search Console and browser evidence into a prioritized technical SEO backlog with owners, acceptance criteria and verification.

Explore Technical SEO services