Crawl and index audit
A full crawl compared against Search Console coverage, with a short list of pages that are blocked, duplicated, orphaned or wrongly canonicalised.
Crawlability, indexation, Core Web Vitals and structured data — fixed in priority order, not dumped in a 200-row spreadsheet.
Most sites do not have a content problem first. They have a crawl, render or indexation problem that makes every new page slower to earn its place. We start by finding out what search engines can actually see, then fix the issues that change how the site is understood.
Our technical work is deliberately unglamorous: server response, template weight, duplicate parameters, internal link depth, schema coverage and the difference between what the CMS publishes and what the rendered page contains. Each item is scoped by likely impact and effort, so your developer knows what to do this sprint and what can wait.
We start with a short discovery call and a read-only review of the site, analytics and search accounts. The first deliverable is a written scope: what we found, what we would fix first, what it costs and what we need from your team. No work starts until that scope is agreed.
Delivery runs in two-week batches. Each batch has a small number of defined outputs, a named owner on our side and a review point with yours. That keeps the work visible and makes it easy to stop or change direction if the evidence points somewhere else.
If something is outside our remit — a complex platform migration, a paid-media programme or a regulated financial promotion — we will say so and help you brief the right specialist rather than stretching the scope.
We do not measure success by a single keyword position. A ranking that never produces a qualified enquiry is not a win.
Scope is agreed in writing before work starts. These are the standard components; the mix and depth are set by the audit.
A full crawl compared against Search Console coverage, with a short list of pages that are blocked, duplicated, orphaned or wrongly canonicalised.
Field and lab data separated, then template-level fixes for LCP, CLS and INP — ordered by the templates that carry the most commercial pages.
Organisation, ProfessionalService, Service, FAQPage and BreadcrumbList markup, validated against the live rendered page rather than a staging copy.
A simple hub-and-spoke model so service, industry and location pages are reachable within a few clicks of the homepage.
Redirect mapping, pre-launch crawl comparisons and post-launch monitoring when you replatform or change URL structures.
Plain-English acceptance criteria, example URLs and priority labels your in-house or agency developer can pick up without a call.
The same discipline applies across sectors, but the priorities change. These are the industries we build for.
If your question is not here, ask it directly. We would rather answer it before you instruct us.
Usually yes for the highest-impact fixes. We write the ticket, provide acceptance criteria and stay available for questions, but we do not ask you to hand over CMS or server access unless you prefer us to make the changes directly.
A focused audit of a 50–300 page site typically takes five to ten working days. Larger or multi-domain estates take longer, and we will give you a fixed scope before starting.
Either model works. Most clients prefer us to produce the prioritised plan and let their developer implement, with a review pass from us afterwards. For smaller sites we can implement directly in the CMS.
No. Lighthouse is a lab snapshot of one template. It does not tell you whether pages are indexed, whether canonicals conflict, or whether the content is useful. We use it as one input, not the finish line.
Tell us what you are trying to improve and what you have already tried. We will reply with a view on fit, priority and the first useful move.