Technical SEO Services: The Unglamorous Work Everything Else Sits On
Crawl, indexation, architecture, rendering, Core Web Vitals and schema. Get this wrong and your best content never gets a fair hearing, from Google or from an AI engine.
Found by a search team, fixed by the developers sitting next to them. Delivered from Ho Chi Minh City for brands across the US, UK, Australia and the EU.
THE SERVICE
What technical SEO covers
Technical SEO is the work that determines whether machines can crawl your site, index the right pages, render your content, understand it and trust it. It covers crawlability and crawl budget, indexation, site architecture and internal linking, JavaScript rendering, Core Web Vitals, structured data, duplicate content and canonicalisation, redirects, hreflang for multi-language sites, and, since 2026, whether AI crawlers such as GPTBot and PerplexityBot can read you at all. We audit all of it, prioritise by commercial impact rather than by issue count, and then ship the fixes ourselves, because a document full of problems is not a fix.
You cannot rank a page Google never finished reading
Technical SEO is the part of search nobody puts in a case study headline, because the win is invisible: pages get discovered, understood and indexed instead of quietly ignored. It is also the part that decides whether the content and links you pay for do anything at all.
Most sites we audit are not penalised. They are just hard work to crawl, thin internal linking, duplicate paths, JavaScript that hides the content from the crawler, a sitemap that disagrees with the canonical tags, and a few thousand parameter URLs eating the crawl budget that should be spent on the pages that sell.
We fix the plumbing first because it is the cheapest ranking you will ever buy. Everything after it, keyword research, topical maps, content, compounds on top of a site that is actually legible to a machine.
What we actually check
Crawlability and crawl budget
robots.txt, crawl traps, parameter sprawl, redirect chains, orphan pages, and server logs where we can get them, so we are looking at what bots fetched rather than what we assume they fetched.
Indexation
Index coverage, index bloat, canonical conflicts, sitemap accuracy, and whether all four signals agree with each other.
Site architecture and internal linking
Crawl depth, hub structure, breadcrumbs, anchor text, and whether authority reaches the pages that sell.
Rendering
Whether the content is in the HTML or assembled client-side after the crawler has left, tested against Googlebot and AI user agents separately, because they do not behave the same way.
Core Web Vitals and page speed
LCP, INP and CLS measured on field data rather than a lab score, at the 75th percentile on mobile. Only around half of all websites currently pass all three.
Structured data
Coverage against what the page type should carry, plus validation, so machines can parse your entities rather than infer them.
Duplicate content and canonicalisation
Near-duplicate paths, faceted navigation, pagination and the parameter URLs that quietly split your own signals.
International and multi-language
hreflang, ccTLD versus subfolder decisions, and the return-tag errors that silently undo the whole implementation.
AI CRAWLERS
Technical SEO for AI engines
Googlebot and the AI crawlers are not the same thing and do not behave the same way. GPTBot, PerplexityBot, OAI-SearchBot and ClaudeBot each fetch differently, and several of them will not execute your JavaScript at all. A site that renders perfectly for Google can be effectively blank to the engine that is about to recommend your competitor.
So we test it separately. We fetch your key pages as each AI user agent and check content parity against what a human sees. We look at whether your robots.txt is blocking AI crawlers by accident, or allowing them by accident, which is a decision worth making deliberately rather than inheriting from a template. We check that your structured data actually describes your entities, because schema is increasingly how AI engines decide what to cite. And we look at whether an llms.txt file makes sense for your site.
None of this replaces conventional technical SEO. It sits on top of it, which is the right order: fixing schema on a page Google will not index is polishing a door that opens onto a wall. The visibility work itself continues in AI visibility and GEO.
OUR PROCESS
How we actually do it
In this order, every time.
Crawl the site like a search engine does
A full crawl against server logs where we can get them, so we are looking at what bots actually fetched rather than what we assume they fetched. Status codes, redirect chains, canonical conflicts, orphan pages, parameter sprawl.
Fix indexation before anything else
Decide what should be indexed, then make the signals agree: robots directives, canonicals, sitemaps and internal links all pointing the same way. Contradictory signals are the single most common problem we find.
Make the architecture say what matters
Internal linking is how you tell a search engine which pages are important. We restructure hubs, breadcrumbs and cross-links so authority flows to the pages with commercial intent instead of pooling in the blog.
Structured data and rendering
Schema so machines can parse entities rather than guess them, and a rendering check so the content is in the HTML rather than assembled client-side after the crawler has left. Tested against AI user agents as well as Googlebot, because they render differently.
Then performance, then the polish
Core Web Vitals come after the page can be found and understood, because speeding up a page nobody indexes achieves nothing. Schema refinements and AI legibility tuning come last, on a foundation that is already clean.
What you get
Deliverables, not adjectives.
MIGRATIONS
Migrations and replatforms
A migration is where technical SEO either proves its value or becomes the most expensive lesson a business learns that year. Rankings built over a decade can be lost in an afternoon by a redirect map nobody checked.
The pattern is always the same: a full inventory and redirect map before anyone touches the build, parity testing on staging, and a monitored launch rather than a launch and a hope. If you are planning a replatform, the cheapest moment to involve us is before the design is signed off, not the week before go-live.
See the SEO migration serviceWe have done this repeatedly and without losses.
McLaren Construction Group
Came through a full replatform with zero rankings lost.
Ski.com
Had URL mapping, redirects and structured data handled before launch day rather than after it.
Unmind
Kept its SEO value through a platform change.
Who this works for
Four situations where technical SEO is the right first spend.
You publish good content and it does not rank.
Usually the content is fine and the site is not legible. Cheaper to fix the plumbing than to write more.
You are about to replatform or migrate.
The cheapest possible moment to involve a search team, and the most expensive one to skip.
You have a large site with more URLs than anyone can account for.
Faceted navigation, parameters, pagination, thousands of pages nobody planned. Crawl budget goes to the wrong places.
Google can read you and AI engines cannot.
Increasingly common on JavaScript-heavy builds, and invisible unless someone tests for it specifically.
Most often for e-commerce and marketplaces, SaaS and technology, education, B2B and professional services, and travel, for clients headquartered in the US, UK, Australia, Canada and the EU as well as businesses operating inside Vietnam.
Questions, answered straight
No fluff, as promised.
How is technical SEO different from an SEO audit?
An audit is a document. Technical SEO is the work. We do both, but the value is in the shipping, we are a build team as well as a search team, so recommendations get implemented rather than handed over and forgotten.
How long does technical SEO take to show results?
Indexation problems can resolve within weeks of a fix. Architecture and internal linking changes typically show over one to three months as the crawler re-evaluates the site. It is the fastest-moving part of SEO, which is why we do it first.
Do I need technical SEO if my site is brand new?
Yes, and it is far cheaper then. Building the structure correctly at launch avoids a migration-shaped problem later. We run it alongside every build, see web design and development.
Do you cover Core Web Vitals?
Yes. LCP, INP and CLS, measured on field data at the 75th percentile on mobile rather than on a lab score that flatters the result. Only around half of all websites currently pass all three. We treat performance as a step that comes after crawlability and indexation, because speeding up a page nobody indexes achieves nothing.
Can AI engines like ChatGPT and Perplexity read our site?
It is worth testing rather than assuming. GPTBot, PerplexityBot and similar crawlers render differently from Googlebot and several will not execute JavaScript, so a site that looks perfect to Google can be effectively blank to them. We fetch your key pages as each user agent and check content parity.
Should we block AI crawlers in robots.txt?
That is a commercial decision, not a technical default, and it should be made deliberately rather than inherited from a template. Blocking them protects your content from training use and removes you from the answers your buyers are reading. Most of our clients allow the crawlers that drive citations and block the ones that only take. We will talk you through the trade-off.
Do you analyse server log files?
Yes, where the client can provide them. Logs show which URLs bots actually crawled rather than which ones a sitemap claims exist, which is how you find crawl waste, bot traps and orphan pages that no crawler simulation will surface. It is one of the clearer dividing lines between a senior technical audit and a tool export.
Can you handle a site migration without losing rankings?
We have done it repeatedly. McLaren Construction Group came through a full replatform with zero rankings lost. The method is a complete inventory and redirect map before the build starts, parity testing on staging, and a monitored launch. The cheapest time to involve us is before the design is signed off.
How often should we run a technical audit?
Quarterly for most sites, and after any significant platform, template or navigation change. Running one only after traffic drops means you are diagnosing damage rather than preventing it.
Related services
This never works in isolation.
Proof from real work
All case studies
Something in the way of your best pages?
Tell us what you're working on. You'll get an honest answer about whether we can help, and exactly how.