SEO Audit

I always start with crawlability and indexability. Not because they are glamorous, but because if Google cannot find a page, nothing else on that page matters. I open Google Search Console and look at the Coverage report first. I scan for pages marked as 'Excluded' that should be indexed, and any 'Error' or 'Valid with warnings' entries. That tells me quickly where to dig.

Next I check whether important pages can actually be crawled. I open the website's robots.txt — often a single directive there blocks half the site. Then I look for noindex tags on pages I intend to be indexed. I use a crawler like Screaming Frog or Sitebulb, configured to simulate Googlebot, and compare the raw crawl output against what I expect. I look for pages that return a 200 but have a noindex in the HTML or headers.

After that I move to canonicalisation. Duplicate URLs because of www/non-www, HTTP/HTTPS, or trailing-slash are common. I verify that every page intended for indexing carries a self-referencing [canonical tag](/canonical-tag/) or that the site resolves variants with [301 redirects](/301-redirect/). I also check the XML sitemap to ensure it lists only indexable, canonical URLs and no redirects or 404s.

Then I audit mobile usability and page speed. I use the Mobile-Friendly Test and Core Web Vitals reports in Search Console. For structured data, I use the Rich Results Test on a sample of pages and cross-reference with the rich results report in Search Console to catch errors or missing eligibility. I also look for duplicate content — thin pages, near-identical product descriptions — and decide whether to consolidate or canonise them.

The biggest trap is trusting tool output blindly. I once had a crawler report that a page was indexable, but when I checked the source code manually there was a noindex tag injected via JavaScript. The crawler had not rendered JavaScript. For JavaScript-heavy sites, you must verify what Googlebot actually sees after rendering. Use the URL Inspection tool in Google Search Console to check the rendered HTML.

Another watch-out is ignoring redirect chains. I have seen chains of six redirects that still return a 200 status at the end — technically they work, but they waste crawl budget and pass less equity. Use a crawler that traces the full redirect path and aims for a maximum of two hops. Also watch for soft 404s, where a page returns a 200 but contains 'page not found' copy. Search Console flags these, but I always confirm by checking a sample.

[Core Web Vitals](/core-web-vitals/) can mislead if you only look at the field data report. I have seen the report show all green but lab tests with Lighthouse reveal poor LCP on specific pages. Use both field and lab data. Also check that your [mobile version](/mobile-seo/) is not blocked by robots.txt or different from the desktop content — I have missed that more than once.

Finally, don't obsess over every issue. The goal is the top five to ten fixes that remove the biggest blockers.

For a long time I skipped manual verification of structured data. I ran the Rich Results Test, saw no errors, and moved on. Then a client saw no rich results in SERPs and I discovered that the test passed syntax but the markup was missing required properties for the eligibility criteria. Now I always cross-reference with Search Console's enhancement reports.

I also used to assume that if a page had a noindex tag in the HTML, it was definitely blocked. But I missed cases where the [robots.txt](/robots-txt/) disallow rule prevented Google from even fetching the page, so the noindex was never seen. Now I check both mechanisms.

Another mistake: I ignored [hreflang tags](/hreflang-tags/) for international sites because I thought they were a nice-to-have. Then I saw a site lose 30% of its international traffic because the tags pointed both ways but the return tags did not exist. Hreflang validation is now part of my indexability check.

I also spent too much time finding every single broken link rather than prioritising issues that block indexation. I now ask: does this problem prevent Google from finding or understanding a high-value page? If not, it goes on a secondary list.