The Technical SEO Checklist: 30 Checks That Actually Matter

Crawling is the front door. If Googlebot can't fetch a URL, nothing else on this list matters for that URL. These seven checks confirm the door is open, and that you're not wasting crawl budget on doors that should be closed.

1. robots.txt doesn't block anything important. Fetch /robots.txt and read every Disallow line. The classic failure is a staging rule (Disallow: /) that shipped to production, or a pattern like Disallow: /*? silently blocking faceted category pages you want indexed.
2. The XML sitemap exists, is referenced in robots.txt, and contains only canonical, indexable, 200-status URLs. A sitemap full of redirects and noindexed pages tells Google your site is poorly maintained and wastes its crawl requests.
3. Every important page is reachable within 3 clicks of the home page. Crawl your site with Screaming Frog and check crawl depth. Pages buried 5+ levels deep get crawled less often and inherit less link equity, a structural problem your internal linking architecture should fix.
4. No orphan pages. Compare your crawl output against your sitemap and analytics. URLs that appear in the sitemap but not in the crawl have zero internal links, Google may know they exist, but has no reason to think they matter.
5. Faceted navigation and URL parameters are controlled. Filters, sorts, and session parameters can multiply one category into thousands of crawlable near-duplicates. Block crawl-trap parameters in robots.txt and canonicalize the rest.
6. Redirect chains are ≤1 hop. Every hop adds latency and leaks link equity, and Google stops following after roughly 10 hops (5 per crawl session). Export chains from your crawler and repoint internal links straight to the final URL.
7. Server responds reliably to Googlebot. In Search Console's Crawl Stats report, check for spikes in 5xx responses or average response times above ~600ms. Sustained server errors cause Google to slow crawling of the whole site.

