Make the site easy to crawl, fast to read, hard to ignore.

Everything that decides whether search engines and answer engines can find, fetch, understand and trust your pages: crawl efficiency, indexing and canonical logic, rendering, site speed measured in the field, internal linking and architecture, structured data, status codes and redirects, international targeting, and the monitoring that keeps all of it from regressing. It does not cover writing the pages or earning links — that is organic search work. A useful way to think about the split: technical SEO decides whether your content gets a fair hearing, and content decides whether it wins.

A few signals are close to diagnostic. Large numbers of URLs reported as discovered or crawled but not indexed. New pages taking weeks to appear. Traffic that fell on a date matching a release rather than an algorithm update. Field vitals failing while lab scores look fine. Search results showing the wrong variant of a page, or filter URLs instead of category pages. Any one of those is worth an audit; two or more usually mean the content team is being blamed for an engineering issue. We start with a scoped diagnosis precisely so that question gets answered with data.

It matters, and it is also normal — the 2025 Web Almanac found only 48% of mobile origins passing all three Core Web Vitals, with loading performance the usual culprit. Our view is pragmatic: vitals are one input among many for ranking, but they are a direct input to conversion, and the same fixes serve both. So we do not chase a perfect score. We fix the specific things your field data blames — usually server response time, an oversized hero image and third-party tags — and stop when the curve flattens.

Crawl budget is simply how much fetching a search engine will do on your site, and for most sites under a few thousand URLs it is not the constraint. It becomes decisive when a template generates URLs combinatorially: filters, sort orders, search pages, calendars, session parameters. Google's guidance is direct about the remedy — keep useless filter combinations out of the crawl and consolidate duplicates. If your crawl reports tens of thousands more URLs than you have real pages, you have the problem regardless of company size.

Yes, and it is usually the fastest route. We write tickets in the form your team already uses: the template or file involved, the change, the reason, the expected effect and how we will verify it after deploy. Where you would rather we implement, we work directly in the CMS or the repository with the access you grant. Either way we join the release conversation, because the cheapest technical SEO in existence is a check before launch rather than a diagnosis three months after one.

Yes, and please involve us before launch. Pre-launch we map the URL inventory, specify redirects one-to-one where they exist, flag templates that will lose content or markup, and check the staging build for noindex tags, blocked assets and rendering gaps. At launch we monitor status codes, coverage and vitals daily for the first weeks so anything unexpected is caught while it is still cheap. Migrations done this way are undramatic; the horror stories almost all come from redirect maps written after the fact.

It is a large part of it. Answer engines have to fetch, render and reconcile your content before they can cite it, so crawl access, clean markup, consistent entity data and server-rendered copy all become prerequisites. Search Engine Land's look at 107,352 pages appearing prominently in AI Overviews and AI Mode is a useful reminder that the fundamentals travel. Where you want the visibility side of that addressed too, our GEO and AEO team works from the same technical baseline.

The diagnosis is two to three weeks depending on site size and log access. Remediation is where the timeline varies: contained fixes to canonicals, redirects and robots rules can ship in the same month, while template rewrites and performance work follow your release cadence. Most sites see coverage and crawl behaviour change within weeks of the first fixes, with ranking and traffic effects compounding over a quarter. We report progress against the baseline we measured on day one, so nobody has to take improvement on faith.

Monitoring, because technical debt is a flow rather than a stock. We keep weekly eyes on coverage, field vitals, markup validity, redirect health and crawl distribution, with alerting on the signals that break silently — a robots rule widened during a deploy, a canonical template edited, a script added by a tag manager. Where you would rather own that yourself, we set the alerts up in your tooling and train your team on the baseline, then step back to periodic reviews.

We do, through the same senior team, and many clients buy the whole programme so the technical baseline and the publishing plan are designed together. Our SEO, GEO and AEO and analytics teams share the same measurement, so a fix and its effect land in one report. It is equally fine to buy technical work alone alongside another agency's content programme: we write specs they can read and share the baseline openly.