Step 1 — Can search engines crawl you?

Check robots.txt for accidental blocks, confirm your XML sitemap lists only canonical URLs, and audit internal links so no important page is more than three clicks from the home page.

Then check that your important pages are linked from somewhere a crawler will reach. Orphaned pages — reachable only from the sitemap — are the most common cause of 'why isn't this page ranking?', and they are invisible to most dashboards.

Also confirm that CSS and JavaScript assets are not blocked. If Googlebot cannot render your pages, everything downstream is guesswork.

Step 2 — Are the right pages indexed?

Compare your sitemap against what is actually indexed. Look for three problems: important pages missing, low-value pages indexed (search results, tag archives, parameter URLs), and duplicate content split across multiple URLs without canonicals.

Set a self-referencing canonical on every indexable page, and noindex anything that exists only for navigation or filtering.

Step 3 — Do you pass Core Web Vitals?

The three thresholds are largest contentful paint under 2.5 seconds, interaction to next paint under 200 milliseconds, and cumulative layout shift under 0.1 — measured on real users, not your office laptop.

Measure on field data rather than a lab score. A lab test from a fast connection can show a healthy number while real data from mid-range Android phones shows something much worse — and it is the field data that affects rankings. Prioritise fixes that move the 75th percentile, not the best case.

  • LCP: compress and correctly size hero images, preload the hero asset, avoid render-blocking fonts
  • INP: break up long JavaScript tasks, defer third-party tags, avoid heavy main-thread work on interaction
  • CLS: reserve space for images, ads and embeds; avoid injecting banners above existing content

Step 4 — Is your structured data telling the whole story?

Implement Organization and LocalBusiness once, sitewide, with consistent name, address, geo coordinates and sameAs profiles. Add Article to blog posts, FAQPage to question content, and BreadcrumbList to hierarchical pages.

Then validate. Structured data that contradicts your visible content is worse than none at all — it teaches machines the wrong thing about your business.

Check the details that quietly break things: dates in Article schema that do not match the visible page, FAQPage markup on content that is not actually a FAQ, and Organization data carrying a phone number you changed last year. Every mismatch is a false fact about your business.

Step 5 — Does your JavaScript render cleanly?

Fetch a sample of pages with JavaScript disabled, or use the URL Inspection rendering report. If key content or links only appear after client-side hydration, you are relying on Googlebot's second pass — which is slower and less reliable than shipping the content in the initial HTML.

Server-rendered content is the safer default for anything that needs to rank.

What should you check before you start?

Before touching anything, establish a baseline. Export your currently indexed pages, your top landing pages by organic traffic, and your Core Web Vitals field data. Without a before picture you cannot tell whether the audit fixed anything or whether a seasonal dip was your own doing.

Then confirm you can access the tools and systems you will need. An audit that identifies problems nobody has the access or budget to fix is a report, not a project.

  • Search Console access, with sitemap and coverage data
  • A full URL export from your sitemap and from the CMS
  • Organic landing page report for the last 12 months
  • Core Web Vitals field data from Search Console
  • Crawl tool access — Screaming Frog, Sitebulb or similar

What tools do you need for an audit?

Four tools cover almost everything. A crawler such as Screaming Frog or Sitebulb maps every URL and surfaces status codes, titles, canonicals and internal links. Search Console gives you indexation, query and Core Web Vitals data straight from Google. PageSpeed Insights separates lab from field performance. A schema validator confirms your markup parses.

You do not need an enterprise platform to run a competent audit. Most technical problems appear in the first two hundred rows of a crawl and in the coverage report. Tools earn their cost at scale; at small-business scale, careful reading beats more software.

How do you prioritise what to fix first?

Order by whether the problem prevents indexing, then by how many pages it affects, then by how hard it is to fix. A sitewide noindex is catastrophic and trivial to reverse, so it goes first. A single orphaned page matters far less than a template-level canonical error affecting four hundred URLs.

Be sceptical of audits that present two hundred issues as a flat list. Most contain perhaps ten things that matter and a hundred and ninety that are cosmetic or theoretical. If your supplier cannot rank their own findings, they are producing a document rather than a plan.

What are the most common technical SEO mistakes?

Five recur constantly: accidental noindex tags left over from a staging environment, canonical tags pointing at the wrong version of a URL, duplicate content across trailing-slash and non-trailing-slash versions, JavaScript and CSS blocked in robots.txt, and pagination or filter parameters generating thousands of crawlable near-duplicates.

The common thread is that none of them look like mistakes in a browser. Everything renders, everything works, and the site simply does not rank. That is why a crawl and an indexation report belong in every quarterly review rather than in a one-off project.

How often should you re-audit, and what changes?

Run a full audit quarterly and monitor continuously in between. Set alerts for coverage errors, Core Web Vitals drops and unexpected changes in indexed page count. Most technical problems announce themselves in Search Console days before they show up in traffic.

Always run an extra audit after a deploy, a redesign, a platform migration or a domain change. Those are the moments when a template change or a forgotten redirect can take out thousands of URLs at once, and the damage compounds the longer nobody notices.