Skip to content

SEOPart of: Technical SEO

Technical SEO issues: the 15 most common and how to fix each

The technical SEO issues that turn up on almost every site, from a stray noindex to redirect chains and JavaScript-only content: how to spot each one, what it costs you and the fix.

getReport teamUpdated 26 Sept 202616 min read

The most common technical SEO issues are pages accidentally set to noindex, robots.txt blocking pages or their resources, canonical tags pointing to the wrong URL, redirect chains, broken internal links, duplicate titles, sitemaps full of dead URLs, and content that only appears after JavaScript runs. Each one stops Google from crawling, indexing or understanding pages that are otherwise fine. This guide lists the fifteen issues we see most, in order of how much damage they do, with how to spot each one and how to fix it. For how the pieces fit together, start with our guide to technical SEO.

Quick answer

  • Fix what hides pages first: a stray noindex, a robots.txt block, a wrong canonical, pages returning 404 or 5xx.
  • Then fix what wastes crawling: redirect chains, broken internal links, sitemaps listing redirected or removed URLs, several versions of every URL.
  • Then fix what confuses Google: duplicate titles, JavaScript-only content, missing mobile content, broken structured data and hreflang.
  • Find them with Search Console's Page indexing report (what Google saw) and a free SEO audit on one page per template (why).
  • Fix at the template, not page by page. Most issues are repeated on every page built from one layout.
  • Watch after releases. Most issues arrive with a deploy, a plugin update or a migration.

How to find technical SEO issues on your site

Two free sources cover most of it.

Google Search Console shows what Google actually did. The Page indexing report lists every URL Google knows that is not indexed, grouped by reason, such as "Excluded by 'noindex' tag", "Blocked by robots.txt", "Page with redirect" or "Not found (404)". URL Inspection shows, for one URL, whether it is indexed, which canonical Google chose, and a live test of what Googlebot fetched.

An audit of one page per template shows why. Pick the home page, a category or listing, a product or service page and an article, and run each through a checker. Problems in a template repeat on every page built from it, so four or five runs cover most of a site.

The getReport SEO audit reads the page's title, description, headings, canonical, robots directives, hreflang, language and viewport, fetches robots.txt and the XML sitemap, follows redirects and checks the links on the page for broken ones. Findings are ordered by how many points they cost, which is also roughly the order below. It checks one page per run and does not show rankings or backlinks.

For a whole-site pass, the SEO audit checklist lists 45 checks in the order that matters.

Issues that hide pages from Google

1. A stray noindex

What happens: a <meta name="robots" content="noindex"> tag or an X-Robots-Tag: noindex header tells Google to drop the page. The page keeps working for visitors, so nobody notices until traffic falls.

Where it comes from: a staging site copied to production, the WordPress "Discourage search engines from indexing this site" box, an SEO plugin's per-page or per-type setting, or a developer's header rule.

How to spot it: Page indexing → "Excluded by 'noindex' tag"; view source and search for noindex; check response headers too.

Fix: remove the tag or header at its source (theme, plugin setting, server config), then request indexing in URL Inspection.

2. robots.txt blocking pages or resources

What happens: a Disallow rule stops Google from crawling a page. If it blocks CSS or JavaScript, Google renders the page without them and may see an empty or broken layout.

How to spot it: Page indexing → "Blocked by robots.txt"; the robots.txt report in Search Console settings; "Indexed, though blocked by robots.txt" for pages Google indexed from links without reading them.

Fix: remove or narrow the rule. Remember that robots.txt does not remove a page from the index; to keep a page out, let Google crawl it and use noindex. See robots.txt mistakes that hide your site.

3. Canonical tags pointing to the wrong URL

What happens: <link rel="canonical"> names the preferred URL. One that points to the home page, to a URL that redirects or returns 404, to the http version, or to a staging domain asks Google to index something other than the page you want.

How to spot it: URL Inspection shows "User-declared canonical" and "Google-selected canonical"; Page indexing → "Duplicate, Google chose different canonical than user".

Fix: every indexable page carries a canonical to its own clean, final, https URL. See canonical tags explained.

4. Pages returning errors or soft 404s

What happens: pages that should rank return 404, 410 or 5xx, or return 200 with "no products found" text that Google classifies as a soft 404.

How to spot it: Page indexing → "Not found (404)", "Server error (5xx)" and "Soft 404"; server logs for 5xx spikes.

Fix: restore the page, or 301 it to the closest replacement; fix server errors at the host; return a real 404 for pages that are gone. See soft 404s and 404, 410 or redirect.

Issues that waste crawling

5. Redirect chains and loops

What happens: URL A redirects to B, which redirects to C. Each hop adds a round trip for visitors, and Google follows only a limited number of hops; its documentation says Googlebot follows up to 10 redirect hops before giving up. Loops never resolve.

How to spot it: a redirect checker; Page indexing → "Redirect error".

Fix: point every old URL straight at the final destination, and update internal links to the final URL. After a migration, see finding every hop of a redirect chain.

What happens: links to pages that return 404 waste crawl requests, leak link value and frustrate visitors.

Fix: update the link to the right URL, or redirect the target if many sites link to it. See finding and fixing broken links.

