Technical SEO

The stage everything else depends on.

Technical SEO is the work of removing the reasons a search engine cannot reach, store, understand or comfortably show your pages. It is the least visible part of a search program and the part that puts a ceiling on everything else.

CrawlCan a search engine reach it
IndexDid it decide to store it
RenderDoes it load fast enough to matter
Search and answer surfaces this work targets: Google Business Profile, Bing Places, Apple Maps, ChatGPT, Google Gemini and Perplexity.
A contour terrain model built from stacked layers of pale card, with a single slender brass pin standing at its highest point.
In short

What is technical SEO and why does it come first?

Technical SEO covers everything that determines whether a search engine can crawl your pages, index them, understand what they are about, and render them quickly on a phone. That includes site structure and internal links, redirects and canonical tags, duplicate content, sitemaps and robots directives, page speed and Core Web Vitals, and structured data.

It comes first because the other stages depend on it. A page blocked from crawling can never rank. A page that has been crawled but not indexed cannot rank either. Two near-identical pages compete with each other instead of one of them winning.

Most of it is a one time cleanup followed by light monitoring, not a permanent retainer. Anybody billing for technical SEO every month indefinitely should be able to show you what changed.

Plain language

Three stages, in order

A page becomes a ranking through three stages, and a failure at any one of them makes the stages after it irrelevant. Almost every disappointing SEO result traces to a stage one or stage two problem being treated with stage three tactics.

Crawling is a search engine following links and fetching pages. It can be blocked by a robots.txt rule, by a page nothing links to, by a login wall, or simply by a site so large and badly organised that the important pages are buried.

Indexing is the engine deciding to store and understand the page. Google does not index everything it crawls, and Search Console will tell you exactly why it skipped something. Duplicate content, thin content and pages that add nothing are the usual reasons.

Ranking is the last stage, and it is the only one most people think about. Content and link work operate here. If the first two stages are broken, all of that effort is invisible.

Diagnosis

Where the blockage usually is

Search Console reports each stage separately, for free, which makes this diagnosable rather than mysterious.

Crawl, index, rankThree stations in a row. First a crawler finds the page, then the page is stored and understood, and only then can it be chosen and placed in an order for a given search.A PAGE ONLY RANKS AFTER TWO EARLIER STEPS SUCCEEDCRAWLA CRAWLER FINDSTHE PAGE AT ALLINDEXIT IS STORED ANDUNDERSTOODRANKIT IS PICKED ANDPLACED IN AN ORDERIF STEP ONE OR STEP TWO FAILS, STEP THREE NEVER HAPPENS.
Discovered but not crawled, crawled but not indexed, and indexed but not ranking are three different problems with three different fixes.

Discovered but not crawled usually means an internal linking or crawl budget problem: the page exists but nothing important points at it.

Crawled but not indexed usually means Google looked and decided the page was not worth storing, which is a content and duplication problem wearing a technical costume.

Indexed but not ranking is the genuine content and authority problem, and it is the only one of the three that content work will fix.

In priority order

What the work actually consists of

Roughly the sequence we follow, because the early items unblock the later ones.

  1. Crawl the site the way a search engine would

    A full crawl reveals what is actually there rather than what the sitemap claims. Broken links, redirect chains, pages with no internal links pointing at them, parameters generating thousands of near-identical URLs, and pages that return the wrong status code.

  2. Resolve duplication and cannibalisation

    Two or more pages targeting the same thing is the most common and most damaging problem on established sites, and it is usually the result of years of well meant additions. The fix is consolidation and redirects, which means deleting pages, which clients find counterintuitive and which usually produces the largest single improvement.

  3. Fix the directives

    Robots.txt, meta robots tags, canonical tags, hreflang where relevant, and the XML sitemap. These quietly contradict each other on most sites: a page canonicalised to another page while also being submitted in the sitemap, or a section blocked in robots.txt while pages inside it carry noindex tags that can never be read because crawling is blocked.

    • One canonical per page, pointing somewhere sensible
    • A sitemap that contains only indexable, canonical URLs
    • Robots rules that do not block the things you want crawled
