Technical SEO,done by an engineer

Technical SEO is diagnosis, not a checklist

Technical SEO has a bad reputation because most of it is delivered as a tool export: two hundred findings, colour-coded, sorted by a severity score the tool invented. That document tells you what is unusual about your site. It does not tell you what is costing you money.

The job is diagnosis. Which of these issues is actually suppressing performance, in what order, and what is the cheapest fix that removes it. Usually two or three things matter and the rest is noise.

Start where the truth is

I crawl the site the way a search engine would, then compare that to what has actually been indexed, then look at server logs where I can get them. The interesting information is in the gap between those three.

Pages you think exist that were never crawled. Pages crawled repeatedly that generate nothing. Parameter combinations creating thousands of near-identical URLs. Sections behind a redirect chain long enough that crawlers give up. None of that shows in a page-by-page audit, and all of it is expensive.

What I actually look at

Crawl efficiency

Every site has a finite share of crawler attention. Sites waste it on faceted navigation generating combinatorial URLs, on paginated archives with no value, on internal redirect chains, and on pages that return 200 for content that does not exist. Reclaiming that budget is often the single fastest improvement available, because it costs nothing to serve fewer useless URLs.

Indexation gaps

Being crawled and being indexed are different things. Pages get excluded for duplicate content, thin content, canonical conflicts, or because a template emits a directive nobody meant to ship. I work through the exclusion reasons in the search console, in volume, and trace each cluster to the template that caused it. Fixing one template usually fixes hundreds of pages.

Rendering

If content depends on client-side JavaScript, you are relying on a rendering step that is slower and less reliable than the initial fetch. Sometimes that is fine. Often the important content, the internal links, or the structured data never make it in. I check what a crawler sees, not what a browser shows.

Core Web Vitals, at the cause

Most Core Web Vitals advice is a list of symptoms. The causes are usually a handful: render-blocking resources in the head, images without dimensions, fonts loading without a fallback, third-party scripts injected before anything useful, and layout shifted by late-arriving content. Fixing the cause fixes several metrics at once.

I also care about the difference between lab and field data. A perfect lab score with poor field data means real users on real connections are having a worse time than your testing suggests, and the field number is the one that counts.

Structured data as a graph

Covered in more depth in the generative engine work, but it belongs here too: schema should describe an entity, with stable identifiers and explicit relationships, not decorate a page with unconnected blocks.

Internal linking as architecture

Internal links are how importance is distributed and how deep pages get discovered. Sites that publish steadily without ever revisiting architecture end up with orphaned pages, flat hierarchies where nothing signals priority, and navigation that links to everything equally, which signals nothing.

Findings are not the deliverable

The deliverable is a fixed site. I work in the repository, ship the changes, and verify them afterwards. Where a fix belongs with your development team, I write it as a specific ticket with the reason, the change and the acceptance criteria, so it does not sit in a backlog waiting for someone to interpret it.

Then I verify. Recrawl, recheck indexation, recheck field data. A fix that was not verified is a claim.