SEO Issues

I think of SEO issues as anything that prevents Google from finding, rendering, indexing or ranking a page. The useful taxonomy for me is three buckets: technical, content, and structure. Technical issues block access – server errors, robots.txt blocks, noindex tags, slow load times, mobile problems. Content issues make the page weak – thin copy, duplicate content, missing structured data. Structure issues confuse the site's architecture – broken internal links, poor navigation, orphaned pages. But this classification only helps if it drives action.

I always start with technical issues because if Google cannot crawl the page, everything else is academic. On a recent audit of an ecommerce site with 50,000 product URLs, I found that a robots.txt disallow rule was blocking the entire /products/ directory. Over 45,000 pages were invisible to Google. The client had invested heavily in product descriptions, but none of that effort mattered. I fixed the robots.txt within an hour. Within two weeks, indexed product pages jumped from 2,000 to 38,000. That is the power of tackling technical issues first.

My rule of thumb: run a crawl covering at least 80% of your live URLs, check status codes, and if you see more than 5% 4xx or 5xx, pause all content work and fix the server response. That crawl doubles as the first step of a full [SEO audit](/seo-audit/). Once crawlability is solid, move to content and structure.

Timing is everything. I recommend investigating SEO issues at four specific points. First, after any site migration – domain change, CMS switch, or redesign. Migrations break URLs, redirects, and internal links. I once saw a client lose 60% of organic traffic four days after a domain change because the 301 redirect map was incomplete. Second, when traffic drops suddenly. A sharp decline often points to a single technical cause. I had a case where a developer added a noindex tag to the staging site and accidentally pushed it to production. That 10-minute mistake caused a three-week recovery.

Third, before launching major new content. Ensure the technical foundation is sound so your investment is not wasted. Fourth, when you change site infrastructure – switching to a new hosting provider, implementing a CDN, or deploying a JavaScript framework. Not every issue demands immediate action. I prioritise based on impact and effort. A slow page on an internal blog post is low priority; a canonical mistake on your top-grossing product page is urgent.

For JavaScript-heavy sites, I check the rendered HTML in Search Console's URL Inspection Tool to confirm Google sees the content. This is a key part of [technical SEO](/technical-seo/) and [core web vitals](/core-web-vitals/) monitoring. On mobile, test pages for usability and speed; see [mobile SEO](/mobile-seo/) for specifics.

I have made several mistakes that cost time and traffic. The biggest: thinking robots.txt could deindex a page. It cannot. If external sites link to a blocked URL, Google can still index it. I now use a noindex tag or password protection for pages that should stay out of the index.

Another mistake: leaving a noindex tag on after a staging-to-production launch. I once had a client's entire site hidden for two weeks because a developer had set 'noindex, nofollow' on the homepage for staging. I forgot to verify the meta robots tag in production. Now I always check Search Console's index coverage report immediately after any launch.

I also mishandled canonical tags on a paginated series. I pointed all paginated URLs to the first page, which consolidated all subsequent pages' signals into page one. Google's guidance says to use self-referencing canonicals or rel="next/prev". I fixed it, but it took months to regain the traffic. See [canonical tag](/canonical-tag/) for details.

I also overestimated the power of XML sitemaps. I assumed every URL in the sitemap would get indexed. It does not work that way – Google still needs internal links and sufficient authority. My rule now: if a page is in the sitemap but not indexed, check internal links first, then robots.txt, then noindex. That is what I have learned from auditing hundreds of sites.