What happens: the menu or body links to http://, a URL without the trailing slash or an old path, and every click and crawl goes through a redirect first.

Fix: link to the final URL at the source, usually a menu, template or a search-and-replace in the database. See internal links that redirect.

8. Several versions of every URL

What happens: the site answers on http and https, with and without www, and with and without a trailing slash, and each returns 200. Google sees up to eight copies of each page and has to pick one.

Fix: choose one host and one form, and 301 every other version to it. See trailing slashes, www and https: pick one.

9. Sitemaps listing the wrong URLs

What happens: the XML sitemap lists URLs that redirect, return 404, carry noindex or are not canonical. Google reads the sitemap as a list of pages you want indexed, so wrong entries dilute it.

Fix: generate the sitemap from the CMS so it lists only indexable, canonical, 200 URLs, and submit it in Search Console. See XML sitemap validation.

10. Orphan pages

What happens: pages exist in the sitemap but no internal link points to them, so Google has little reason to think they matter.

Fix: link each one from a relevant category, hub or article. See orphan pages: finding and linking them.

Issues that confuse Google

11. Missing, duplicate or boilerplate titles

What happens: a template gives hundreds of pages the same title, or the site name alone. Pages look interchangeable, and Google is more likely to rewrite them.

Fix: a title template with the page's own name first, then hand-written titles for top pages. See duplicate titles and descriptions across a site.

12. Content that needs JavaScript

What happens: text, links or tags are added by JavaScript after the page loads. Google renders JavaScript, but later and not always completely, and other crawlers, including most AI crawlers and social apps, read only the raw HTML. A canonical or noindex changed by JavaScript is especially risky.

Fix: server-render or pre-render the main content, links and head tags. See JavaScript SEO.

13. Mobile gaps

What happens: Google indexes the mobile version. A missing viewport tag, content hidden on phones, a shorter mobile menu or a full-screen pop-up all cost you in search.

Fix: run the mobile SEO checklist on one page per template.

14. Broken structured data

What happens: JSON-LD with a syntax error is ignored entirely; markup missing required properties loses its rich result.

Fix: validate after every template change, and keep one plugin in charge of schema. See schema markup validation.

15. Broken hreflang

What happens: on multilingual sites, hreflang annotations without return links, with wrong language codes or pointing to redirected URLs are ignored, and the wrong language version ranks.

Fix: every alternate lists every other, including itself, with valid codes and final URLs. See hreflang return links.

What about slow pages?

Speed matters, but it rarely hides a page from Google the way the issues above do. Google's ranking systems use Core Web Vitals as one of many signals, and relevance still wins. Fix speed after indexing and crawl issues, starting with the templates that get the most search traffic; our page speed guide covers it.

How to prioritise the fixes

Rank each issue by two things: how many pages it affects and how badly. A noindex on one blog post is small; a noindex on the product template is an emergency. The order above is a good default:

  1. Anything that removes pages from the index (1–4).
  2. Anything site-wide that wastes crawling (5–10).
  3. Anything that weakens how pages are understood or shown (11–15).
  4. Speed and extras.

After fixing, validate in Search Console's Page indexing report, where each issue has a "Validate fix" button, and give Google a few days to weeks to recrawl. For help putting a number on the effort, see what an SEO audit costs and picking which fixes to do first.

How to stop the issues coming back

Most technical SEO issues are regressions: a release reintroduces noindex, a plugin update changes canonicals, a migration breaks redirects. Three habits catch them early:

  • Check after every release on the same four or five template pages.
  • Look at Search Console weekly, especially the Page indexing report's trend line.
  • Watch key pages for changes. The getReport change monitor emails you the lines that were added or removed when a page's visible text changes. It is a funded unlock and switches on once donations cover it.

The monthly site health routine turns this into a 30-minute habit.

Questions people ask

What is the most common technical SEO issue?

Duplicate or missing titles and broken internal links are among the most frequent, because templates and everyday content changes create them constantly. The most damaging common issue is a stray noindex left from staging or a plugin setting, because it removes pages from Google while the site keeps working for visitors. Check for that first on every template.

How do I know if my site has technical SEO problems?

Open Google Search Console's Page indexing report: a growing number of pages that are not indexed, grouped under reasons such as "Excluded by 'noindex' tag" or "Page with redirect", is the clearest sign. Then run a free SEO audit on one page per template to find the cause. Falling impressions after a release are another strong hint.

Can technical SEO issues cause a drop in rankings?

Yes. Issues that remove pages from the index, such as a noindex, a robots.txt block or a wrong canonical, make those pages disappear from results completely. Issues such as redirect chains, JavaScript-only content or mobile gaps weaken pages more gradually. If traffic fell right after a release or migration, look for a technical cause before blaming content or an algorithm update.

How long does it take Google to notice technical SEO fixes?

Anywhere from a few days to several weeks. Google needs to recrawl the affected pages, which happens sooner for popular pages than for deep ones. You can speed up individual URLs with Request indexing in URL Inspection, and track a group with Validate fix in the Page indexing report. Updating the sitemap's lastmod for changed pages helps too.

Check your site before and after Check