# A sane robots.txt for most sites
User-agent: *
Disallow: /cart
Disallow: /checkout
Disallow: /search
Disallow: /*?sort=
Disallow: /*?sessionid=

Sitemap: https://www.example.com/sitemap.xml

Indexation is a two-sided problem. Pages you need indexed sometimes aren't, and thin, duplicate, or parameterized junk often is, diluting how clearly Google models your site. The Page Indexing report in Search Console is your primary instrument here.

1. Indexed count roughly matches your count of valuable pages. If you have 800 real pages and Google reports 12,000 indexed, you have an index-bloat problem. If it reports 150, you have a discovery or quality problem. Either gap is a finding.
2. "Crawled, currently not indexed" is small and stable. A growing bucket here is Google telling you it fetched pages and judged them not worth storing, a content quality signal, not a technical bug. Consolidate or improve those pages.
3. Canonical tags are self-referencing on unique pages and point to the right target on variants. Spot-check with the URL Inspection tool: "Google-selected canonical" should match "user-declared canonical." When they disagree, Google is overruling you, investigate why.
4. No accidental noindex tags. Crawl for noindex in both meta tags and X-Robots-Tag HTTP headers. CMS plugins and migration leftovers put these in surprising places, and a single templated noindex can remove an entire page type.
5. Pagination is crawlable. Paginated archives should use plain crawlable links, self-canonicalize each page, and never canonicalize page 2+ to page 1, that hides every product or post that only appears deeper in the series.
6. One protocol, one host. HTTP, HTTPS, www, and non-www versions must 301 to a single canonical origin in one hop. Test all four combinations with curl.
7. Soft 404s and expired content are handled deliberately. Empty category pages and dead listings should return a real 404/410 or redirect to a genuinely relevant parent, not render a "no results" page with a 200 status.

“Index bloat is the quietest ranking problem there is. Google models your site from everything it indexes, every thin page in the index dilutes its confidence in the pages that matter.”

Google renders pages with an evergreen Chromium, but rendering happens in a second wave after crawling, can be deferred, and fails silently when scripts error or time out. If your framework is React, Vue, or anything client-heavy, this section is where audits find their biggest surprises.

1. Primary content exists in the server-rendered HTML. View source (not DevTools' rendered DOM) and search for your H1 and opening paragraph. If they're absent, you're depending entirely on Google's rendering pass. Prefer SSR or static generation for anything you want ranked.
2. Internal links are real <a href> elements in the initial HTML. Links injected by JavaScript, or built as click-handler divs, may never be discovered. Crawl once with JavaScript rendering off, any important page that disappears from the crawl is at risk.
3. Rendered output matches the source. Use URL Inspection's "View crawled page" to compare Google's rendered HTML against what users get. Watch for hydration replacing server content, or consent walls blanking the page for bots.
4. Nothing critical loads only on user interaction. Content behind "load more" clicks, infinite scroll without paginated URLs, or hover-triggered tabs is invisible to Googlebot, which doesn't click or scroll.
5. Render-critical resources aren't blocked. If robots.txt blocks your JS or CSS bundles, Google renders a broken page and may judge it low quality. Check the "Page resources" list in URL Inspection for blocked files.

Speed matters twice: as a modest ranking signal via Core Web Vitals, and as a large conversion and crawl-efficiency factor. The key discipline is measuring field data (what real Chrome users experience, via CrUX) rather than lab scores, Google ranks on the former.

1. LCP under 2.5s at the 75th percentile. The Largest Contentful Paint element is usually a hero image or headline. Preload the hero image, serve it in AVIF/WebP at the right dimensions, and never lazy-load it.
2. INP under 200ms. Interaction to Next Paint punishes heavy JavaScript. Break up long main-thread tasks, defer third-party scripts, and ship less JS, tag managers and chat widgets are the usual suspects.
3. CLS under 0.1. Reserve space for images (width/height attributes), ads, and embeds; never inject banners above existing content after load.
4. TTFB under ~600ms globally. Slow HTML responses cap everything downstream and throttle crawl rate. Cache at the edge or CDN; a dynamic origin response for content that changes weekly is wasted latency.
5. Total page weight and request count are sane. As a working budget: under ~1.5MB transferred and under ~80 requests for content pages. Every megabyte is a tax on mobile users and on your crawl budget.

Diagnose with PageSpeed Insights (which shows both field and lab data) and fix in the order LCP → INP → CLS, since LCP failures are the most common and most visible. For the full optimization playbook, see our Core Web Vitals guide.

The final six checks make your pages easier for machines to interpret and keep the site's signals clean. Structured data in particular has outgrown "nice to have", it's how you hand Google and LLM-based engines your entity model directly, which is central to how modern search parses entities.

1. Sitewide Organization schema plus page-type schema on every template. At minimum: Organization with sameAs, Article with author on posts, Product with offers on product pages, FAQPage where you have real FAQs. Validate with the Rich Results Test; details in our schema markup guide.
2. Schema matches visible content. Markup describing content that isn't on the page violates Google's guidelines and risks a manual action. Schema is a translation layer, not a place to add claims.
3. Titles and H1s are unique and descriptive per page. Crawl for duplicates, templated titles like "Products | Brand" across 400 pages flatten your entity signals and your click-through rate simultaneously.
4. Internal 404s and broken links are near zero. Every internal link to a dead page wastes crawl budget and equity. Fix the link at the source rather than papering over it with a redirect.
5. Hreflang is reciprocal and self-referencing (international sites only). One-directional hreflang pairs are ignored entirely. If you serve multiple locales, this check alone justifies the audit.
6. HTTPS is universal with no mixed content. Every asset loads over HTTPS, HSTS is set, and the certificate covers all subdomains in use.

Thirty checks is still a lot if you treat them as equals. Don't. Run them as a funnel:

• Day 1, kill switches. Check robots.txt, sitewide noindex, canonical sanity, and server errors. These four cause total failure and take an hour to verify.
• Day 2, full crawl. Run Screaming Frog (once with JS rendering, once without), export depth, orphans, chains, duplicates, and status codes.
• Day 3, index reconciliation. Compare crawl output, sitemap, and Search Console's Page Indexing report. Every mismatch between the three lists is a finding.
• Day 4, templates, not pages. Audit rendering, schema, and Core Web Vitals on one URL per template. A fix at the template level repairs thousands of pages at once.
• Day 5, ship the top ten. Write findings as tickets with evidence and expected impact, sorted by the priority table above. Ten shipped fixes beat two hundred documented ones.

Technical SEO decays continuously, every release can introduce a stray noindex, a new redirect chain, or a heavier JS bundle. Treat this checklist as recurring maintenance, and fold it into a broader SEO audit process that also covers content and links. A technically clean site doesn't rank by itself; it just guarantees that your content gets a fair hearing.