The plumbing under your homepage: what we audit first.

A technical SEO audit starts with the infrastructure that lets search engines find, read, and trust your site — before anyone looks at keywords or content.

Most professional services firms we work with have already spent money on a website redesign or a content push. Rankings still flatline. The reason is usually not what you published. It is how the site is built. This post walks through the exact order in which we audit the technical layer — the plumbing — and why each item gets checked before the one after it.

Why crawlability comes first

If Google cannot reach your pages, nothing else matters. Crawlability is the gate. Everything downstream — indexation, rankings, traffic — depends on whether Googlebot can get in and move around.

The first thing we check is the robots.txt file. It sits at the root of your domain. One misplaced line in that file can block your entire site from being crawled. We have seen law firms and accountancies whose developers accidentally disallowed everything during a site build and never reverted the change. The site looked fine in a browser. It was invisible to Google.

After robots.txt, we check for crawl traps. These are patterns that generate near-infinite URLs — faceted navigation, session IDs appended to URLs, paginated archives without proper controls. Googlebot follows them, wastes crawl budget, and never reaches your real pages.

We also look at internal linking at this stage. Pages with no inbound internal links are called orphan pages. Googlebot discovers pages by following links. If a page has no links pointing at it, it may never be crawled — even if it is technically accessible.

What the XML sitemap actually tells us

A sitemap is a map of the pages you want indexed, and comparing it against what is actually indexed reveals gaps fast. The sitemap should contain only canonical, indexable URLs — nothing noindexed, nothing redirected, nothing returning a 4xx or 5xx status.

We pull the sitemap and cross-reference it against Google Search Console's coverage report. This comparison shows three things: pages you want indexed that Google has not found, pages Google has found that you did not submit, and pages returning errors that are still listed in your sitemap as if everything is fine.

For most professional services sites, the sitemap is either missing practice area pages entirely or is auto-generated and full of URLs that should not exist — author archives, tag pages, filtered search results. A bloated sitemap dilutes the signal. A sparse one leaves real pages unsubmitted.

This is part of what we cover inside Search Foundations, our baseline audit and implementation track for firms that want to stop guessing and start building on solid ground.

How we read your redirect chains

Redirects are the scar tissue of a website's history. Every domain migration, every URL restructure, every page deletion leaves a trail. The question is whether that trail is clean or tangled.

A single 301 redirect — old URL to new URL — is fine. A chain — old URL to intermediate URL to final URL — is a problem. Each hop in the chain costs crawl budget and passes less link equity than a direct redirect. Three or more hops and you start losing meaningful signal.

We map every redirect chain on the site. We look for loops (URL A redirects to URL B, which redirects back to A). We look for chains that end in a 404. We look for 302 temporary redirects being used where a 301 should be — which tells Google the old URL is still the canonical destination.

For any firm that has changed domains, rebranded, or rebuilt its site in the last five years, the redirect audit almost always finds problems. McShanes Solicitors had exactly this kind of tangled history when we started working with them — legacy URLs from a previous platform still accumulating inbound links, none of which were passing equity to the live site.

What site speed signals about everything else

Page speed is not a UX nice-to-have. It is a ranking factor, a conversion factor, and a signal of how well the site is built overall.

We measure speed using Core Web Vitals — specifically Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). These three numbers reflect real user experience, and Google uses them in ranking. A poor LCP means your main content is loading slowly. High CLS means elements are jumping around as the page loads. Poor INP means the page is unresponsive to input.

For a deeper breakdown of what these numbers mean and how Google weights them, Core Web Vitals: the three numbers that decide if Google bothers is worth reading before you run your first audit.

When a professional services site scores poorly on Core Web Vitals, the cause is almost always one of three things: unoptimised images, render-blocking scripts loaded in the wrong order, or a hosting environment that cannot serve content fast enough. The third cause is the most expensive to fix but also the most common among firms that chose cheap shared hosting years ago and never revisited the decision.

Slow sites also cost money directly — not just through lost rankings. If you want to understand the revenue side of the argument, Why your slow site is a sales problem, not an IT problem makes the case plainly.

Indexation: what Google has actually decided to keep

Crawlability determines whether Google can visit a page. Indexation determines whether Google chooses to keep it in its index. These are different things, and the gap between them is where a lot of rankings disappear.

Google can crawl a page and still decide not to index it. The reasons include: thin content, duplicate content, pages that are too similar to others on the same site, and pages that Google's quality systems assess as low-value.

We use Search Console's URL Inspection tool to check individual pages, and the Coverage report to see patterns across the whole site. The statuses that concern us most are "Discovered — currently not indexed" and "Crawled — currently not indexed." The first means Google found the URL but has not yet visited it. The second means Google visited it and decided not to include it. The second status is worse. It means something about the page itself gave Google pause.

For professional services sites, thin service pages are the most common culprit. A page that says little more than "we offer conveyancing in London — contact us" gives Google almost no signal about depth or relevance. It often gets deprioritised, regardless of how many times it is submitted in the sitemap.

Structured data: what you are telling Google directly

Structured data is markup added to a page's HTML that tells Google explicitly what the content is — not what it appears to be, but what it is. For professional services firms, the most relevant schema types are LocalBusiness (or the specific subtype — LegalService, AccountingService), Person, FAQPage, and BreadcrumbList.

We check structured data with Google's Rich Results Test and schema validators. The common problems are: no structured data at all, structured data that is present but syntactically broken, and structured data that contradicts the visible content on the page.

The last case is the one that causes active harm. If your structured data says your office is open Monday to Friday 9–5 and the page says Monday to Saturday 9–6, Google registers a conflict. Trust erodes.

Well-formed structured data does not guarantee a rich result in search. But it gives Google a cleaner picture of your business, your location, and your people — which matters in local and professional services search, where trust signals are part of how results are ranked.

Where this breaks down

A technical audit is not a ranking guarantee. Fixing crawlability, redirects, speed, indexation, and structured data removes blockers — it does not create rankings from nothing. If a site has no authoritative content and no inbound links, cleaning the technical layer will not manufacture visibility. It clears the path. The site still has to give search engines something worth ranking.

The audit also captures a moment in time. Sites change — developers push code, plugins update, content gets deleted. Technical health drifts. The audit is the start of a process, not a one-time fix.

How we sequence the work

The order matters as much as the checklist. We audit crawlability first because if Google cannot get in, nothing else we find will matter until that is resolved. Redirects come second because broken redirect chains actively misdirect both users and crawlers. Speed third because it affects every page across the whole site. Indexation fourth because it depends on the previous three being stable. Structured data last because it is additive — it builds on a site that is already crawlable, fast, and indexed.

This sequence is not arbitrary. It reflects how Google's own systems work: crawl, assess, rank. We audit in the same direction Google moves through a site.

If you are not sure where your site stands on any of these layers, that is the right place to start — not with keyword research, not with new content, but with the plumbing.