The Technical SEO Checklist That Actually Moves Rankings

Technical SEO audits have a habit of turning into fifty-item checklists where a missing meta description gets the same visual weight as a broken canonical tag. It isn't the same problem. Some technical issues quietly cap your traffic at zero no matter how good the content is; others are cosmetic and can wait. This is the list of what actually correlates with ranking and indexing problems, in roughly the order it tends to matter, plus how to check each one and what to do once you've found it.

1. Confirm Google can actually reach and render the page

Before anything else, check three things in Google Search Console: the Page Indexing report (this report replaced the old "Coverage" report in 2022, though a lot of older guides still call it that), the URL Inspection tool's rendered HTML, and whether your robots.txt is accidentally blocking a section of the site.

A page that looks fine in a browser but returns a near-blank shell to Googlebot, common on JavaScript-heavy sites without proper server-side rendering, will never rank no matter how good the content underneath the JavaScript is. Run URL Inspection on a sample of templates (not just one page, since a shared template issue breaks everything built from it), and compare the "rendered HTML" tab against what you see in a browser's view-source. If the rendered version is missing your main content, that's a render-blocking or hydration problem worth fixing before anything else on this list.

2. Fix indexing before you touch anything else

A page that isn't indexed can't rank, full stop, and this is where most technical audits should start spending time. The Page Indexing report in Search Console breaks out exactly why a URL was excluded, and the common causes worth checking, roughly in order of how often they show up, are:

• Accidental noindex tags left over from a staging environment that shipped to production
• Canonical tags pointing to the wrong URL (a self-referencing canonical is the safe default unless you have a deliberate consolidation reason)
• Duplicate or near-duplicate content getting consolidated onto a URL you didn't intend, which you'll see in the report as "Duplicate, Google chose different canonical than user"
• Thin or near-duplicate pages Google has decided aren't worth a crawl, shown as "Crawled, currently not indexed"

That last category is worth sitting with. "Crawled, currently not indexed" isn't a bug Google needs to fix; it's Google telling you the page didn't clear its bar for being worth serving. Thin pages built from a template at scale (location pages, tag archives, auto-generated category pages) are the most common source of this, and the fix is usually consolidation or genuine expansion, not a technical workaround.

3. Site speed, but the metrics that actually correlate with rankings

Core Web Vitals are a confirmed ranking signal, and as of Google's current documentation there are three: Largest Contentful Paint (loading, target under 2.5 seconds), Interaction to Next Paint (responsiveness, target under 200 milliseconds), and Cumulative Layout Shift (visual stability, target under 0.1) (Google Search Central, Core Web Vitals). Interaction to Next Paint replaced First Input Delay as the official responsiveness metric in March 2024, so if you're reading an older audit template that still references FID, it's out of date.

A 100/100 Lighthouse score isn't the goal; passing the field-data thresholds is. Lighthouse runs a single simulated lab test on one device profile. The Core Web Vitals report in Search Console, by contrast, uses real-user data collected from the Chrome User Experience Report (CrUX), aggregated across your actual visitor base. A site that passes Core Web Vitals with a 75 Lighthouse score is fine. A site that fails Core Web Vitals with a 100 Lighthouse score has a real problem the lab test didn't catch, usually something that only shows up on real devices and real network conditions, like a third-party script that blocks the main thread on mid-range Android phones but runs fine on the developer's laptop.

Check the Core Web Vitals report in Search Console at the URL-group level, not just the homepage. Templates fail independently; your product pages can pass while your blog template fails on CLS because of a late-loading ad slot.

4. Internal linking depth

Pages more than three or four clicks from the homepage get crawled less often and pass less authority through internal links, which is still one of the clearest signals Google uses to judge relative importance within a site. Run a crawl with Screaming Frog, Sitebulb, or a similar crawler, and sort by crawl depth.

Orphaned pages, meaning pages with zero internal links pointing to them from anywhere else on the site, are effectively invisible to search engines regardless of content quality, since a crawler has no path to discover them except through your sitemap (which helps with indexing but does little for authority flow). If you've got orphaned pages that matter, the fix is almost always adding contextual links from relevant existing content, not just adding them to a sitemap and hoping.

