Technical SEO
Fixing what stops the site working
Crawl budget, indexation, canonicals, rendering, site architecture, Core Web Vitals, log files. Most of it affects whether the site works at all, not just whether Google can read it — a page that renders slowly or inconsistently is a problem for the person on it long before it is a ranking problem.
Prerequisite
Diagnosis first
Nothing gets fixed until it has been established that it is broken and that fixing it is worth the effort. That usually means an audit, or evidence from one you already have.
If you arrive knowing what is wrong — a developer flagged it, a migration broke something, Search Console is reporting it — that counts. What doesn’t work is fixing speculatively. Most technical findings on most sites aren’t worth acting on, and a site that has been optimised against a tool export is usually worse off than one left alone.
Substance
What it covers
Crawl budget
Large sites waste crawl on URLs that shouldn’t exist — filter combinations, session parameters, paginated series that go nowhere. The work is finding what the crawler spends its time on and removing what isn’t worth the request.
Indexation
Two problems in opposite directions: pages that should be indexed and aren’t, and pages that are and shouldn’t be. Thin indexed pages are usually the more damaging of the two.
Canonicals
Whether the site tells search engines which version of a page is the real one, and whether it does so consistently. Conflicting canonical signals are one of the most common faults on e-commerce and multi-location sites.
Rendering
Whether your content exists for a crawler that doesn’t execute your JavaScript. If the page is empty until a script runs, what gets indexed may not be what you see.
Site architecture
How pages connect, how deep the important ones sit, and whether internal linking reflects what actually matters commercially. Most sites grow faster than their structure.
Core Web Vitals
A perfect Lighthouse lab score is vanity. Field data from real users is what Google actually grades you on. CrUX metrics like LCP and INP reflect the network and device friction that lab simulations miss entirely, so that is what to optimise for.
Log files
Crawler emulators show how your site should behave. Raw server logs show what Googlebot is actually doing. Analysing them cuts the guesswork on crawl budget waste, bot traps, and how search engines really prioritise your pages.
Situations
When people usually arrive
After a migration or replatform, when traffic didn’t come back.
After a redesign, when the site looks better and performs worse.
When Search Console starts reporting indexation problems that weren’t there before.
When Core Web Vitals fail in the field despite passing in the lab.
When a site has grown past the architecture it was built on.
Delivery
Who does the work
Depends on the platform and on whether you have a developer.
On WordPress and most common CMSs, I implement directly. On a hard-coded or custom-built site I can implement, but if you have a developer it’s better that they do — they know the codebase and they’ll be maintaining it. In that case you get a specification precise enough to hand over, and I verify the work once it’s live.
Either way, work happens on staging. I don’t make changes to a live site.
Deliverable
What you get
The fixes, implemented and verified — or a written specification precise enough for your developer to act on without further interpretation. Often both, where some items are mine and others belong with your team.
Verification is part of it. A fix that was deployed but didn’t take is not a fix.
Engagement
How it’s scoped
Project-based or ongoing, depending on what the site needs. A migration or a set of discrete faults is a project. A large site carrying recurring technical debt is usually better served by something continuous.
Quoted after the diagnosis, because work can’t be priced before anyone knows what it is.
Related services