SEO Technical Audit Checklist: Fix Blockers Before Minor Warnings

A technical SEO audit should answer three questions: can search engines access your important pages, can they understand and index the right versions, and can visitors use those pages to enquire or buy?

Use this checklist to produce a fix plan—not just an automated health score. Start with service, product, pricing and demo pages, then the articles that lead buyers to them. Google’s minimum technical requirements are crawler access, a working page returning HTTP 200, and indexable content; meeting them makes a page eligible, not guaranteed to be indexed. Google’s technical requirements

Prepare the audit

Gather:

• Google Search Console access, including Page indexing, Sitemaps, Crawl stats, Manual Actions and Security Issues.
• A site crawl from a tool such as Screaming Frog or Sitebulb.
• A CMS URL export and the site’s XML sitemap.
• PageSpeed Insights, browser developer tools and analytics access.

Build a list of URLs you want indexed. Keep redirects, private pages and duplicate variants separate. Compare that list with crawl results and Search Console: a crawler following internal links cannot reveal every unlinked page by itself. Search Console’s Page indexing examples are also limited and may not list every affected URL. Page indexing report limits

For a small site, check every commercially important URL. On larger sites, inspect examples from each template and expand testing wherever you find a shared defect.

Check Manual Actions and Security Issues separately: URL Inspection does not test whether the site is free of either. URL Inspection’s testing limits

1. Check access and HTTP status codes

• [ ] Important URLs load publicly over HTTPS without login requirements, certificate errors or security challenges.
• [ ] Those pages return 200 with their actual content—not an error message inside a successful response.
• [ ] Investigate 5xx errors and 429 rate limiting affecting important pages or recurring across the site.
• [ ] Repair broken internal links. Use permanent redirects for permanently moved pages; retain genuine 404 or 410 responses when no replacement exists.
• [ ] Remove redirect loops and shorten unnecessary chains.

Google recommends permanent server-side redirects, such as 301 or 308, when a page’s URL permanently changes. Google’s redirect guidance

Google treats error-like content returned with 200 as a possible soft 404. Server errors and 429 responses can slow crawling, so check hosting, CDN and firewall behaviour rather than assuming the CMS is responsible. Google’s HTTP status guidance

2. Separate crawling from indexing controls

• [ ] Review robots.txt rules against your intended indexable URLs and essential rendering resources.
• [ ] Check both robots meta tags and X-Robots-Tag headers for accidental noindex rules.
• [ ] Confirm staging and private environments use appropriate access protection.
• [ ] Inspect unexpectedly excluded commercial pages individually in Search Console.

Robots.txt controls crawling; it does not reliably keep a web page out of search. Use password protection for private content, not just a crawler rule. Robots.txt guidance

For public pages that should not appear, use an appropriate indexing control. Google must be able to crawl a page to read its noindex rule, so blocking it in robots.txt can prevent that rule from being seen. Noindex guidance

Do not treat every “Not indexed” URL as a defect. Expected duplicates, retired pages and deliberately excluded URLs can be healthy exclusions. Search Console’s Page indexing guidance

3. Align canonical URLs and redirects

• [ ] Test HTTP/HTTPS, www/non-www, trailing-slash and parameter variants where they exist.
• [ ] Check that canonical annotations point duplicate or near-duplicate pages to the preferred version—not an unrelated page.
• [ ] Make internal links, sitemaps and canonical annotations agree on the preferred URL.
• [ ] Compare the user-declared and Google-selected canonical in URL Inspection’s indexed data.

A canonical annotation is a signal, not an instruction Google must obey. Redirects and canonical annotations are stronger canonicalization signals than sitemap inclusion. Avoid combining contradictory preferences or using noindex as a substitute for duplicate consolidation. Google’s canonical guidance

4. Confirm discovery through links and sitemaps

• [ ] Give each important page a contextual internal link from another relevant page.
• [ ] Check that navigation and content links use anchor elements with valid href destinations, rather than click-only script events.
• [ ] Reconcile crawl results with CMS and sitemap exports to find orphan pages—pages without internal links pointing to them.
• [ ] Keep preferred, indexable URLs in the sitemap; remove stale redirects and unwanted variants, and check processing errors in Search Console.

Google recommends linking to every page you care about from another page on the site. Internal-link guidance

A sitemap helps communicate preferred URLs, but submitting one does not guarantee crawling or indexing. Sitemap guidance

5. Inspect rendered content on mobile

• [ ] Compare the initial HTML, browser-rendered page and Google’s rendered HTML for representative templates.
• [ ] Confirm primary copy, headings, links and metadata survive rendering.
• [ ] Check that essential content does not require clicking, swiping or typing before it loads.
• [ ] Test mobile navigation, enquiry forms and booking or demo flows manually.

Google uses the mobile version of content for indexing and ranking. A page that looks complete on desktop can still have missing mobile content or inaccessible resources. Mobile-first indexing guidance

Google can execute JavaScript, but rendering still needs verification. JavaScript SEO guidance Use the mobile and desktop rendering comparison workflow when templates differ.

6. Diagnose speed with the right measurements

• [ ] Review real-user Core Web Vitals for important templates, separating mobile and desktop.
• [ ] Use lab tests to diagnose large images, blocking scripts, slow responses and layout shifts.
• [ ] Record missing field data as unknown—not a pass.

As of October 2026, the “good” Core Web Vitals thresholds are:

Metric	What it measures	Good threshold
Largest Contentful Paint (LCP)	Loading performance	≤2.5 seconds
Interaction to Next Paint (INP)	Interactivity	≤200 milliseconds
Cumulative Layout Shift (CLS)	Visual stability	≤0.1

Assess these at the 75th percentile, separating mobile and desktop. Lab measurements help diagnose problems but do not replace field measurements. Do not make a perfect Lighthouse score the audit’s main objective. Web Vitals definitions and measurement guidance

7. Check metadata and structured data

• [ ] Look for missing or incorrectly repeated page titles and descriptions caused by template errors.
• [ ] Test applicable structured data with the Rich Results Test.
• [ ] Verify markup accurately represents the page and meets the specific feature’s requirements.

Automated validation cannot establish every quality requirement. Quality violations can prevent even syntactically correct markup from appearing as a rich result. Don’t prioritize optional schema warnings above access or indexing blockers. Structured data guidelines

Turn findings into implementation tickets

Use business exposure and confirmed severity to set priority:

Priority	Example	Next action
P0: restore access or indexing eligibility	Main service template returns server errors or accidental noindex	Escalate to the responsible developer or site administrator
P1: restore discovery or correct URL signals	Commercial pages are orphaned or point to the wrong canonical	Fix the template, links or URL signals
P2: improve experience and presentation	Slow resource pages, metadata defects or optional markup gaps	Schedule after blockers, unless the user impact is severe

Each ticket should contain affected URLs or templates, captured evidence, the proposed fix, an owner, dependencies and an acceptance test. Group shared template defects into one ticket rather than reporting hundreds of identical warnings.

For example, a ticket for accidental noindex on service pages should require affected URLs to return 200, show no noindex in the response headers or rendered HTML, and pass the relevant live inspection checks.

After deployment, recrawl affected URLs and run live inspections. Then monitor indexed results separately: a successful live test does not confirm indexing or predict Google’s selected canonical. URL Inspection documentation

Track technical recovery first, then search impressions, clicks and qualified enquiries for the affected pages. Keep deployment dates so later changes can be investigated without automatically attributing every traffic movement to the fix. For ongoing measurement, use a post-launch SEO feedback loop.