5. XML sitemap accuracy

A sitemap that includes noindexed, redirected, or 404 URLs sends mixed signals and wastes the crawl budget Google allocates to your site. Google's own guidance is direct about what belongs in a sitemap: only the canonical, indexable URLs you actually want crawled (Google Search Central, build and submit a sitemap).

If your CMS auto-generates the sitemap, audit a sample against the Page Indexing report's actual indexed count periodically. Drift between what's in your sitemap and what Google has indexed (a sitemap with 12,000 URLs against 6,000 actually indexed) is a signal that something changed upstream, whether that's a bulk content change, a migration that didn't update the sitemap generator, or indexing issues from items further up this list.

6. Structured data validity, not just presence

Having schema markup on a page doesn't help if it's invalid or doesn't match the visible content. Google's structured data general guidelines explicitly require that markup reflect what a user actually sees on the page, and Google can take manual action against markup that doesn't (Google Search Central, structured data guidelines).

One change worth knowing if you haven't audited structured data recently: Google retired FAQ rich results from standard search results in mid-2026, along with the related Search Console reporting (Search Engine Journal). If your technical audit template still flags "add FAQ schema for the rich result" as a quick win, that specific payoff no longer exists in regular search results, though FAQ schema can still help structure content for AI-driven features. Validate schema with the Schema Markup Validator for syntax, then check it manually against a template-level sample, since a broken schema template breaks every page built from it at once, not just the one page you happened to spot-check.

7. HTTPS and redirect chains

A single 301 redirect is fine and has effectively no cost. Three redirects stacked in a chain (http → www → https → final-url) burns crawl budget and dilutes a small amount of link equity at each hop. Audit for redirect chains specifically after any domain migration or URL structure change, since they accumulate silently and nobody notices until a crawl report flags a page three or four redirects deep.

8. Mobile usability and viewport configuration

Google has used mobile-first indexing for the entire index since 2023, meaning the mobile version of your page is what gets crawled, indexed, and used for ranking, not the desktop version. A page that renders fine on desktop but hides content behind a mobile menu that never loads, or that has tap targets small enough to trigger mobile usability warnings, is being evaluated primarily on that broken mobile experience. Check the Mobile Usability section under Search Console's Experience reports, and test your highest-traffic templates directly on a real phone, not just in a browser's responsive-mode simulator, since simulators miss real touch-target and viewport issues that show up on actual devices.

9. Log file analysis, if the site is large enough for crawl budget to matter

For a small brochure site, crawl budget is a non-issue; Googlebot can visit every page constantly without strain. Past a few thousand URLs, it stops being theoretical. Server log files show you exactly which URLs Googlebot actually requested, how often, and what status code each request got, which is a different (and more honest) picture than a crawl tool's simulation of how your site is structured.

