Technical SEO: what the work actually covers

// In this article+

Most agency service pages bundle technical SEO into a single line item, and few say where one workstream stops and the next begins. Technical SEO is the work that decides whether a search engine can find, crawl, index, and render a website at all. That's separate from the words on the page or the links pointing at it. Veruska Anconitano, the multilingual SEO and localization consultant who wrote Search Engine Land's guide to the subject ↗︎, puts the stakes in one line: "None of that matters if search engines can't find, understand, or access your content". The work splits into distinct pieces: crawlability, indexation, site architecture, page speed, structured data, canonical tags, and the audits and migrations that touch several of them at once. Google documents each piece on its own page, with its own last-updated date.

This piece defines each workstream against that guidance as it stood in September 2026. It also shows the point where a routine audit turns into a migration project.

Summary

• What separates the distinct workstreams inside technical SEO, and where content or link-building work begins instead.
• What a technical SEO audit actually produces, and how often to run one.
• Why Google treats a canonical tag as a hint rather than a rule, and what makes it override one.
• What a site redesign or migration adds to the scope, and the one deliverable that cannot be skipped.
• Where Core Web Vitals and sitemap work stand as of the September 2026 refresh, measured against current field data.

What does technical SEO actually cover?

Search Engine Land's own framework for the term draws roughly the boundary Google's documentation implies: crawlability, indexability, site architecture, page speed, mobile-friendliness, HTTPS, structured data, and canonicalization. Search Engine Land's guide to the term ↗︎ defines technical SEO as "the process of optimizing your website's infrastructure so search engines can crawl, render, index, and serve your content correctly and efficiently". A companion guide from the same publication ↗︎ calls the same discipline "behind-the-scenes website optimizations that make it easier for search engines to discover, crawl, index, and render pages on your website more effectively". Both descriptions point at the same ground. Where they differ is packaging, not substance.

The core workstreams break down as:

• Crawlability: can an automated crawler reach and fetch the page.
• Indexability: can the page be added to the index once it's fetched.
• Site architecture: how pages are organized and linked internally.
• Page speed and Core Web Vitals: how fast a page loads and responds.
• Mobile-friendliness and HTTPS: baseline rendering and security requirements.
• Structured data: schema.org markup describing what a page is.
• Canonicalization: which URL represents a set of duplicate or near-duplicate pages.
• Migrations and redesigns: the project work that touches several of the above at once.

Agency service pages tend to package these into one purchase. Thrive Agency's technical SEO page ↗︎, for one example, offers a comprehensive technical audit to find and fix site issues. The same page separately offers website migration handled through URL mapping and traffic monitoring. An audit and a migration are two workstreams. They carry different deliverables, different timelines, and different failure points. The page doesn't say where one ends and the other starts. That gap is what this piece closes.

Draw the boundary this way: technical SEO changes how a machine reads a site, not what the site says or who links to it. The words on a page are content work. The links pointing at the page from other domains are outreach work. A newer boundary sits next to that one. Generative engine optimization (GEO), also called answer engine optimization (AEO) or AI search optimization, is the discipline of getting a business cited inside an AI-generated answer rather than ranked in a list of links. This piece uses AI search optimization from here on. As the FAQ below covers, Google's AI features guidance ↗︎ treats AI search optimization as resting on the same technical foundation, not as a separate set of requirements.

What is a technical SEO audit, and what does it produce?

A technical SEO audit is a specific, repeatable deliverable, not a synonym for the whole engagement. It produces three things.

A crawl report. A list of every URL a crawler found, with response codes, redirect chains, and pages blocked by robots.txt or a noindex tag.

An indexation map. Which of those URLs Google has actually indexed, which it has excluded, and why, pulled from Search Console's coverage data.

A prioritized fix list. The problems ranked by how much organic visibility they cost, not by how easy they are to fix.

That ordering matters. Fix crawl and indexing errors first, since a page Google cannot index will not rank regardless of anything else done to it. Core Web Vitals and other page-experience signals come second. Structured data comes third, since it changes how a result is displayed more than whether it appears at all.

A full audit tends to run best on a quarterly cadence. A lighter monthly pass in between just watches Search Console for new crawl or indexing errors. A site under active remediation needs a tighter cycle. Google changed how it enforces its site reputation abuse policy on 2026-08-30. Outside the EEA, a manual action under that policy still demotes the portion of the site it covers and leaves the rest of the site alone. Inside the EEA, the manual action no longer applies. Google may instead separate the affected section in its systems so that, over time, it ranks on its own, per Google's policy update ↗︎ and Search Engine Land's report on the change ↗︎. An audit on an affected site now has to check where the abusive section sits. It also has to check which searchers the action still reaches.

What does canonical tag work involve?

Canonical tag work starts with Google's canonicalization documentation ↗︎. A canonical URL is the page Google marks as canonical after judging it "objectively the most complete and useful for search users" among a set of duplicate or near-duplicate pages. Google states plainly that rel=canonical and other canonicalization signals are "a hint, not a rule." Google clusters duplicate pages together first. It picks the one it judges best, whatever the page's own markup claims.

That means a stated canonical gets overridden in predictable situations:

• HTTP versus HTTPS. If both versions of a URL are live and only one is marked canonical, Google may still choose the secure version if it is the one most consistently linked to and indexed.
• Redirect chains. A canonical pointing at a URL that itself redirects elsewhere sends a mixed signal, and Google tends to follow the redirect's destination instead.
• Sitemap mismatches. If the XML sitemap lists a different URL than the one marked canonical, that mismatch is itself a signal Google weighs against the tag.

