Technical SEO.
Give useful pages a stronger foundation.

Diagnose before changing the website

An audit combines a crawl, available search data and a review of representative templates. The aim is to identify causes, affected pages and realistic fixes rather than produce a long list of tool warnings.

Access to Search Console, your CMS and relevant deployment history helps distinguish persistent issues from temporary symptoms. Access should be granted through individual invitations, never by sharing passwords in the enquiry form.

Most audit findings do not deserve a developer sprint

A crawler will return hundreds of findings on almost any site, and a report listing all of them is easy to produce and close to useless. Missing alt text, a handful of long titles and a redirect chain three hops deep are all real, and none of them is why the traffic fell.

The work worth paying for is the triage: separating what is costing you discovery from what is merely untidy, and being able to say why. That means ranking each finding by how many pages it touches, whether those pages matter commercially, and what it would cost to fix. Twelve prioritised items with owners attached are worth more than four hundred rows, and are considerably more likely to be implemented. If the harder question is what to do with the shortlist once you have it, that is an advisory conversation rather than an audit.

Give developers actionable work

Each recommendation needs a clear problem statement, affected examples, priority and a way to verify the change. We separate work that affects discovery from housekeeping and longer-term improvements.

Before migration or large template changes, we agree the redirect approach, URL checks and post-release monitoring. Your development team retains control of production releases.

Migrations are where this work earns its keep

Replatforming, redesigning or restructuring URLs is the one moment when technical SEO either protects a business or fails to. The damage is rarely caused by the new site being worse. It is caused by redirects mapped from a spreadsheet nobody checked, pages that quietly did not make the move, or a staging environment left blocking crawlers after launch.

The parts that matter are unglamorous and they happen before release: a complete inventory of what exists now, a mapping of every URL that earns anything to its destination, a check on the staging build, and a monitoring plan for the fortnight afterwards so problems are found by you rather than by a fall in enquiries. Your developers keep control of the release. What we add is the list of things that have to be true before and after it. Where the site is large enough that no one can check the mapping by hand, and the redirects are themselves generated from rules, it becomes a different scale of problem.

Validate the implementation

A task is not complete simply because a recommendation has been sent. Where validation is in scope, we recheck the affected pages, record unresolved constraints and update the issue register after implementation.