Pull at least two weeks of raw server logs and filter for the Googlebot user agent (verify it's genuinely Googlebot by reverse-DNS lookup, since plenty of scrapers spoof the user-agent string). Look for three patterns: pages Googlebot is hitting constantly that don't deserve the attention (faceted navigation URLs, session-ID variants, internal search result pages), pages that matter but Googlebot rarely or never visits, and a spike in 404s or 5xx responses that didn't show up in a simulated crawl because your crawler didn't test the same URL set under the same conditions real traffic does.

This is the one item on this list that's genuinely optional for most sites and genuinely necessary for large ones. If you're running an ecommerce catalog with faceted navigation generating effectively infinite URL combinations, or a publisher with tens of thousands of archived articles, log file analysis will surface crawl budget waste that no other tool on this list will show you, because every other tool describes your site's structure, not what Googlebot is actually choosing to do with it.

Putting it in order

What to skip on a first pass

Meta description length, exact title tag character counts, and keyword density are worth cleaning up eventually, but they aren't why a site fails to rank, and spending the first week of an audit on them is a common way to feel productive while ignoring the problem that's actually capping traffic. If you're triaging a site with real ranking problems: indexing and crawlability come first, Core Web Vitals and internal linking second, and copy-level polish last. Fixing polish items before the structural ones is exactly how technical SEO audits turn into forty-item lists that never move a single ranking.

How this interacts with AI search visibility

Everything on this list is also a prerequisite for showing up in Google AI Overviews, ChatGPT search, and other AI answer engines, since all of them require a page to be indexed and crawlable as a baseline before any citation-specific factors come into play. If the technical basics here are solid and you're still not getting picked up as a source in AI answers, the next layer to work on is content structure and extractability, which we cover in how to get cited by ChatGPT and Google AI Overviews. For a broader look at what the shift toward AI-generated answers means for organic traffic overall, see how Google keeps expanding AI Overviews.

Tools worth using for this audit

A full crawl (Screaming Frog or Sitebulb) plus Search Console covers most of this list without a paid all-in-one platform. If you're deciding between Semrush and Ahrefs for the ongoing monitoring and site audit side of this, we've put together a direct comparison of Semrush vs Ahrefs pricing and strengths. There's also a running list of free AI SEO tools if budget is the constraint rather than workflow preference.

If you run a business with a physical location, technical fixes are only half the job. Your Google Business Profile carries a lot of weight in local results, and our roundup of AI SEO tools for Google Business Profile covers the tools that help you manage it at scale.

You don't need a paid crawler to work through this checklist. Several tools in our open-source SEO platforms roundup, including Lighthouse, Unlighthouse and SEOnaut, cover crawling and Core Web Vitals for free.

Clean markup sits underneath all of this. Our guide to semantic HTML for SEO covers which elements actually help Google and AI engines parse a page, and which popular rules (like "only one h1") are myths.

Most of this checklist also helps in AI answers, which is why we argue in AEO vs SEO that the two overlap more than vendors suggest. For the AI-specific checks, see our AEO checklist.

Two related calls come up in audits: whether to disavow spammy backlinks (usually not), and how to handle Google's September 2026 spam update if traffic dropped during it.

Working on a legal site? Our law firm SEO playbook applies this checklist to practice-area pages and YMYL content.

If Search Console shows pages stuck outside the index, our guide to why Google isn't indexing your pages walks through every status and fix.

FAQ

How often should I run a full technical SEO audit?

A lightweight check of indexing status and Core Web Vitals is worth doing monthly, since both can shift after a deploy without anyone noticing. A full crawl-based audit covering internal linking, redirect chains, and sitemap accuracy is reasonable quarterly, or immediately after any site migration, replatform, or major template change.

Does a perfect Lighthouse score mean I'm safe on Core Web Vitals?

No. Lighthouse is a single lab test on a simulated device and network profile. Google's actual ranking signal comes from field data collected from real visitors through the Chrome User Experience Report, visible in Search Console's Core Web Vitals report. A page can pass Lighthouse and fail the field-data thresholds, usually because of real-world conditions (slower devices, third-party scripts, variable network speed) that a single lab run doesn't capture.

Is "Crawled, currently not indexed" something I need to fix manually?

Usually, yes, but not through a technical trick. That status means Google crawled the page and decided it wasn't worth indexing, which is most often a content quality or duplication problem rather than a technical bug. The fix is almost always consolidating thin pages, expanding genuinely useful ones, or removing low-value pages entirely, not resubmitting the URL repeatedly through Search Console and hoping the decision changes.

Do redirect chains actually hurt rankings in a measurable way?

A single redirect has negligible impact. Chains of three or more do waste crawl budget and dilute a small amount of link equity per hop, and they're worth cleaning up, but they're rarely the reason a page isn't ranking. Treat this as a maintenance item you fix during a broader audit, not an emergency on its own.

What replaced First Input Delay in Core Web Vitals?

Interaction to Next Paint (INP) officially replaced First Input Delay as the responsiveness metric in March 2024. If you're working from an older checklist or a legacy monitoring dashboard that still references FID, update it, since Google stopped using FID as a Core Web Vitals ranking signal.

Is log file analysis worth doing for a small site?

Generally no. If your site has a few hundred or even a couple thousand pages, Googlebot has more than enough capacity to crawl everything regularly without you needing to verify it through raw logs. Log analysis earns its keep once a site reaches a scale where crawl budget becomes a real constraint, typically tens of thousands of URLs or a catalog structure that generates large numbers of near-duplicate pages through filters and facets.