Technical SEO in 2026: the complete field guide

Technical SEO in 2026 is still the same job it always was: make sure engines can crawl, render, understand, and trust your pages, fast. What changed is that "engines" now includes AI answer engines, and one Core Web Vital (INP) quietly became the metric most sites fail. This is the field guide I work through, foundation up, when I audit a site.

Crawlability and indexing: the foundation

If an engine cannot crawl and index the page, nothing else matters. Confirm the basics: a clean robots.txt that does not block what you want indexed, an accurate XML sitemap listing every canonical URL with a lastmod, one canonical URL shape (do not mix trailing-slash and non-trailing-slash), and no stray noindex. Then look one level deeper. Orphan pages, URLs in the sitemap that nothing internally links to, get crawled rarely and indexed slowly, because crawlers follow links, not just sitemaps. Redirect chains (a URL that 301s to another that 301s again) waste crawl budget and leak a little signal at each hop, so collapse them to a single hop.

Watch for "discovered, currently not indexed" in Search Console. On a newer or lower-authority site that status is usually a crawl-priority signal, not a code fault: Google found the URL but has not prioritised crawling it. Verify there is genuinely no block or noindex first, then the fix is authority and patience, request indexing for a few priority URLs and earn some links, not more code.

Rendering: give crawlers the content in the HTML

Engines are best at content that is present in the server-rendered HTML. If your primary content only appears after client-side JavaScript or a user interaction, an accordion that is not in the DOM until clicked, or infinite-scroll content that never loads for a bot, it may not be indexed reliably. The check is simple: view the raw HTML source (or fetch it with curl), not the rendered browser view, and confirm the words that matter are actually there. If they are injected later by script, move the important content into the initial render. Hydration mismatches are the subtler version of this: if the server HTML and the client render disagree, a framework can blank the content, so treat hydration warnings as real bugs, not noise to suppress.

Core Web Vitals: INP is the one to watch

Google's Core Web Vitals thresholds are stable: LCP under 2.5s, INP under 200ms, CLS under 0.1. The catch most teams miss is that these are graded on real Chrome-user field data at the 75th percentile, so a green Lighthouse run with red field data still fails. Lab tools are a proxy for finding problems, not the score itself.

In 2026, INP is the metric that bites: roughly 43% of sites fail the Interaction to Next Paint threshold, and mobile is the weak spot. INP measures how quickly the page responds to a tap or click, so the usual culprit is heavy JavaScript occupying the main thread. The fixes are concrete: break long tasks into smaller chunks so the browser can respond between them, defer or lazy-load scripts that are not needed for the first interaction, remove unused third-party tags, and keep event handlers cheap. For LCP, the lever is usually the hero: serve a right-sized, compressed image, load it eagerly, and do not hide the largest element behind a fade-in animation. For CLS, give every image and embed explicit dimensions and reserve space for anything that loads late, so nothing jumps.

Structured data: help engines understand the page

Schema does not rank you, but it helps engines and LLMs parse what a page is and trust it, and it makes some rich results eligible. Mark up only what is visible on the page, keep the JSON valid (one trailing comma kills the whole block), and use absolute URLs. Use the Rich Results Test before shipping. Which types actually earn AI citations, and which quietly backfire, is its own topic: schema markup that earns AI citations. Two traps are worth flagging because they produce invalid items in Search Console: multiple Review objects with no aggregateRating, and self-serving reviews (an entity reviewing itself), which earn no star result at all. When schema fits the content, it is cheap trust; when it describes things the user cannot see, it is a guidelines risk.

AI-crawler access: the 2026 addition

The new technical surface is deciding which AI crawlers may read your site. For most brands you want the retrieval bots (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) to reach you so you can be cited, and you control that in robots.txt. Note two things. Google does not support IndexNow, so for Google the fast-index levers remain the sitemap and Search Console; IndexNow pings Bing and its partners, which is what powers ChatGPT Search and Copilot. And Google-Extended has no server-side crawler you can block selectively, so robots.txt is the only lever for it. I dug into which of these files actually do anything in llms.txt and AI crawler control.

Handling site moves without losing equity

Most self-inflicted technical damage happens during changes. Renaming or removing a published URL without a 301 redirect turns it into a dead page and throws away the ranking equity it earned, so every changed URL needs a permanent redirect to its replacement. Migrations magnify this: map old to new URLs one to one before you ship, keep the redirects in place, and re-submit the sitemap afterwards. And remember Google indexes mobile-first, so if the mobile version renders less content or behaves worse than desktop, the mobile version is the one being judged.

Ship it as engineering tickets

An audit that lands as a 40-page PDF dies in a downloads folder. The version that works is scoped tickets with a clear fix, an owner, and an acceptance check, written in the language the dev team already uses. Prioritise by impact and effort: fix the issues that block indexing or fail Core Web Vitals before the cosmetic ones, and put each behind a measurable acceptance criterion so "done" is not a matter of opinion. That is the whole argument of a technical SEO audit that ships as eng tickets, which is the how-to companion to this guide.

Where to start

Run it top down: crawl and index first, then rendering, then Core Web Vitals (start with INP on mobile), then schema, then AI-crawler access. Fix the blocking issues before the polish, and re-check the field data a few weeks after each change, because CrUX reflects real users over time, not your last deploy.

Want a prioritised, ticket-ready technical audit of your site? See how I run one.

Further reading

• Technical SEO fundamentals
• Google Search Central documentation
• web.dev: Core Web Vitals