# 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.

Updated 2026-09-26 · Technical SEO · HTML version: https://getreport.app/guides/technical-seo-issues

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](https://getreport.app/guides/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](https://getreport.app/tools/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.

> **Free tool:** [Free SEO checker and SEO audit for any page](https://getreport.app/tools/seo-audit): Free SEO audit of any page: titles, headings, canonical, robots.txt, sitemaps, indexability and broken links, each with a plain-language fix. No sign-up.

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](https://getreport.app/guides/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.

> **Check: The page is not set to noindex.** A noindex directive tells Google to drop this page from search results. Unless that is intended, every visit from search is lost.
>
> 1. Remove noindex from the robots meta tag and from the X-Robots-Tag header, unless the page should stay out of search.
> 2. In WordPress, untick Settings → Reading → "Discourage search engines" and check the page's SEO plugin settings.

### 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](https://getreport.app/guides/robots-txt-before-it-hides-your-site).

> **Check: robots.txt allows this page.** A Disallow rule stops search engines from crawling this page, so they cannot read its content or see any updates. The page can still appear in results as a bare URL with no description.
>
> 1. Remove or narrow the Disallow rule in robots.txt so this URL is allowed for all crawlers.
> 2. If the page should stay out of search, allow crawling and use a noindex tag instead; a blocked page cannot be de-indexed.

### 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](https://getreport.app/guides/canonical-tags-explained).

> **Check: Canonical tag points to a valid URL.** The canonical tag asks Google to index that URL instead of this one. If it points to another site, appears twice or leads to an error page, your ranking signals are given away or ignored.
>
> 1. Point the canonical at this page's own clean URL (same scheme and host, no tracking parameters), and make sure it returns 200.
> 2. Keep exactly one canonical tag; if a plugin and the theme both add one, disable one of them.

### 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](https://getreport.app/guides/soft-404s-what-they-are-and-how-to-fix-them) and [404, 410 or redirect](https://getreport.app/guides/404-vs-410-vs-redirect-what-to-do-with-removed-pages).

## 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](https://getreport.app/guides/redirect-chains-after-a-migration-finding-every-hop).

> **Check: The URL loads without a redirect chain.** Each redirect is a full request and response before the browser can start loading the page, which slow mobile connections feel most. Google says redirects do not lose ranking value, but Googlebot follows at most 10 hops, and long chains slow crawling and break when one hop changes.
>
> 1. Point every old URL straight at the final one (a single 301), and update internal links to use the final URL directly.
> 2. Look for rules that stack, for example http → https, then non-www → www, then trailing slash; combine them into one rule.

### 6. Broken internal links

**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](https://getreport.app/guides/find-and-fix-broken-links).

> **Check: Broken links.** A link to a 404 page is a dead end for visitors and a wasted crawl for search engines. Old campaign or product pages are the usual cause.
>
> 1. Update or remove each link listed in the technical detail; redirect the missing pages if they still get visits.
> 2. In WordPress, a plugin such as Broken Link Checker finds these site-wide.

### 7. Internal links that redirect

**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](https://getreport.app/guides/redirect-chains-after-a-migration-finding-every-hop).

> **Check: No link on the page goes through a redirect.** Every redirected link costs visitors an extra round trip, and a chain can break when one hop changes. Linking to the final URL is free.
>
> 1. Update each link listed in the technical detail to its final URL.
> 2. Search your templates and content for the old URLs after a domain, https or trailing-slash change.

### 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](https://getreport.app/guides/trailing-slashes-www-and-https-pick-one).

> **Check: Only one of www and non-www serves the page.** When the www and non-www addresses both return the page, search engines see two copies of every URL and split links and rankings between them.
>
> 1. Pick one host as canonical and 301-redirect the other to it, keeping the path (most hosts and CDNs have a one-click setting for this).
> 2. Make sure the canonical tag on every page uses the chosen host.

> **Check: The site is served over HTTPS.** Browsers label HTTP pages "Not secure" and Google uses HTTPS as a small ranking signal. Anyone on the network can read or alter what visitors see.
>
> 1. Get a certificate (Let's Encrypt is free) and enable HTTPS on your host.
> 2. Redirect every http:// URL to https:// with a 301.

### 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](https://getreport.app/guides/xml-sitemap-validation).

> **Check: Sitemap URL status.** A sitemap should list only pages that answer 200. Redirects, 404s and noindex pages in it waste crawl budget and make Google trust the file less.
>
> 1. Remove deleted pages from the sitemap and list the final URL of redirected pages.
> 2. Most CMS plugins do this automatically; if you generate the file yourself, rebuild it from the live URL list before publishing.

### 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](https://getreport.app/guides/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](https://getreport.app/guides/duplicate-titles-and-descriptions-across-a-site).

> **Check: The page has a <title>.** The title is the headline Google shows in results and the text in the browser tab. Without it, the page is hard to find and hard to recognise.
>
> 1. Add a <title> inside <head> that describes this page in 30–60 characters.
> 2. In WordPress, set it under the page's SEO panel (Yoast, Rank Math) or the page title.

### 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](https://getreport.app/guides/javascript-seo).

> **Check: The visible text is present without JavaScript.** Google renders JavaScript later and with a budget, so text that only appears after scripts run can be indexed late or not at all. Other search engines and link previews may never see it.
>
> 1. Serve the main content in the HTML (server-side rendering or static generation) and use JavaScript only to enhance it.
> 2. Check the difference in the technical detail; menus and widgets are fine, headlines and body copy are not.

### 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](https://getreport.app/guides/mobile-seo-checklist) on one page per template.

> **Check: Viewport meta tag is present.** Without a viewport tag, phones render the page at desktop width and shrink it. Google indexes the mobile version first, so this hurts rankings directly.
>
> 1. Add <meta name="viewport" content="width=device-width, initial-scale=1"> in <head>.

### 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](https://getreport.app/guides/schema-markup-validation).

> **Check: JSON-LD syntax.** A JSON-LD block with a syntax error is ignored completely, so Google reads no structured data from it. One stray comma or missing quote costs the whole block.
>
> 1. Open the technical detail to see the parser message and the block number.
> 2. Paste the block into a JSON validator, fix the character it points at, and run this check again.

### 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](https://getreport.app/guides/hreflang-return-links).

> **Check: Every hreflang alternate links back to this page.** hreflang only works when every version lists every other version, including itself. An alternate that does not point back makes Google ignore the pair, so visitors get the wrong language.
>
> 1. On each alternate page, add a <link rel="alternate" hreflang="…"> for this page and for itself.
> 2. Generate the tags from one list (CMS, plugin or the XML sitemap with xhtml:link) so every page carries the same set.

## 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](https://getreport.app/guides/page-speed) 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](https://getreport.app/guides/seo-audit-cost) and [picking which fixes to do first](https://getreport.app/guides/picking-which-fixes-to-do-first-impact-vs-effort).

## 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.

> **Free tool:** [Monitor website for changes: email alerts](https://getreport.app/tools/change-monitor): Monitor a website for changes for free and get one email with the added and removed lines when its text changes. It switches on once donations cover it.

The [monthly site health routine](https://getreport.app/guides/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.