Technical SEO Audit: 20 Points to Check Before You Start
Content work without a technical audit is money spent for nothing — Google doesn't rank what it can't index correctly. The twenty points below are the minimum to check before you edit a single line of copy.
Indexing and accessibility (points 1-5)
1. Check robots.txt for a stray Disallow: / left over from development — a common reason a new site sits unindexed for months. 2. Cross-check sitemap.xml against the actual site structure: stale URLs in the sitemap that resolve to 404 confuse the crawler. 3. In Search Console, open the Page Indexing report and go through every exclusion reason individually, not just the total indexed count.
4. Check canonical tags on every template type — homepage, category, product page, blog post: the canonical should point to the page itself or a deliberately chosen version, not a random URL caused by a CMS bug. 5. Confirm HTTPS is configured with no mixed content — unencrypted images or scripts on an https page erode both browser trust and part of the ranking signal.
Architecture and duplicates (points 6-10)
6. Check whether the site creates duplicates by leaving www/non-www or http/https simultaneously accessible without a redirect — a classic source of link equity fragmentation. 7. Find duplicate titles and meta descriptions with a Screaming Frog crawl export: pages sharing an identical title almost always signal a structural problem, not just a forgotten edit.
8. Check the click-depth of key pages — anything past four clicks from the homepage gets crawled noticeably less often. 9. Look at internal linking structure: orphan pages with zero internal inbound links are found by Google only via the sitemap and get crawled less frequently. 10. Check pagination: links to subsequent pages need to be clickable <a href> elements, not just a JS handler that never changes the URL.
Speed and Core Web Vitals (points 11-14)
11. Check LCP (Largest Contentful Paint) in PageSpeed Insights for mobile — the target threshold is 2.5 seconds, anything above 4 seconds is rated "poor" and directly affects ranking as part of page experience. 12. Check CLS (Cumulative Layout Shift): layout shift from images missing width/height attributes, or ad blocks that pop in after load.
13. Check INP (Interaction to Next Paint), which replaced FID as the responsiveness metric as of March 2024 — heavy analytics scripts and chat widgets often block the main thread and increase tap-response delay. 14. Check image weight and format: JPEG and PNG on product pages instead of WebP or AVIF on a site with a thousand SKUs is the most common cause of poor LCP for e-commerce.
Mobile and structured data (points 15-17)
15. Check the Mobile Usability report in Search Console (or its current equivalent under Core Web Vitals) — text smaller than 12px and interface elements closer than 8px apart both count as usability errors. 16. Check structured data with the Rich Results Test: for e-commerce, Product and BreadcrumbList; for a local business, LocalBusiness; for a blog, Article.
17. Check hreflang for multilingual sites: across three versions — ru/uz/en — every language version needs to link to itself and to the other two, including x-default. One-directional or incomplete hreflang chains get ignored by Google at best, or confuse which language version shows in results at worst.
Content-adjacent technical signals (points 18-20)
18. Check title and description uniqueness across the whole site — a 5% overlap is tolerable, a 30% overlap is already a template-level structural problem. 19. Check the H1-H2-H3 heading hierarchy: a single H1 per page, and logical subheading nesting that doesn't skip levels for visual styling reasons.
20. Check error page behavior: a custom 404 page with navigation and search instead of the hosting provider's default template, and correct response codes — 410 for pages permanently removed, instead of a soft 200 with "page not found" text that misleads the crawler.
Using the checklist in practice
Work through the points by effort, not by importance ranking: indexing and duplicates (1-10) get fixed quickly and show results within weeks; Core Web Vitals (11-14) need developer time and roughly a month to stabilize; multilingual setup and structured data (15-20) are a one-time configuration with a long payoff.
Record a baseline before you start: a screenshot of the Search Console reports, a Screaming Frog crawl export, and PageSpeed Insights numbers. Without a fixed starting point, three months later there's no way to prove to a client — or to yourself — that the technical audit actually changed anything.