See the remaining steps: What the work actually consists of4 more stepsHide the remaining steps: What the work actually consists of
  1. Make the structure navigable

    Internal linking is a technical lever as much as an editorial one. Important pages should be reachable in a few clicks from the home page, related pages should link to each other, and orphaned pages should either be linked or removed.

  2. Deal with speed as a measured problem

    Image weight, render blocking resources, font loading, third party scripts and layout stability, measured against Google's published Core Web Vitals thresholds using field data rather than a lab score.

  3. Add structured data that matches the page

    Schema markup describes what a page is about in a form machines read directly. It has to match what is visible on the page, which is both a Google requirement and simply honest. We use Organization, LocalBusiness, Service, Article, FAQPage and BreadcrumbList where they genuinely apply.

  4. Monitor rather than bill

    After cleanup, the ongoing work is small: watching index coverage, catching new errors after site changes, and re-checking after a platform update. We would rather tell you the heavy work is done than invent a monthly technical retainer.

A cleanup on an established site usually takes four to eight weeks depending on platform and how much has accumulated.

Core Web Vitals

The thresholds to hold anyone to

Google publishes these. They are not an agency interpretation, and you can check them yourself in Search Console using data from real visits to your site.

2.5sLargest Contentful Paint, good threshold
200msInteraction to Next Paint, good threshold
0.1Cumulative Layout Shift, good threshold
75thpercentile of page loads at which they are measured

SourceCore Web Vitals thresholds, Google (web.dev)

The 75th percentile detail is the one that catches people out. Three quarters of real visits have to be good, so a fast average propped up by desktop users on fast connections does not pass.

Structured data, without the overselling

Schema markup is a standardised vocabulary for telling a machine what a page is about: that this is a local business, this is its address, this is a service, this is an article by a named author. It is invisible to readers and read directly by search engines and by the systems that assemble AI answers.

What it genuinely does: makes a page unambiguous to machines, supports certain rich results, and feeds the entity understanding that search engines and assistants build about your business.

Read the full breakdown: Structured data, without the overselling2 more paragraphsHide the full breakdown: Structured data, without the overselling

What it does not do, despite being sold this way constantly: it is not a ranking factor in itself, and FAQ markup in particular no longer produces the rich result most people are buying it for. Google restricted FAQ rich results in 2023 to well known authoritative government and health sites. The markup still has value for machine readability. It does not have the value it did.

The non-negotiable rule is that structured data must describe what is actually on the page. Marking up reviews you did not collect, or a rating you cannot substantiate, is both a policy violation and a straightforward misrepresentation. We publish review markup only from reviews collected through a first-party process.

Warning signs

How to tell technical SEO is theatre

This is the easiest service to bill for without doing, because the client cannot see any of it.

  • A monthly report that is a tool export with hundreds of issues and no indication of which ones matter or which were fixed.
  • Errors counted rather than resolved. Two hundred issues identified and forty seven fixed is a report. Which forty seven, and what changed as a result, is the actual work.
  • A PageSpeed Insights score presented as the goal. It is a lab diagnostic. Field data in Search Console is what Google actually uses.
  • Schema markup added that does not correspond to anything visible on the page, or review markup for reviews that were never collected.
  • No before and after on index coverage. If pages were being excluded and now are not, that is the clearest possible evidence something real happened.
See the full checklist: How to tell technical SEO is theatre3 more itemsHide the full checklist: How to tell technical SEO is theatre
  • Nobody can name a page that was deleted or merged. Consolidation is usually where the biggest gains come from, and it never happens in accounts where nobody is willing to remove anything.
  • A permanent technical retainer years into an engagement with no explanation of what is still being done.
  • Recommendations that require a rebuild when a targeted fix would do, which is sometimes a genuine assessment and sometimes a sales strategy.

The honest test: ask what specifically changed on the site this month and what number it was expected to move.

What varies by platform

WordPress problems are usually accumulation: overlapping plugins that each generate their own sitemap, tag and category archives producing hundreds of thin pages, page builders that emit heavy markup, and years of drafts and revisions. The work is mostly subtraction.

Shopify problems are structural: the platform generates a URL for every product inside every collection, faceted navigation multiplies URLs, and out of stock or discontinued products leave pages that need a decision rather than deletion.

