Brilliant content on a broken website does not rank. Technical SEO is the floor everything else stands on, and without it the strategy, the positioning and all the careful audience work fall straight through it into noise.
Technical SEO makes a site legible to algorithms. The job is making sure search engines can find the site, understand it, remember it, and trust what they found there. It maps onto the Trust Signal pillar of the Trust Algorithm, which is the part of your claim a machine can check without having to ask anybody.
Done well, none of it is visible. Your audience never notices a canonical tag. They notice that the thing works, that it loads before they lose interest, and that it feels like it belongs to a real business.
I spent years running printing machines, and technical SEO reminds me of that room more than anything else in marketing does. Most digital printers at the time sprayed silicone over the toner to seal it, and silicone does not bond with laminate, so a laminated book cover with a crease down the spine would pop and peel and look like amateur hour. We bought a Canon that did not use the spray. Not one customer ever knew that. They knew the cover did not peel. Technical SEO is the same category of decision, invisible and unglamorous, and it decides whether the promise on the front survives contact with a reader.
Crawlability: Can Google Even Find You
Crawlability is the first frontier, and when Google cannot crawl a site nothing else on this page matters, because the most authoritative writing in your industry is invisible if the crawler cannot reach it.
A few things kill it. Navigation that hides pages from the main menu. Sitemaps that are missing, stale, or describe a site structure that no longer exists. Robots.txt files blocking critical paths, usually by accident or by somebody being over-protective years ago. Internal linking so thin that pages sit isolated, with no path to them from anywhere a crawler starts.
Think of the site as a building. Crawlability is whether the bot can walk through the doors and hallways into every room. Blocked exits, sealed wings, and a map that does not show where the rooms are: the bot either leaves or works through it slowly and incompletely, and you never see which happened.
Most crawlability problems are inherited rather than created. A site built on old technology. A platform generating bloated code nobody has looked at. A ten-year-old site that has quietly accumulated broken links, redirect chains and security rules that now turn bots away at the door.
The fix is methodical. Audit your own site with a crawler like Screaming Frog and cross-check what it finds against Google Search Console. Read robots.txt and confirm it is not blocking things you want crawled. Fix your navigation so every page that matters is reachable. Build a proper XML sitemap and submit it. Improve your internal linking until the site is a web rather than a pile of separate documents.
This is Opportunity work. You are making the site findable and taking the barriers out from between the algorithm and the writing.
Indexation: Is Google Remembering You
Crawling and indexing are related and not the same. Google can crawl a page and decline to index it, which means the bot found it, read it, and decided it was not worth keeping.
Indexation failures come from a short list. Duplicate or near-duplicate content, which teaches the algorithm to de-prioritise all the copies. Thin pages with almost nothing on them. Noindex tags set during development and never removed, which is more common than anybody admits. Canonicalisation problems, where the same content sits on several URLs and nothing tells Google which one is the real version.
Crawl budget sits underneath all of it. Google gives a site a certain amount of crawling attention, so a slow site, or one spending that attention on pages that should never have been indexed, gets less of its important work looked at.
The solutions are methodical too. Audit your site for duplication and use canonical tags to name the primary version. Review your thin pages and either improve them, merge them, or remove them. Hunt down the noindex tags that should not be there. Improve page speed so crawling you is cheap. Re-read your sitemap and robots.txt to confirm nothing is being blocked or confused by accident.
Indexation is Opportunity work as well. You are making sure that what Google finds, Google keeps.
Core Web Vitals: Does the Site Feel Fast
Core Web Vitals are three metrics Google uses to measure real-world experience. They are not perfect measures of anything, and they are the ones Google published, which makes them your problem regardless.
Largest Contentful Paint measures how quickly the main content appears, and Google's published target is under two and a half seconds. A page taking six seconds fails. The fix is usually image handling, lazy loading, cutting JavaScript, or better hosting, and it is rarely a mystery. Every slow site I have worked on already knew exactly why it was slow, and had simply put the fix behind something else.
Interaction to Next Paint measures responsiveness: somebody clicks or types, and how long before the page does anything about it. Google's target is under two hundred milliseconds. This is usually a JavaScript problem, solved by deferring non-critical scripts and taking work off the main thread. Heavy ad code kills it. Unoptimised third-party tags kill it.
Cumulative Layout Shift measures visual stability, which is whether things jump around while the page finishes loading, and the target is under 0.1. It happens when space is not reserved for images or ads, or when resources arrive after the page has already drawn itself. A detail metric, and the detail Google chose to measure.
Core Web Vitals are Authority signals. A fast site says somebody invested in the experience, and a slow site says the opposite while the visitor sits and waits for it.
Improving them costs money. Faster hosting, front-end rebuilds, cutting the third-party services that drag everything down. The work is measurable, at least, and Google Search Console hands you the field data for nothing.
Schema Markup: Teaching Google What the Site Is
Schema markup is structured data. It tells Google what the content is, who wrote it, when it was published and what it claims. It does not rank a site by itself. It makes your Authority claims legible to a machine.
Organisation schema describes the company: who you are, what you do, where you are, how to reach you. Author schema names who wrote each piece. Article schema carries the title, the date and the author. FAQ schema structures questions so they can be displayed in the results in their own format.
Schema is Trust Signal work rather than algorithm trickery. Marking it up correctly says here is the claim, here are the facts behind it, and here is a form in which you can check them yourself.
Plenty of sites skip it, treating it as optional, which throws away a signal that costs almost nothing. Structured data says somebody has taken the site seriously enough to describe it properly, and it makes content more likely to turn up in featured snippets, knowledge panels and the other rich results.
The work is straightforward. Audit your site and decide what should be marked up, which for most sites means organisation, author and article schema at minimum. I would rather see three types marked up properly than twelve marked up badly. Add the JSON-LD. Test it with Google's Rich Results Test. Then watch Search Console for structured data errors, because they appear quietly.
Site Architecture: Signalling What's Important
How a site is organised signals what matters, and the signal goes to your audience and the algorithm at the same time.
Topical architecture groups related content together. Ten articles about email marketing should sit in one section, linked to each other, close together in the structure, because that arrangement says there is depth here rather than one article that happened to mention the subject.
Pillar and cluster is the formal version of the same idea. The pillar covers a broad topic at a high level, the clusters go deep on specific parts of it, the clusters link back to the pillar, and the pillar links out to all of them. The structure itself says here is a topic we know well, here are the angles, here is how they connect.
Breadcrumbs show hierarchy. The path from the homepage to the page you are on becomes visible, and they hand the crawler a set of internal links that describe the structure at the same time.
Site architecture is Authority work. A well-organised site with obvious topical groupings demonstrates knowledge, and a chaotic one demonstrates something else, which readers feel long before they can explain it.
The work starts with an audit of what you already have and what it covers. Map that onto a structure that makes sense. Create pillar pages as entry points into each of your major areas. Build the clusters around them. Then use internal linking to make the relationships explicit rather than implied.
HTTPS and Security: Trust Signals
HTTPS is basic hygiene, and a site still running on HTTP is sending a signal in the wrong direction before anybody reads a word of it.
An HTTP site triggers a "Not Secure" warning in the browser, and the warning exists for a good reason, because an unencrypted connection can be read by anybody on the network. For anything taking payments that is a disaster. For a content site it is a smaller problem, and it is still a message.
Google announced HTTPS as a ranking signal years ago, and the more useful point is that it is an Authority signal. A secure site says somebody paid for the certificate, configured it properly, and checked that it worked.
The fix is simple. Get a certificate, and most hosting providers now hand you one free through Let's Encrypt. Configure the site for HTTPS. Redirect the HTTP versions so old links and bookmarks survive. Update internal links, sitemaps and robots.txt to match.
One of the easiest Authority wins available. Do it this week.
Mobile-First Indexing: Google's Default
Google indexes the mobile version of a site first, which means a broken mobile experience is not a mobile problem, it is the whole problem, and how the desktop version looks stops being relevant.
For most sites the majority of visits already arrive on a phone. I check my own ad accounts on a phone at the weekend, and so does most of the market you are selling to. Many of those sites still treat mobile as an afterthought, building for a desktop, applying a quick responsive pass, and then wondering why the rankings drift.
Mobile-first indexing means that layout faults, slowness, and anything that behaves badly on a small screen become ranking faults, because the crawler is primarily reading the mobile version and making its decisions from that.
The work here is structural more than technical. Test on real devices rather than a resized browser window on your desk. Confirm your text is readable, your navigation works with a thumb, your images are sized for the screen, and your Core Web Vitals hold up on a phone connection rather than office wifi.
Modern responsive frameworks need very little of this. Older or neglected sites can need a rebuild, and it is better to find that out now.
Technical SEO Through the Opportunity and Authority Lens
Technical SEO splits cleanly along the framework that structures everything else here.
Crawlability and indexation are Opportunity work. You are making the content findable, taking the barriers out from between the algorithm and the pages, and making sure search engines can reach the site, read it and keep it. Skip this and the algorithm never gets the chance to judge the writing, because it is stuck at the door.
Core Web Vitals, schema, architecture and security are Authority work. You are making the content trustworthy and signalling competence and care. A fast site with clean markup and a sensible structure sends a different message from a slow one full of technical debt, and both the algorithm and the reader receive that message whether or not anybody intended to send it.
Technical failures are invisible Authority failures. Nobody reads your robots.txt or inspects your canonical setup, and nobody needs to, because they feel it. Fast or slow. Working or not. Trustworthy or slightly dodgy, without ever being able to say why.
Two illustrations, and I am constructing both rather than naming clients. Picture a manufacturer selling to engineers and procurement teams, who compare hardware specifications line by line: when the product schema is missing, the datasheet PDFs are not crawled, and the pages crawl on a regional connection, the buyer goes back to the results page. Now picture a borrower checking rates on a phone during a lunch break, on a patchy connection, with the layout jumping as an ad loads late. That tab closes, and no amount of good writing further down the page ever gets read.
Expertise in Technical SEO
Three people worth studying for deeper technical work.
Dawn Anderson works in information retrieval, which is the science underneath how search engines function at all. She brings theoretical depth to a field that often runs on folklore, she cares about the principles rather than the tactics, and she has published extensively on crawl budget, JavaScript rendering and structured data.
John Mueller works at Google as a Search Advocate, and he is one of the few people there who talks publicly about how search behaves. His feed is full of practical guidance, and the part worth copying is how carefully he handles ambiguity, because he does not pretend to know more than he knows.
Bill Slawski read Google's patents and wrote about what he found, with no insider knowledge and enough technical depth to work out what a filing actually described. He died in 2022, and the discipline he modelled still holds: a patent shows what a company could build, not proof of what is running.
Study all three.
Next Steps
Technical SEO never really finishes. The foundations get built, then maintained. Core Web Vitals get watched. Crawl errors get cleared. Schema gets reviewed when the site changes. Architecture gets kept clean while people add pages to it.
Done well, everything downstream gets easier, and Opportunity and Authority both depend on it, because neither one works on a broken foundation.
Explore how Opportunity and Authority work together, how to build a Content Strategy that sits on top of solid technical ground, and how the Trust Algorithm reads signals like these to make sense of a site.
The Diagnostic helps you find technical problems before they turn into ranking problems.
Marketing Curious: Working the Noise carries the long version. This page is a rendering. The seed is the source. The book is the story of building it.
Part of the Marketing Universe. Explore Traffic Plus Offer : The Trust Algorithm : 4-Quadrant AI.