Technical SEO: a no-fluff guide to what actually moves rankings

TL;DR

• Technical SEO is one job: make it easy for Google to crawl, understand and trust your pages. That’s it.
• Fix things in order. Crawling and indexing first, then speed and mobile, then canonicals and schema. Most guides start at the wrong end.
• The first knob to turn is almost never Core Web Vitals. It’s checking Google can actually reach and index the pages that matter.
• A technical SEO audit is a triage, not a 200-point checklist. Find what’s blocking money pages, fix that, ignore the rest for now.
• Boring, consistent hygiene beats one heroic fix. That’s the part nobody wants to hear.

To be honest, technical SEO gets treated like dark magic, and it really isn’t. Strip away the jargon and it’s one plain idea: can Google find your pages, read them, and decide they’re worth showing? Everything under the “technical SEO” banner is just a way of answering that question. This post is the order I’d actually work in, and why most advice on this gets the sequence backwards.

I’ve built and run sites for over 20 years, including growing the CoLaz clinic group from 1 location to 9 using SEO and websites alone. A lot of what I learned there was technical, and a lot of it was unglamorous. So this is a do-this-not-that guide, not a theory lecture.

What is technical SEO, really?

Technical SEO is the work that helps search engines crawl, index and render your site, so your content has a fair chance to rank. It’s the plumbing, not the paint.

Google’s own how search works breakdown splits the job into three stages: crawling (finding your pages), indexing (understanding and storing them), and serving (deciding which ones to show). Technical SEO is everything that keeps those three stages running smoothly. If content SEO is what you say, technical SEO is whether Google can hear you say it.

Here’s the useful mental model. Content and links decide how high you could rank. Technical SEO decides whether you’re allowed into the race at all. A brilliant page that Google can’t crawl scores zero.

Why does most technical SEO advice get the order backwards?

Most guides open with Core Web Vitals and page speed, and that’s the wrong place to start. Speed only matters once Google can reach and index the page in the first place.

The reason for the bad order is simple: speed is easy to measure and looks impressive on a report. A red-to-green speed score feels like progress. Meanwhile the page that’s quietly blocked by a stray noindex tag never gets checked, because nobody thought to look.

So the honest priority order is: crawling and indexing, then mobile and speed, then canonicals and structured data, then the long tail of nice-to-haves. Work top down. Don’t polish a page Google can’t see.

Can Google even crawl and index your pages?

Start here, always. Before anything else, confirm that Google can reach your important pages and is allowed to index them. This is the single highest-impact check in all of technical SEO.

Google’s technical requirements are blunt about what a page needs: Googlebot must not be blocked, the page must return an HTTP 200 success code, and it must have content Google can index. Miss any of those and the page is invisible, no matter how good it is.

Here’s what I’d actually check first, in this order:

1. robots.txt. Make sure you’re not accidentally disallowing pages or whole folders you want ranked. One careless line can hide a section.
2. noindex tags. A noindex rule tells Google to keep a page out of results. These get left in after a site launch more often than you’d believe. I’ve found them on the money pages of a “finished” site.
3. HTTP status codes. Key pages should return 200, not a soft 404 or a broken redirect chain.
4. Your sitemap. Build and submit an XML sitemap that lists only real, canonical, indexable URLs. Don’t list pages you block in robots.txt; that’s a common own goal.

If you do nothing else from this post, do this. A page that can’t be crawled or indexed can’t rank, and no amount of speed tuning changes that.

How do you run a technical SEO audit without drowning in it?

Treat a technical SEO audit as triage, not a full-body scan. Start from your pages that produce enquiries and work outward, fixing only what blocks or slows those pages.

Most technical SEO audits fail because they produce a 200-item spreadsheet and no priorities. The owner reads it, feels overwhelmed, and does nothing. A useful audit answers three questions instead: what’s blocking my important pages, what’s slowing them, and what’s confusing Google about them.

Here’s the sequence I use for technical SEO auditing on a service business site:

• Coverage. Are the pages that matter indexed? Google Search Console’s page indexing report tells you plainly. Chase anything important that’s excluded.
• Speed and mobile. Run your key templates through a speed tool and check they hold up on a real phone, not just a fast laptop.
• Canonicals and duplicates. Is each piece of content reachable at one clear URL, or five?
• Structured data. Is your schema valid and present on the pages that deserve rich results?

Notice what’s missing: minor warnings, cosmetic issues, and 90% of what automated tools flag red. Those can wait. Technical SEO audits earn their keep by finding the two or three things actually costing you visibility, not by counting every hairline crack.

If auditing your own site sounds like a weekend you’d rather not lose, that’s the kind of diagnostic I run as part of SEO consulting. Same checks, done by hand.

