1. Pages Not Being Indexed
What it is: Your pages exist but Google has decided not to include them in its index — or hasn’t crawled them yet.
Why it hurts: A page that isn’t indexed cannot rank. Full stop. This is the most fundamental technical SEO problem and the first thing to check on any underperforming site.
How to diagnose: Open Google Search Console → Pages report. Look for pages in these statuses:
- Discovered – currently not indexed: Google knows the URL exists but hasn’t crawled it yet
- Crawled – currently not indexed: Google crawled the page and decided not to index it — usually due to thin content, near-duplicate signals, poor internal linking, or slow page speed
- Excluded by noindex tag: A noindex directive is explicitly blocking the page
How to fix it: The fix depends on the specific status. “Crawled – currently not indexed” often requires improving content quality, fixing duplicate signals, and strengthening internal links to the affected pages. “Discovered – currently not indexed” often resolves by adding the URL to your sitemap and building internal links to it. See our full guide on fixing page indexing issues in Google Search Console.
Platform note: On WordPress, category and tag archive pages are frequently the culprit — they get indexed but Googlebot evaluates them as thin content. Consider noindexing category and tag pages that don’t serve a clear user purpose.
2. Crawl Budget Waste
What it is: Google allocates a crawl budget to every site — a limit on how many pages it will crawl within a given period. When that budget gets consumed by low-value URLs, important pages get crawled infrequently or deprioritised.
Why it hurts: If Googlebot is busy crawling your filter combinations, session ID URLs, and paginated archives, it may only visit your most important content pages once a month. New content takes weeks to be indexed. Updates to existing pages go unnoticed.
How to diagnose: A full crawl budget analysis requires log file data — server logs that show exactly which URLs Googlebot requested, how often, and with what status codes. Screaming Frog can approximate this by crawling your site and showing you how many unique URLs exist vs. how many are valuable.
How to fix it: Block low-value URL patterns in robots.txt (use carefully — see problem #4), canonicalise filtered and sorted URLs back to the base page, noindex paginated archives beyond page 2, and remove redirected or error pages from your XML sitemap. Our deeper guide on crawl budget and why it matters covers the full strategy.
Platform note: WooCommerce is particularly vulnerable. Product sorting, colour filters, size filters, and tag archives can generate tens of thousands of indexable URL combinations from a few hundred products. Our guide on faceted navigation SEO covers WooCommerce-specific solutions.
3. Duplicate Content and Canonicalisation Issues
What it is: Multiple URLs on your site serving the same or near-identical content — without telling Google which version is authoritative.
Why it hurts: Google won’t rank multiple versions of the same content. It picks one — usually not the one you’d choose — and suppresses the others. If your canonical tags are missing or misconfigured, Google is making this decision without your input.
How to diagnose: Common duplicate content sources:
- `http://` and `https://` both accessible
- `www` and `non-www` both accessible
- Trailing slash vs. no trailing slash (`/page` and `/page/`)
- URL parameters creating variants (`/products?sort=price` and `/products?sort=new`)
- Printer-friendly or AMP versions without correct canonicals
- WooCommerce product URLs accessible under multiple category paths
Check for canonical issues using Screaming Frog (filter by canonical → look for missing, relative, or non-indexable canonicals) or Semrush’s Site Audit duplicate content report.
How to fix it: Implement consistent canonical tags on every indexable page. The canonical should point to the preferred version — always the same protocol, domain format, and URL structure. See our full guides: canonical issues SEO guide, canonical tag strategies, and what is a canonical URL.
Platform note: On Shopify, products accessible under `/products/` and `/collections/collection-name/products/product-name` are a known duplication issue. Shopify auto-canonicals the `/products/` path, but verify this is working correctly for your theme.
4. Robots.txt Blocking Critical Resources
What it is: Your robots.txt file is accidentally preventing Googlebot from accessing pages, CSS files, JavaScript, or entire directories it needs to crawl and render your site.
Why it hurts: Blocked CSS and JavaScript means Google can’t render your pages — it sees broken layouts or empty content. Blocked page directories means entire sections of your site disappear from Google’s index. Neither shows up as an obvious error — your site looks fine in a browser.
How to diagnose: Open Google Search Console → Settings → robots.txt (or visit yourdomain.com/robots.txt directly). Cross-reference with the URL Inspection tool — if a page shows “Blocked by robots.txt” it won’t be indexed regardless of content quality. See our guide on the GSC blocked by robots.txt issue.
How to fix it: Test every robots.txt change using the robots.txt tester in Google Search Console before pushing to your live server. Never use `Disallow: /` on a production site. Be surgical with directory blocks — block `/wp-admin/` not `/wp-content/`. See our robots.txt optimisation guide for WordPress and robots.txt for large websites.
5. Slow Page Speed and Failing Core Web Vitals
What it is: Your pages load too slowly or deliver poor user experience metrics — specifically Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).
Why it hurts: Core Web Vitals are a confirmed Google ranking signal. Pages that fail — particularly LCP above 4 seconds and CLS above 0.25 — are at a measurable disadvantage in competitive SERPs. In 2026, with mobile-first indexing fully established, poor mobile performance is especially costly.
How to diagnose: Google Search Console → Core Web Vitals report shows field data (real user measurements) across your site. PageSpeed Insights (pagespeed.web.dev) gives you lab data per URL with specific recommendations. Focus on your most important landing pages first — homepage, service pages, top blog posts.
How to fix it: The highest-impact fixes, in order:
- Optimise images — convert to WebP, compress, add explicit dimensions, lazy load below-the-fold images
- Eliminate render-blocking resources — defer non-critical CSS and JS
- Implement caching — server-level caching dramatically reduces TTFB
- Upgrade hosting if server response times are consistently above 600ms
See our detailed guides: improving LCP, INP, and CLS, Core Web Vitals and page experience, optimising Core Web Vitals on WordPress, and best hosting options for Core Web Vitals.
6. JavaScript Rendering Issues
What it is: Your site uses JavaScript to render content — meaning the HTML that loads initially is empty or near-empty, and the visible content only appears after JavaScript executes in the browser.
Why it hurts: Googlebot doesn’t always execute JavaScript immediately or completely. Content that exists only in the JavaScript-rendered version of a page may be invisible to Google — meaning your headings, body copy, internal links, and schema markup simply don’t exist as far as ranking is concerned.
How to diagnose: Use Google Search Console → URL Inspection → View Crawled Page. Compare the screenshot (what Google renders) against what a user sees. Use the “View Source” option in URL Inspection to see the raw HTML Google receives — if it’s near-empty and your content only appears in the rendered version, you have a JavaScript SEO problem. Our guide on JavaScript SEO and indexing covers the full diagnostic process.
How to fix it: Implement server-side rendering (SSR) or static site generation (SSG) to ensure your content is present in the initial HTML response. For Next.js sites, this means using `getServerSideProps` or `getStaticProps`. For other frameworks, evaluate pre-rendering solutions. Our Next.js SEO guide covers implementation in detail.
Real example: A SaaS company’s React application delivered client-side rendered HTML to Googlebot — the crawler was seeing near-empty pages across 200+ URLs. After implementing SSR on key landing pages and the blog index, indexed pages increased 340% within 60 days. No new content was published.
7. Broken Internal Links and Orphan Pages
What it is: Broken internal links are links on your site that point to pages returning 404 errors. Orphan pages are pages with no internal links pointing to them at all.
Why it hurts: Broken links waste crawl budget and signal poor site maintenance to Google. Orphan pages can’t be discovered by Googlebot through crawling — they may never get indexed, regardless of content quality. Both dilute the internal link equity that flows through your site.
How to diagnose: Run a full site crawl with Screaming Frog → filter for internal links returning 4xx responses. For orphan pages, compare your sitemap URL list against Screaming Frog’s crawled URL list — pages in the sitemap but not discovered through crawling are likely orphans.
How to fix it: Redirect broken internal links to their correct destination, or update the link to the new URL. For orphan pages, add contextually relevant internal links from related content. See our guides on fixing broken links and orphan pages and internal linking.
8. Weak Internal Linking Structure
What it is: Your site’s internal links don’t effectively distribute authority to your most important pages — or your content architecture doesn’t signal to Google which pages are the most valuable.
Why it hurts: Internal links are one of the most powerful on-site SEO levers. Pages that receive many internal links with descriptive anchor text are treated as more authoritative than pages with few or generic links. A flat internal link structure treats every page as equally important — which means nothing is prioritised.
How to diagnose: In Screaming Frog, sort pages by number of inlinks. Your most important pages (service pages, pillar content, high-converting landing pages) should have the most internal links. If your homepage and a low-priority blog post from 2021 have the same number of inlinks, your structure isn’t working.
How to fix it: Build a hub-and-spoke architecture — pillar/hub pages on broad topics, spoke pages on specific subtopics, with spokes linking back to the hub. Update older content to link to newer, relevant pieces. Use descriptive anchor text. See our full internal linking strategy guide.
9. XML Sitemap Problems
What it is: Your XML sitemap contains URLs that are noindexed, redirected, returning errors, or otherwise shouldn’t be submitted to Google — sending mixed signals about what you want indexed.
Why it hurts: Your sitemap is a priority signal to Google — it says “these are the pages I consider important.” If it contains 404 pages, redirected URLs, or noindexed pages, Google either wastes crawl budget following dead ends or receives conflicting instructions (you’re simultaneously saying “don’t index this” via noindex and “this is important” via sitemap).
How to diagnose: Download your sitemap XML and run the URLs through Screaming Frog. Filter for non-200 status codes and noindexed pages — these should not be in your sitemap. Google Search Console → Sitemaps report also shows sitemap errors.
How to fix it: Your sitemap should contain only canonical, indexable, 200-status URLs. Remove redirected URLs, noindexed pages, and error pages. For large sites, see our guides on XML sitemaps for large sites and submitting your sitemap to search engines.
10. Missing or Invalid Structured Data
What it is: Your pages are missing schema markup entirely, or the schema you have contains errors that prevent Google from using it for rich results.
Why it hurts: Schema markup doesn’t directly improve rankings — but it enables rich results (FAQ dropdowns, star ratings, breadcrumbs, product prices) in SERPs, which dramatically improve click-through rates. Pages eligible for rich results that don’t have schema are leaving visibility on the table.
How to diagnose: Google’s Rich Results Test (search.google.com/test/rich-results) validates schema on any URL and shows errors. Google Search Console → Enhancements report shows schema errors across your entire site.
How to fix it: Add relevant schema for your content type — FAQPage for FAQ sections, Article for blog posts, Product for e-commerce, LocalBusiness for local businesses, BreadcrumbList for all pages. Validate every schema block before publishing. See our guides: structured data implementation, advanced schema markup, fixing schema errors, and schema markup for products.
11. Redirect Chains and Loops
What it is: Redirect chains occur when URL A redirects to URL B, which redirects to URL C — forcing Googlebot and users to follow multiple hops to reach the final destination. Redirect loops occur when the chain circles back on itself and never resolves.
Why it hurts: Every redirect hop loses a small amount of link equity. Chains of 3+ hops can noticeably dilute PageRank. Redirect loops cause Googlebot to give up entirely on those URLs. Both waste crawl budget on navigation rather than content evaluation.
How to diagnose: Screaming Frog → Response Codes → filter for 3xx. Follow each redirect chain and count the hops. Any chain longer than one hop (A → B) is worth collapsing. Check for loops in the same view — they appear as circular references.
How to fix it: Collapse all chains so every redirect points directly to the final destination URL. Update internal links to skip the redirects entirely — linking directly to the final URL is always preferable to relying on a redirect. See our comprehensive guide on SEO redirects: types and impact and redirect chains and loops.
12. Poor Mobile Crawl Experience
What it is: Google uses mobile-first indexing — meaning it evaluates and ranks your site based on how Googlebot’s mobile crawler experiences it. If your mobile experience differs significantly from desktop (hidden content, different navigation, missing schema), your rankings reflect the mobile version.
Why it hurts: Content visible only on desktop but hidden on mobile is effectively invisible to Google in 2026. Mobile-specific technical issues — different canonical tags on mobile vs desktop, slower mobile page speed, blocked mobile resources — can cause ranking suppression that doesn’t show up on a desktop crawl.
How to diagnose: Google Search Console → Mobile Usability report. Also use the URL Inspection tool and switch between desktop and mobile rendering to compare what Google sees on each. Screaming Frog allows you to set the user agent to Googlebot Smartphone to run a mobile-specific crawl.
How to fix it: Ensure your mobile and desktop versions serve identical content. Don’t hide content behind “read more” toggles on mobile that are expanded on desktop. Keep schema markup consistent across both versions. See our guides on mobile SEO and Core Web Vitals and mobile crawl issues.
How These Problems Compound Each Other
No technical SEO problem exists in isolation. The most common pattern we see in audits:
Crawl budget waste + weak internal linking + canonicalisation gaps = chronic under-indexation
A WooCommerce store generating 50,000 low-value filter URLs (crawl budget waste) with no canonical strategy (canonicalisation gap) and thin internal linking to product pages (weak architecture) will struggle to get important product pages indexed reliably — regardless of how good the product content is.
Fix one and you help. Fix all three simultaneously and the improvement compounds.
This is why a proper technical SEO audit matters — it identifies which problems are present and how they interact, so you can prioritise fixes by cumulative impact rather than tackling them in isolation.
Quick Diagnostic Checklist
Use this to triage your own site before deciding what needs expert attention:
If you’re flagging more than 3 of these, your site likely has compounding technical issues worth addressing systematically. Our technical SEO checklist for WordPress and full technical SEO checklist are useful starting points for a structured self-audit.
Frequently Asked Questions
How do I know which technical SEO problem is most urgent? Prioritise by impact on indexation first — if pages aren’t indexed, everything else is irrelevant. Start with the GSC Pages report. Once indexation is healthy, move to page speed and Core Web Vitals, then structured data and internal linking.
Can I have multiple technical SEO problems at the same time? Almost always yes. In our experience auditing hundreds of sites, the average site has 4–7 significant technical issues running simultaneously. They interact with each other — fixing one often reveals the next. This is why a structured audit with prioritised recommendations is more useful than fixing issues in the order you notice them.
Do technical SEO problems affect all pages equally? No. New pages on low-authority sites are disproportionately affected by crawl budget and indexation issues. High-traffic, well-linked pages are more resilient. This is why new content on growing sites often underperforms — the technical infrastructure isn’t scaled to support it yet.
How long does it take to fix common technical SEO problems? Simple fixes (robots.txt correction, sitemap cleanup, adding canonical tags to a handful of pages) can be done in days. Complex fixes (implementing SSR on a JavaScript framework, restructuring URL architecture, building a crawl budget strategy for a large catalog) take weeks or months of coordinated work. The timeline for Google to recognise and respond to fixes ranges from days (for crawl-related fixes) to 3–6 months (for trust and authority signals).
Should I fix all technical SEO problems at once or in stages? In stages — always. Making multiple significant technical changes simultaneously makes it impossible to attribute ranking changes to specific fixes. Implement in priority order, verify each fix in GSC before moving to the next, and document everything. This is particularly important for migrations and large-scale canonical changes.
If several of these issues look familiar, a structured technical SEO audit is the fastest way to understand which problems exist on your site, how they interact, and what to fix first. Our technical SEO team specialises in platform-specific diagnosis and implementation — not just reports.
