Most SEO problems I find in audits aren't content or keyword problems. They're bugs. The site looks perfect in the browser, Lighthouse is green, the client is happy, and Google quietly refuses to index half of it.
The tricky part is that these bugs don't throw errors. Nothing breaks for the user. So here are the 12 I see most often, with a quick way to catch each one. Shipping the staging noindex to production
The classic. Staging was set to "discourage search engines", the site went live, and nobody unchecked it.
For any stack, check both the HTML and the response headers, since X-Robots-Tag is easy to forget in a server config:
Add this to your launch checklist. Better yet, make it a deploy check. robots.txt blocking what Google needs to render the page
Blocking /wp-content/ or /assets/ "for security" means Googlebot can't load your CSS and JS, so it can't render the page the way users see it.
The reverse is just as common: low-value URLs (internal search, filter combinations, admin-ish paths) left fully crawlable. robots.txt controls crawling, not indexing, so for pages that must stay out of the index, use noindex and let Google crawl them. Content that only exists after JavaScript runs
With client-side rendering, the initial HTML can be an empty shell. Google does render JavaScript, but it's slower, less reliable, and any error means content (or links) simply don't exist for Googlebot.
Then check the rendered HTML in Search Console's URL Inspection tool. If your main content, menu, or product links only appear after hydration, consider SSR or static generation for those routes. Infinite scroll and "load more" without real URLs
Googlebot doesn't scroll or click buttons like a user. Content loaded on scroll events or behind a "Load more" button may never be seen.
Each page of results should have its own URL that works without JavaScript. Canonical and noindex misconfigurations
A few variations I keep finding: Every page canonicalized to the homepage (a template bug) Canonical pointing to a URL that redirects or returns 404 noindex and canonical to another URL on the same page (conflicting signals) Canonical tags added only by JavaScript
Then crawl the site (Screaming Frog or similar) and filter for canonicals that don't point to themselves. Every non-self canonical should be intentional. The CMS generating thousands of empty pages
In a recent audit, a local contractor's site had about 2,600 URLs. Only 58 were service pages. Around 1,650 were image attachment pages and about 700 were tag archives, most with a single post.
WordPress creates an attachment page for every upload. Since WordPress 6.4, new installs have them disabled, but older sites keep them on:
For tag archives, if your SEO plugin doesn't handle it, the core wprobots filter does:
Also check your sitemap index. If you see attachment-sitemap.xml or a huge posttag-sitemap.xml, you have this problem. Building URLs with string concatenation
The missing slash came from an old search-replace (https://old-domain/ → https://example.com). Users never noticed, because the Elementor lightbox opened the image from a separate, correctly generated URL. Crawlers, on the other hand, saw a broken link on every affected page.