The first technical SEO audit for a new client, in one afternoon

The first audit you run for a new client does more than find problems. It sets the tone for the whole relationship. Get it right and the client learns that you find the things that matter and explain them plainly. Get it wrong and they learn that SEO means a long document they are not expected to understand.

This is the order of work we use. It fits in an afternoon for a typical small-business site of a few hundred pages, and it is built so the most expensive problems surface first.

Before you crawl anything

Spend ten minutes on three questions. They change what you look for.

• Which pages make money? The booking page, the main service pages, the category pages of a shop. Write the URLs down. Everything that follows is ranked against this list.
• What changed recently? A redesign, a new CMS, a domain move or a new developer. Most sudden SEO problems have a date, and that date is usually a launch.
• What access do you have? Google Search Console, analytics and the CMS. Search Console is the one that matters most for an audit, because it is Google telling you what it sees.

If the client cannot get you into Search Console, ask again before you start. An audit without it is a guess about Google's view of the site, when the real view is one invite away.

Hour one: can Google reach the pages that matter?

Nothing further down this list matters if the answer here is no. Start with the pages you wrote down.

Check each one for a noindex directive, either in the page's meta robots tag or in an X-Robots-Tag header. A leftover noindex from a staging site is one of the most common and most damaging things you will ever find, and it is invisible to the client because the page still loads normally. We keep a full write-up on noindex on an important page.

Then check the canonical tag. A service page that declares a different URL as its canonical is asking Google to index something else. Sometimes that is correct. Often it is a template mistake repeated across every page, which is why canonical mismatches deserve a look at the template, not just the URL.

Read the robots.txt file yourself. It is short. Look for rules that block whole folders the site depends on, and for rules that block the CSS and JavaScript Google needs to render the page (blocked resources).

Finally, open the Pages report under Indexing in Search Console. It lists the reasons Google has chosen not to index URLs. You are looking for the money pages in any of those lists, and for large jumps in excluded pages that line up with the "what changed recently" answer.

Hour two: is the journey broken?

Now crawl the site. The crawl is where most tools start, and it is where most audits go wrong, because a crawl finds everything with equal enthusiasm.

Filter it down to the journey. You care about errors on the path a visitor takes to become a customer:

• Pages that return 4xx errors, especially ones that other pages still link to.
• Pages that return 5xx server errors. One is worth mentioning. A pattern is urgent, because it often means the server is struggling under load.
• Broken internal links inside navigation, footers and templates, which repeat across every page.
• Redirect chains and redirect loops, which are common after a migration.

Group everything by template. Two hundred broken links that all come from one footer link are one fix, not two hundred. That grouping is the single biggest difference between an audit a developer can act on and one they quietly ignore.

Check security while you are here. Mixed content, where a secure page loads images or scripts over plain HTTP, makes browsers show warnings and sometimes block parts of the page.

Hour three: speed where visitors actually land

Do not test the homepage and stop. Pull the top landing pages from analytics or Search Console and test those, on mobile.

Use PageSpeed Insights and read the top section first. That section is field data: how the page performed for real Chrome users over the last 28 days. The score further down is lab data from a single simulated load. When they disagree, the field data is what visitors experienced.

The three numbers that matter are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. We cover what each one means in plain terms in Core Web Vitals, explained for the client who asks. For the audit itself, note which pages fail and why:

• A slow Largest Contentful Paint is usually an oversized hero image, a slow server response or render-blocking scripts.
• A poor Interaction to Next Paint is usually too much JavaScript, often from third-party widgets.
• A poor Cumulative Layout Shift is usually images without dimensions, late-loading banners or web fonts swapping in.

Look for large images on the landing pages specifically. It is the most common speed problem on small-business sites and one of the cheapest to fix.

Hour four: on-page signals, at scale

On-page problems are real but rarely urgent, so they come last. The trick is again to think in templates.

Check for missing titles, duplicate titles and titles too long to display in full. Do the same for meta descriptions. Check for pages missing an H1 or with several of them.

Then look at thin content on the pages that are supposed to rank. A service page with forty words on it is not a technical problem, but it is often the real reason the page does not rank, and the client needs to hear it.

Ignore the long tail for now. A missing description on a 2019 blog post is a finding, not a priority.

Turning findings into a first-month plan

You will have somewhere between fifty and several hundred findings. The client should see five.

Rank by impact first: what does this problem cost this business? Indexing problems on money pages come first, broken journeys second, trust and security third, speed on landing pages fourth, everything else after. Then break ties by effort, so an afternoon's fix beats a three-day project of similar value. We go deeper on this in Five things, not two hundred rows.

For each of the five, write one sentence a business owner can decide about. Not "canonical mismatch on 34 URLs", but "34 of your service pages tell Google to index a different page, so they are unlikely to appear in search until the template is fixed".

A finding without a reason is a chore. A finding with a reason is a decision.

What to send the client

Keep the first page to one screen:

• One health score, with a note that it is calculated the same way every month, so next month's number is comparable.
• The five priorities, each with its reason and a rough effort level.
• What you will check next month, so the client knows the audit is the start of the work, not the whole of it.

Put everything else in an appendix, grouped by category. The client will not read it. Its presence proves you looked properly, and it answers the "what about…" questions before they are asked.

What not to do in the first audit

Do not promise rankings. Nobody can, and a new client remembers the promise longer than the explanation.

Do not lead with third-party authority scores. They are estimates made by tool vendors, not measurements from Google, and a client who fixates on one will judge your work by a number you do not control.

Do not fix things silently. If you find a leftover noindex and remove it in the first week, tell the client what it was and what it was costing. It is the easiest credibility you will ever earn.

If you want to see what the first page of that report looks like with real data, run a free audit on a client site, or look through the sample report.