Site builder platforms constrain what can be fixed at all. Some cannot expose the controls needed, and the honest answer in those cases is that there is a ceiling and a migration is the only way past it.

Custom builds and modern JavaScript frameworks raise a different question: whether content is present in the initial HTML or only after scripts run. Search engines render JavaScript, but rendering is slower and less reliable than reading HTML, and for AI systems that read pages without executing scripts it may not happen at all.

How this is measured

Index coverage in Search Console is the primary measure: how many of your pages are indexed, how many are excluded, and for what stated reason. A technical engagement that does not move that report has not done much.

Core Web Vitals from field data, again in Search Console, rather than a lab score.

Crawl statistics, which show how often Google fetches your site and what it receives. A site returning large numbers of errors or redirects is spending crawl effort on nothing.

Then the ordinary outcome measures. Technical work rarely produces an immediate ranking jump on its own. What it produces is the ability for content and authority work to register at all, which is why it is sequenced first and judged over a longer window.

How this connects to the rest

This is the foundation stage of our SEO and GEO program. Content strategy is the stage that comes after it, and publishing into a site with unresolved technical problems is the most common way a content budget is wasted.

It overlaps heavily with website speed optimisation, which is the same work viewed from the conversion side rather than the crawling side, and with the build standards used in web design and development.

It is also the substrate for answer engine optimisation and GEO. A page that cannot be rendered cleanly or that contradicts your other sources is not going to be used as a source by anything.

An SEO audit is the diagnostic that tells you which of these problems you actually have, and is the sensible starting point if you are not sure.

What we need from you

Developer or admin access to the site, the hosting, and Search Console. Read-only access is not enough to do the work, and a staging environment is strongly preferred for structural changes.

A decision maker who can approve deletions. Consolidation is where the largest gains come from and it means removing pages somebody once wrote, which is a decision we cannot make for you.

Notice before the site changes. Most new technical problems arrive with a theme update, a new plugin or a redesign, and being told afterwards means finding them the slow way.

We do not publish a price for this piece of work on its own, because the right scope depends on what already exists. What is published is the bundle pricing: 2,400, 3,600 or 4,800 dollars a month depending on which channels are running. You can read the full breakdown on the pricing page, and you will get an exact number in writing before anything starts.

Find out what is actually blocking the site.

We will crawl your site and read your index coverage before the call, so the conversation starts with what is genuinely broken rather than a generic checklist.

Questions

Straight answers.

How do I know if I have a technical SEO problem?

Open Search Console and look at the page indexing report. If a meaningful share of your pages are excluded, or important pages are listed as crawled but not indexed, you have one.

The other common tell is publishing good content for months with nothing moving at all, which often means the content is not being stored rather than not being good.

Is technical SEO a one time job or ongoing?

Mostly one time, followed by light monitoring. The cleanup on an established site is real work over several weeks. After that, the ongoing requirement is watching index coverage and catching new problems after site changes.

We would rather tell you the heavy lifting is finished than keep billing for a monthly technical retainer that has nothing left to do.

Does site speed actually affect rankings?

It is one input among many, and it is a much larger factor in whether people stay and convert. Google publishes the Core Web Vitals thresholds and reports them to you from real visits.

Treat speed as a conversion investment that also helps search, rather than as a ranking lever on its own.

Do I need schema markup?

It is worth having where it genuinely describes the page, because it removes ambiguity for search engines and for the systems assembling AI answers.

It is not a ranking factor, and FAQ markup no longer produces the rich result most people buy it for, since Google restricted that feature in 2023 to authoritative government and health sites.

Will fixing this break my site?

Structural changes carry risk, which is why we work on staging where one exists, take a backup before changes to live, and make redirects explicit rather than implicit.

The riskiest change is consolidation, because it removes pages. Done with redirects it is safe. Done without them it loses rankings, which is exactly why the redirect map is written before anything is deleted.

Sources

Where this comes from.

Primary documentation and published research behind the guidance on this page.

Next step

Talk to the team

A short call, a look at how the business currently shows up, and a straight answer on what we would do first.