The practical takeaway: check what Google actually indexed in Search Console rather than assuming the canonical tag was obeyed. If the indexed URL doesn't match the stated one, one of the three causes above is usually why.

What does a site redesign or migration add to the scope?

A site redesign or migration adds one thing a routine audit doesn't carry: a change to the URLs themselves. Everything else follows from that: the ranking signals attached to the old URLs have to transfer to the new ones.

Google's own site-move documentation ↗︎, refreshed the same week as the canonicalization page, gives the operating rules. Split the move into smaller steps where that makes sense for the site, though a smaller site can usually move all its URLs simultaneously. Whichever approach is used, keep the redirects live for at least a year.

The single deliverable that cannot be skipped is the redirect map: every old URL matched to its specific new destination. Test it on staging before launch. A common and costly mistake is redirecting everything to the homepage instead of to the corresponding new page. A homepage-only redirect tells Google the specific content at the old URL no longer exists anywhere. That's a bigger signal loss than a slower, correctly mapped migration.

This is the point where the engagement stops being an audit and becomes a project. A redesign, a CMS change, or a domain move all carry the same redirect-map requirement. When an outside firm runs the redesign, the SEO questions to put to a web design agency belong in the contract before the templates are built. That's the shape of the work behind our technical SEO services.

What does Core Web Vitals optimization involve today?

Core Web Vitals optimization covers three metrics Google uses as page-experience signals:

• Largest Contentful Paint (LCP). The time until the main content renders.
• Interaction to Next Paint (INP). The responsiveness of the page to a user's interaction.
• Cumulative Layout Shift (CLS). How much visible content moves while a page loads.

Google's current Core Web Vitals thresholds ↗︎: LCP within the first 2.5 seconds, INP under 200 milliseconds, and a CLS score under 0.1.

Field data shows most sites are still short of that bar. As of the May 2026 Chrome UX Report, cited in Digital Applied's Core Web Vitals benchmarks ↗︎, only 55.9% of tracked origins passed all three Core Web Vitals, down 0.8 points from April. Broken out by metric, 68.6% of origins passed LCP, 81.3% passed CLS, and 86.6% passed INP. LCP is the weakest of the three.

That pattern shows up often in a post-redesign audit. A site that passed Core Web Vitals before a redesign fails LCP after it. Usually a hero video, an image carousel, or a font-loading delay got added above the fold without anyone checking its render time. Pull the current pass rate and compare it against the 55.9% field average. That's the fastest way to tell a client whether their site is ahead of the field or behind it. Catching the regression before launch takes a per-template performance budget set from the old site's own field data, the method behind Core Web Vitals optimization that survives a launch.

What belongs in an XML sitemap, and what doesn't?

An XML sitemap is a file that lists the URLs on a site an owner wants a search engine to know about. It's submitted through Search Console or referenced in robots.txt. Google's build-sitemap documentation ↗︎ sets hard limits: a single sitemap file is capped at 50MB uncompressed or 50,000 URLs, whichever comes first. A larger site needs a sitemap index that points to multiple files.

What belongs in it: canonical, indexable URLs the site actually wants ranked. What doesn't: pages marked noindex, URLs that return a 4xx or 5xx status, redirects, and non-canonical duplicates. Google states it ignores the priority and changefreq tags entirely. It may use an accurate lastmod date as a signal for when to recrawl a page. That tag is worth keeping current rather than static.

A sitemap that still lists thousands of noindex or redirected URLs from a prior CMS is one of the more common findings in an audit's crawl report. It's a cheap fix relative to almost everything else on the prioritized list.

What to do this week

1. Run a crawl and check indexation before anything else. Indexing problems outrank every other fix on the priority list.
2. Pull the current Core Web Vitals pass rate from PageSpeed Insights or the Chrome UX Report and compare it against the 55.9% field average from Digital Applied's benchmarks ↗︎.
3. If a redesign or CMS migration is scheduled, build the URL redirect map first and budget a year of live redirects, per Google's site-move guidance.
4. Audit rel=canonical tags against the three override conditions above (HTTPS versus HTTP, redirect chains, sitemap mismatches) instead of assuming the tag is obeyed.
5. Check the sitemap for noindex, 4xx, or redirected URLs that shouldn't be listed.
6. If the business operates in the EEA, recheck any existing site reputation manual action against the new regional enforcement split.

FAQ

Is technical SEO a one-time project or an ongoing service?

Both, depending on the workstream. Crawlability and indexation need ongoing monitoring, since a CMS update or a new template can silently break either one. A migration or redesign is a one-time project with its own start and end date, built around the redirect map described above.

How is a technical SEO audit different from a full technical SEO engagement?

An audit is a diagnostic deliverable: a crawl report, an indexation map, and a prioritized fix list. The engagement is the work of actually fixing what the audit found, plus the recurring workstreams, like Core Web Vitals monitoring and sitemap maintenance, that don't stop once the audit is filed.

Do AI Overviews and AI Mode require different technical SEO than regular Google Search?

No. Google's own AI features documentation states there are "no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary," and no special schema.org structured data is needed beyond standard indexing eligibility. AI search optimization depends on the same crawlability, indexation, and structured-data foundation covered above. It doesn't replace it.

What is the single most consequential deliverable in a site migration?

The redirect map. Every other migration task, from updating internal links to resubmitting the sitemap, depends on the old-to-new URL mapping being correct and complete before launch, not patched together afterward.

How often should a site run a technical SEO audit?

Quarterly for a full audit, with a lighter monthly check of Search Console for new crawl or indexing errors in between. A site under active remediation, such as a site reputation abuse manual action, needs a tighter cycle until the issue is resolved.