Technical SEO: making a site a search engine can actually read.
Technical SEO is the engineering that determines whether a search engine can crawl, render and understand a site at all: how pages are served, what metadata each carries, how they link to one another, and what structured data describes them. It is separate from writing content and from acquiring links.
It is also the part that is verifiable. Whether a page renders for a crawler is a fact you can check, unlike a ranking, which is a prediction about someone else's algorithm.
- Dynamic Page Rendering
- Structured SEO Metadata
- Canonical & Host Resolution
- Internal Link Graph
- Crawl Directives
The foundation is largely one-off. Revisiting it matters at migrations and new templates, where regressions appear.
The problems that make everything else pointless
Content and campaigns both assume the page can be read in the first place. These are the faults that quietly break that assumption.
The served HTML is empty
If a page is assembled in the browser, a crawler that does not run JavaScript sees a container and a title. Search engines render eventually; most AI and answer-engine crawlers do not render at all.
Two hosts serving the same site
When both the apex domain and www answer with identical content and no canonical, a site competes with itself for every page it has.
No sitemap, no robots directives
Without them a crawler has to discover everything by following links, and has no statement of what it is allowed to do. Both are trivial to produce and commonly missing.
Navigation that is not links
Buttons that scroll or route in JavaScript carry no href. There is nothing for a crawler to follow and no anchor text describing the destination.
Content hidden behind interaction
Detail that only renders after a click — in a modal, a tab or an accordion mounted on demand — is not in the document and cannot be indexed.
Structured data that does not match the page
Markup describing content a visitor cannot see is the fastest route to having rich results suppressed. It has to reflect what is actually rendered.
How the work runs
In this order, because each step is wasted if the one before it has not happened.
- 01
Look at what a crawler receives
Not what the page looks like in a browser. What comes back in the HTTP response, with JavaScript disabled, is the thing being indexed.
- 02
Fix how pages are served
Server rendering or build-time prerendering so the content is in the document. This is usually the single change that makes the rest of the work meaningful.
- 03
Settle identity and duplication
One canonical host, one canonical URL per page, redirects for the alternatives, and a generated sitemap that stays correct as routes are added.
- 04
Make the internal link graph real
Navigation as anchors with descriptive text, a hub-and-spoke structure, and breadcrumbs — so crawl depth is shallow and every page has something pointing at it.
- 05
Describe pages with structured data
Organisation, page, breadcrumb and FAQ markup generated from the same source as the visible content, so the two cannot drift apart.
- 06
Verify rather than report
Each item checked against the built output: does the page render for a crawler, does the canonical resolve, does the markup validate, is every FAQ answer actually on the page.
What you actually receive
Every item on this list is a state you can verify yourself — with curl, with JavaScript disabled, or in a structured data validator. None of it requires taking our word for it.
- Pages that render fully in the served HTML, verified with JavaScript disabled
- One canonical host, with redirects from the alternatives
- A per-page canonical URL and a generated sitemap that updates with the routes
- robots.txt with an explicit position on search and answer-engine crawlers
- Real anchors in navigation, with descriptive text and a hub-and-spoke structure
- Validated structured data generated from the same source as the visible content
- A branded error page wired to the server, returning a real 404 status
Generated, not hand-kept
Sitemaps and structured data are built from the same source as the pages, so they cannot fall out of step as routes change.
Links, not handlers
Navigation is anchors with real hrefs and descriptive text, which is what a crawler follows and what carries meaning.
Frequently asked questions
What is technical SEO?
Technical SEO is the engineering that determines whether a search engine can crawl, render and understand a site at all: how pages are served, what metadata each carries, how they link to one another and what structured data describes them. It is separate from writing content and from acquiring links.
Why might a search engine not be able to read our site?
The most common reason is that the page is assembled in the browser. If the served HTML is an empty container and the content only appears after JavaScript runs, crawlers that do not execute scripts — including most AI and answer-engine crawlers — see nothing but the title.
What is structured data and do we need it?
Structured data is machine-readable markup describing what a page is about — an organisation, a service, a set of questions and answers. It does not change what a visitor sees. It makes the page legible to search and answer engines, and it has to match the visible content or it can be ignored or penalised.
How long before technical SEO shows results?
Crawling and indexing happen over weeks, not days, and ranking movement depends on competition we do not control. What is immediate and verifiable is the technical state: whether pages render for a crawler, whether the sitemap is correct, whether canonicals resolve, whether the structured data validates.
Is technical SEO a one-off fix or ongoing work?
The foundation is largely one-off — rendering, canonicals, sitemap, structured data, internal linking. It stays correct until the site changes. New sections, new templates and migrations are where regressions appear, which is why it is worth revisiting rather than declaring finished.
Do you also write content or build links?
Content structure yes; content writing and link acquisition are outside this service. We will tell you what a page needs to answer and how it should be organised, but we are engineers rather than a content agency or a link broker.
Let us look at what your site returns
Twenty minutes, with an engineer rather than a salesperson. Send us the URL and we will tell you what a crawler currently receives — and whether the problem is technical at all, since sometimes it is not.