The Technical SEO Checklist

How is priority set in a technical SEO audit?

Ask first not "how many errors does the site have?" but "which error makes a core page invisible?" A site with thousands of warnings can function, while one wrong noindex can remove a revenue page from search entirely. In an SEO system, the technical audit must be prioritised by business value, the number of affected URLs and the problem's severity.

Before the audit, list the strategic pages separately: core services, revenue categories, pillar articles and brand pages. To rank the site higher on Google, open these URLs' technical path first; don't spend all the time on cosmetic errors in low-value archives.

How are crawling and indexing checked?

Crawling is Googlebot reaching the URL; indexing is the content being processed in Google's systems and stored for search. They're not the same stage. A URL can be crawlable but excluded from the index as duplicate, thin or unfit content. In Search Console, read the Page Indexing and URL Inspection results together with the server response.

1–5. Access and index signals

1. Check Googlebot access. The core page, article, category and service paths must not be blocked by robots.txt.
2. Check noindex signals. Open the HTML meta tag and the HTTP X-Robots-Tag response separately.
3. Confirm public accessibility. A page meant for indexing must not sit behind a login, IP restriction or an accidental security rule.
4. Find orphan URLs. Separate pages visible in the sitemap and analytics that receive no internal link from the site.
5. Write the archive strategy. Tag, author, filter and internal search pages should stay in the index only if they hold distinct value for users.

robots.txt is not a reliable way to remove a page from Google's results. Per Google's robots.txt guide, a blocked URL can be found through other links and appear in results without a content description. If you want a page out of the results, let Googlebot crawl the URL and use noindex, or protect the content with a password.

How are status, canonicals and the sitemap checked?

A page's visible design can be fine while the server gives Googlebot the wrong answer. So looking in the browser isn't enough. The HTTP status, the canonical target and the sitemap entry must show the same URL decision.

6–12. URL and server checks

6. Check the HTTP status. A URL meant for indexing must return 200, a deleted page a real 404 or 410, and a permanently moved page a fitting redirect.
7. Find soft 404s. An empty "not found" page returning 200 is a contradictory signal for Google.
8. Shorten redirect chains. An old URL should go as directly as possible to the final, working, fitting page.
9. Add self-canonicals. An indexed core page should point its canonical at its own full HTTPS address.
10. Open the canonical target. The target must return 200, must not be blocked and must genuinely represent the content.
11. Consolidate URL variants. HTTP/HTTPS, www/non-www, trailing-slash and parameter variants must not create conflicting canonicals.
12. Clean the sitemap file. Only canonical, working URLs intended for indexing should remain.

In Google's canonicalization guidance, permanent redirects and rel="canonical" are listed as strong signals, and sitemap inclusion as a weak canonical signal. Showing URL A in the sitemap and URL B as canonical in the HTML doesn't strengthen the decision — it makes it contradictory.

A sitemap eases discovery; it doesn't guarantee indexing. Google's sitemap explainer says most pages of a small, well-interlinked site can be found without one, while sitemaps are more useful for large, new or weakly externally linked sites. Don't turn it into a URL warehouse.

How are rendering, on-page and schema checked?

Google doesn't just grab the source HTML and stop; it can put JavaScript pages into a separate render queue. Per Google's JavaScript SEO documentation, server-side rendering or pre-rendering is still a healthy choice for users and crawlers, because not all bots run JavaScript and content in the initial HTML simplifies the process.

13–18. Render and content checks

13. Compare the rendered HTML. The title, main text, internal links, canonical and robots signals must not disappear between source and render.
14. Build crawlable links. Internal navigation should use real <a href="...">; don't rely on elements bound only to click events.
15. Write unique titles and descriptions. 50–60 and 140–160 characters are practical editorial targets, not Google's hard limits. The text can be replaced per query in the results.
16. Give a clear main heading. The H1 count is no magic ranking rule; what matters is the heading precisely showing the page's intent.
17. Check the content hierarchy. H2s should answer real sub-questions, TOC links should work and repeated heading blocks — as in SEO mistakes — should not appear.
18. Match the schema against the visible text. Article, Breadcrumb and other JSON-LD fields must not create author, price, review or service claims absent from the page.

Structured data can help Google classify the page and create candidacy for fitting rich results, but it gives no display guarantee. An FAQ in the visible content can be useful for users; the FAQ rich result, though, is currently limited mostly to recognised government and health sites. So adding FAQ schema to every blog post and promising a separate result is wrong.

How are performance and mobile experience measured?

The speed part of a technical SEO audit isn't only a Lighthouse score. Lab data helps reproduce the problem; field data shows what real users experience. In the Core Web Vitals documentation, Google recommends keeping LCP within 2.5 seconds, INP below 200 milliseconds and CLS below 0.1 for a good experience.

19–22. User-experience checks

19. Find the LCP element. If the hero image or main text block lags, check its size, preload, priority and the server response with a waterfall.
20. Stop layout shifts. Reserve dimensions for images and video, test font swapping and late-arriving banners.
21. Isolate the INP cause. Measure long JavaScript tasks, heavy third-party scripts and main-thread blocking in real interactions.
22. Check the mobile render separately. Text, tables, the menu, forms, dark/light appearance, keyboard focus and touch targets must work.

Serve images in WebP or AVIF at the displayed size; lazy-load below-the-fold media except the LCP image. Keeping fonts local isn't enough on its own: the preload and font-display strategy must not create a jump at first paint. If visitors brought by content marketing won't wait on a slow page, the technical debt has already become a business problem.

What's needed for AI Search and monitoring?

There's no need to hunt for a separate technical "hack" for AI results. Google's generative AI optimisation guide writes openly that llms.txt doesn't help Google visibility, no special schema is required and artificially chopping content into small pieces isn't mandatory. Clear technical structure, unique usefulness and trustworthy human-first content remain the foundation.

23–25. Measurement and continuous oversight

23. Verify the Search Console account. Track the sitemap, URL Inspection, Page Indexing, manual actions, security and Core Web Vitals reports with a named owner.
24. Join the server and analytics signals. Check 404s, 5xx, redirects and bot access from the logs; core business actions from GA4.
25. Retest after changes. Add the prior result, the fix, the release date and the final confirmation to the audit log. Document the cause and effect, not the position.

Choose the article fact-check rhythm by risk. If taxes, law, health, prices and platform features change fast, tighter review is needed; don't present a stable explanation as refreshed by merely changing its date because "six months passed." Measure the backlink profile and technical health separately, then compare how they affect the same strategic URL.

Don't separate the technical foundation from the AEO and GEO strategy. If the page is unreachable for a bot, even a clear answer and a good source may not be processed. Conversely, technically flawless text offering no new idea is only a candidate for indexing — not for being chosen.