SEO technical work explained: what it means and what to fix first

TL;DR

• “SEO technical” is the half of SEO that makes sure Google can find, read and trust your pages. Get it wrong and even the best content stays invisible.
• The four things that matter most, in order: can Google crawl and index the page, does it load fast on a phone, is there one clear version of each URL, and is the meaning marked up with schema.
• Google Search runs in three stages: crawling, indexing, then serving. Technical SEO is about clearing the path through the first two.
• Core Web Vitals have plain targets: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measured across most of your real visitors.
• You do not need to fix everything at once. Fix crawling and indexing first, then speed and mobile, then canonicals and schema.

If you have typed “seo technical” into Google and come away more confused, you are not alone. The phrase gets used to mean everything and nothing. So let me give you the short version first, then the detail.

SEO technical work is the part of search optimisation that makes sure Google can reach your pages, read what is on them, and treat them as trustworthy. It is not about keywords or backlinks. It is the plumbing underneath both.

Get the plumbing wrong and nothing else you do shows up. I have watched owner-operators pour money into content and links while a single broken setting quietly kept half their site out of Google. To be honest, the technical side is usually where the cheapest, fastest wins are hiding.

What does “seo technical” actually mean?

SEO technical work covers everything that helps a search engine crawl, index and render your website, rather than the words or links on it. Think of it as making your site legible to a machine.

Google itself splits search into three stages: crawling (finding your pages), indexing (understanding and storing them), and serving (ranking them for a query). Technical SEO is mostly about the first two. If Google cannot crawl or index a page, ranking never enters the picture.

That is the framing that turns this from confusing to obvious. Every technical task, from a sitemap to page speed, is really answering one question: is anything stopping Google from finding, reading or trusting this page?

Where technical SEO sits next to on-page and off-page

The three parts of SEO split cleanly: technical is about access, on-page is about relevance, and off-page is about reputation. You need all three, but they solve different problems.

• Technical SEO: can Google reach and understand the page at all?
• On-page SEO: does the page clearly answer what the searcher asked?
• Off-page SEO: does the wider web treat the site as credible (mostly links and mentions)?

Most small business sites I audit are not short of content or links. They are short of the boring technical hygiene that lets the content and links count. If you want the wider strategy view, that sits inside general SEO consulting, but the technical layer is where I usually start.

What does an SEO technical audit check?

An SEO technical audit checks six things: crawlability, indexing, site speed, mobile usability, canonical setup, and structured data. Those six cover most of what actually moves rankings on the technical side.

Here is the plain version of the checklist I work through:

You do not need paid tools to start. Google Search Console, which is free, surfaces most crawling and indexing problems straight from the source.

Can Google actually crawl and index your pages?

Yes, but only if three things are true: Googlebot is not blocked, the page returns a healthy 200 status code, and the content is genuinely indexable. Those are Google’s own technical requirements, and they are simpler than they sound.

The trap I see most often is confusing two different controls. A robots.txt file tells crawlers what not to fetch. A noindex tag tells Google not to store a page. Google is clear that robots.txt is the wrong tool for keeping a page out of the index; use noindex for that.

A sitemap is the other half of the job. It is a simple file listing the pages you want found, and it is the cheapest way to help Google discover new or updated content. Most site builders generate one automatically, so the work is usually to check it exists and submit it in Search Console.

How fast does your site need to be?

Fast enough to clear Google’s Core Web Vitals, which come down to three plain targets. The metrics measure loading, responsiveness and visual stability, and Google uses them as a ranking signal.

The thresholds for a good score are:

• Largest Contentful Paint (main content loads): under 2.5 seconds.
• Interaction to Next Paint (response to a tap or click): under 200 milliseconds.
• Cumulative Layout Shift (things jumping around): under 0.1.

One detail matters here. Google grades you at the 75th percentile of real visits, so a quick score on your own fast laptop is not the test. What counts is the experience most of your visitors get, often on a mid-range phone on mobile data. That is the everyday reality for a lot of UK local searches.

Does your site work properly on a phone?

It has to, because Google now uses the mobile version of your site for indexing and ranking. This is called mobile-first indexing, and it has been the default for years.

The practical rule is content parity. Your mobile pages should carry the same text, headings, images and structured data as the desktop version. Owners get caught out when a “mobile-friendly” theme quietly hides half the content on small screens. If Google only reads the mobile version, that hidden content may as well not exist.

Canonicals and schema: consolidating your site’s strength

These two are where sites either consolidate their strength or leak it. Canonicals stop Google splitting credit across duplicate URLs; schema helps Google understand what a page is about.

A canonical URL is simply the version of a page you want Google to treat as the real one. Google picks a canonical using several signals: a redirect is a strong hint, a rel=“canonical” tag is a strong hint, and inclusion in a sitemap is a weaker one. If the same content sits on several URLs (with and without a trailing slash, http and https, tracking parameters tacked on the end), you want one clear winner.

Schema markup, usually written as JSON-LD, labels the parts of a page so Google can read them without guessing: this is an article, this is the author, this is a local business. It can earn you richer search listings, though Google is clear that marking up a page does not guarantee that appearance.

The SEO technical checklist, in the order I fix things

Fix things in the order Google needs them: access first, experience second, meaning third. Chasing schema while Google cannot even crawl the page is effort in the wrong place.

Here is the order I actually use:

1. Crawling and indexing: robots.txt, noindex tags, a working sitemap, 200 status codes.
2. Speed and mobile: Core Web Vitals, a layout that holds up on a phone.
3. Canonicals: one clear URL per piece of content, clean redirects.
4. Schema: Organization, LocalBusiness, Article, and the types that fit your pages.

I learned to trust boring fundamentals the hard way. When I grew the CoLaz group from one clinic to nine between 2016 and 2022, almost none of it came from clever tricks.

It came from sites Google could crawl, pages that loaded fast, and clean structure repeated location by location. The fundamentals barely change, and the sites that keep winning are the ones that keep the plumbing clean.

If some of these terms are new, the order I work in here is the same one I use on new website builds, and it is the reason a fast, well-structured site tends to hold its rankings for years.

Do you need to hire someone to do this?

Not necessarily. A determined owner with a modern site builder and a free Search Console account can clear most of the common technical issues in a weekend.

Where it gets worth paying for help is when the problems are hidden or tangled: a botched migration that dropped its redirects, duplicate pages fighting each other, schema that validates but describes the wrong thing. That is the sort of diagnostic work that also fits under ongoing website maintenance, so the site stays healthy after the first fix.

The technical basics are worth getting right, whoever does them.

If you want to see where your own site stands without committing to anything, book a call and bring the URL. I’ll run the same technical checks I have described here, in plain English.