Do Core Web Vitals actually matter?

Yes, but less than the reports suggest, and only after the crawling and indexing basics are sound. Core Web Vitals are a real but lightweight ranking signal, not a magic switch.

The three Web Vitals have clear targets. Largest Contentful Paint (how fast the main content loads) should be under 2.5 seconds. Interaction to Next Paint (how quickly the page responds to a tap) should be under 200 milliseconds. Cumulative Layout Shift (how much the page jumps around) should be under 0.1.

One detail most people miss: Google judges these at the 75th percentile of your real visitors. So a fast test on your machine means nothing if a quarter of your visitors are on a mid-range phone and a patchy signal. Test how your actual audience loads the site.

Google is clear that good Core Web Vitals help with Search and reward the user experience their systems already aim for. Just don’t expect a green score to rescue thin content or a page Google can’t index. Speed is a tie-breaker, not a trump card. If your site is genuinely slow, a static-first stack fixes most of this at the source, which is why I build website builds that way.

What about canonicals and duplicate content?

Point every duplicate version of a page at one preferred URL using a canonical tag, so Google consolidates the signals instead of splitting them. This is quiet, high-value technical SEO that almost nobody checks.

Canonicalization is just Google picking one representative URL when the same content sits at several addresses. Think of a product reachable at both a “www” and non-”www” address, or with tracking parameters tacked on. Left alone, Google guesses, and it sometimes guesses wrong.

A canonical tag is a hint, not a command, so Google can still overrule you. To make your preference stick, be consistent: link internally to the canonical version, redirect old URLs to it, and include only canonical URLs in your sitemap. When those signals agree, Google usually follows.

Does your site need to work on mobile first?

Yes. Google predominantly uses the mobile version of your pages for indexing and ranking, so the mobile version is the one that counts. Mobile-first indexing is not optional any more.

The trap here is content parity. If your mobile site strips out text, headings, structured data or images that appear on desktop, Google may never see the missing parts, because it’s reading the mobile version. Whatever you want ranked has to be present on the phone, not just the widescreen.

This one caught plenty of businesses out during the “responsive redesign” era. A prettier mobile layout that hid half the content quietly cost them rankings. If you’ve redesigned recently, check that your mobile pages still carry the full content and the same schema as before.

Where JavaScript quietly breaks technical SEO

JavaScript is where a lot of modern sites lose rankings without anyone noticing. Google can render JavaScript, but it’s a second, slower pass, and things fall through the gaps.

Google’s JavaScript SEO guidance is worth reading if your site is built on a framework. The common failure is content or links that only appear after a script runs. If the important stuff isn’t in the initial HTML, Google might crawl the page, see a near-empty shell, and move on before the content loads.

The fix isn’t to ban JavaScript. It’s to make sure your core content, internal links and metadata are present without needing a script to build them. Static-first rendering sidesteps the whole problem, which is one reason I don’t build service-business sites as heavy single-page apps.

The boring stuff that compounds

The single biggest technical SEO lesson from CoLaz wasn’t a clever trick. It was consistency across nine locations: one clean organisation schema, the same business name, address and phone number everywhere, and clean URLs that didn’t change on a whim.

None of that is exciting. But every new clinic inherited the same trust signals instead of starting from zero, and Google treated the group as one coherent, credible business. Boring hygiene, repeated, was the moat.

The flip side is the most expensive mistake I see: a redesign without a migration plan. Owners rebuild on a shiny new platform, lose old URLs, drop redirects, strip out schema, and wonder why traffic tanked. In most cases it’s recoverable by restoring redirects, content density and schema, but it’s a painful, avoidable own goal. New is not automatically better. Continuity is badly undervalued.

One more small thing that pays for itself: use HTTPS. Google confirmed years ago that HTTPS is a ranking signal, and it protects your visitors either way. It’s a lightweight factor, but there’s no reason to run a business site on plain HTTP in 2026.

So which knob do you turn first?

If you take one thing from this, take the order. Confirm Google can crawl and index your key pages. Then check mobile and speed. Then sort out canonicals, schema and HTTPS. Then, and only then, worry about the long tail of minor warnings.

The businesses that win at technical SEO aren’t the ones chasing every algorithm rumour. They’re the ones who keep the plumbing sound quarter after quarter, which is exactly what ongoing website maintenance is for. The fundamentals have barely changed in fifteen years: a crawlable site, content that answers the question, trust signals, and a fast mobile experience.

So if you want a second pair of eyes on your own site, drop the URL into the free audit and I’ll run these same checks against it. No call needed to get started, and let me know what’s going on.