Blog

“Page with redirect” means the URL forwards visitors elsewhere, so Google indexes the destination instead — usually exactly what you want. Its broken sibling, “Redirect error”, always needs fixing.

What “Page with redirect” means

Google’s wording: this is a non-canonical URL that redirects to another page, so it will not be indexed. The redirect works; Google followed it and put the destination in the index instead.

Normal vs. worth fixing

• Normal: http → https, non-www → www (or the reverse), old slugs after you renamed a post, trailing-slash normalisation, deleted pages redirected to a true replacement.
• Worth fixing: redirecting URLs listed in your XML sitemap — a sitemap should only list final, indexable URLs.
• Worth fixing: internal links and menus pointing to URLs that redirect. Every hop wastes crawl effort; link to the final URL directly.
• Worth fixing: a page you want indexed that redirects unexpectedly — often a plugin rule, a language redirect or a login redirect.

“Redirect error” — the one you must fix

This separate status means Google couldn’t complete the redirect at all. Google lists the causes: a redirect chain that was too long, a redirect loop, a redirect URL that exceeded the maximum URL length, or a bad or empty URL in the chain. Test the URL with URL Inspection’s live test or any redirect-checker, and make each old URL go directly to its final destination in one 301 hop.

Clean-up checklist

• Sitemap: make sure it lists only final URLs (Yoast and Rank Math handle this automatically for normal posts).
• Internal links: update menus and in-content links to the final URL.
• Use 301 for permanent moves and keep redirects in place for at least a year after a migration.
• Flatten chains: A → B → C becomes A → C and B → C.
• Don’t redirect everything to the homepage — Google tends to treat that as a soft 404.

FAQ

“Sitemap could not be read” (or “Couldn’t fetch”) means Google tried to load your sitemap and failed — wrong URL, a block, broken XML, or simply a brand-new submission that has not been processed yet.

The 2-minute first check

The real causes

• Wrong URL. WordPress with Yoast uses /sitemap_index.xml; WordPress core uses /wp-sitemap.xml; Rank Math uses /sitemap_index.xml. Submitting /sitemap.xml by habit is the classic mistake.
• Blocked for Googlebot. A robots.txt rule, a security plugin, a firewall or bot-protection challenge that lets you in but not Google.
• Broken XML. Blank lines or PHP warnings before the <?xml declaration, unescaped ampersands, or a caching plugin serving a minified HTML version.
• Too big. A single sitemap may hold at most 50,000 URLs or 50 MB uncompressed. Split larger ones and use a sitemap index.
• Server errors or timeouts while Google fetched it — slow hosting, rate limiting, 5xx responses.
• A brand-new submission. On new sites the report often shows “Couldn’t fetch” for a while even when the file is fine. Many site owners see it flip to “Success” on its own.

Fixes that work

• Submit the exact URL your plugin generates, and delete stale submissions of old sitemap URLs.
• Exclude sitemaps from caching and minification, and whitelist Googlebot in your security or firewall settings.
• Validate the XML with any online XML sitemap validator; fix anything before the opening <?xml line.
• List the sitemap in robots.txt with a Sitemap: line, so every crawler — including Bing — finds it.
• Resubmit once after fixing. Repeated resubmits don’t speed anything up.

FAQ

“Excluded by noindex tag” means Google crawled your page, found an instruction not to index it, and obeyed — the only question is whether you put that instruction there on purpose.

What “Excluded by ‘noindex’ tag” means

Google’s wording: when it tried to index the page, it encountered a noindex directive and therefore did not index it. It’s the most obedient status in the report — Google did exactly what the page told it to.

Where a noindex hides

• The robots meta tag in the page’s HTML: <meta name=”robots” content=”noindex”>. View source and search for “noindex”.
• The X-Robots-Tag HTTP header, set by the server, CDN or a plugin. It’s invisible in the page source — check the response headers, or URL Inspection’s “Indexing allowed?” line.
• WordPress “Discourage search engines” (Settings → Reading). One checkbox that noindexes the entire site. Often left on after launch.
• SEO plugin settings. Yoast: “Allow search engines to show this content in search results?” per post and per content type. Rank Math: the Robots Meta setting per post and in Titles & Meta.
• Maintenance or “coming soon” plugins and some page builders that add noindex while active.

Remove it step by step

• Confirm in URL Inspection. Run a live test: “Indexing allowed? No: ‘noindex’ detected in ‘robots’ meta tag” (or in the X-Robots-Tag header) tells you which source to chase.
• Fix the source, not just the page: if a whole post type is set to noindex in your SEO plugin, every new post inherits it.
• Purge caches. Page caches and CDNs can keep serving the old noindexed HTML. Clear them after the change.
• Make sure it isn’t blocked by robots.txt. Google must crawl the page to see the change — see Blocked by robots.txt.
• Request indexing for important pages and click Validate fix for the rest.

Related guides: How to remove a URL from Google · How to check if a page is indexed

No noindex in the HTML? Check the response headers: a noindex can also come from an X-Robots-Tag HTTP header, which never shows up in the page source.

FAQ

“Blocked by robots.txt” means your robots.txt forbids Googlebot from crawling the URL — and because robots.txt controls crawling, not indexing, the blocked page can still end up in Google as a bare, description-less result.

“Blocked by robots.txt” — what it means

Your robots.txt (at yoursite.com/robots.txt) contains a Disallow rule that matches this URL. Googlebot obeys it and doesn’t fetch the page. For admin areas, cart pages and internal search results, that’s exactly what you want. For articles and product pages, it’s a mistake.

Common accidental blocks: a leftover Disallow: / from a staging site, a too-broad rule like Disallow: /p that also matches /products/, or a plugin that rewrote the file.

“Indexed, though blocked by robots.txt” — what it means

Google can index a URL it isn’t allowed to crawl if enough links point to it. It then shows the URL with little or no description, because it never read the page. This is a warning, and it trips people up in both directions:

What do you actually want?

• Page should rank → it must be crawlable. Remove the matching Disallow rule.
• Page should never appear in search → allow crawling, add a noindex meta tag or X-Robots-Tag header. Once Google has dropped it, you can leave it as is.
• Page is crawl waste (filters, internal search, endless calendars) and isn’t indexed → a robots.txt block is fine. Ignore the report for those URLs.

How to fix both statuses

• Open the robots.txt report in Search Console (Settings → robots.txt). It shows the version Google fetched, when, and any parse errors.
• Find the matching rule. URL Inspection tells you a URL is blocked; compare its path with your Disallow lines. Remember that rules match by prefix.
• Edit carefully. On WordPress, Yoast (Tools → File editor) and Rank Math let you edit robots.txt; otherwise edit the file in your site root. Never block CSS or JavaScript your pages need to render.
• Keep the sitemap line. Add Sitemap: https://yoursite.com/sitemap_index.xml (or your sitemap’s URL) so crawlers find it.
• Validate. Click Validate fix on the issue, or Request indexing for the key pages.

Related guides: AI crawlers and robots.txt · How to remove a URL from Google

Need to keep a PDF or image out of Google? Don’t block it in robots.txt — send a noindex with the X-Robots-Tag header instead.

Not robots.txt, but a 403? If Search Console shows “Blocked due to access forbidden (403)”, the block is in your firewall or server, not in robots.txt: here’s how to fix it.

Test your rules. Paste your robots.txt into our free robots.txt tester to see exactly which rule blocks a URL for Googlebot.

FAQ

A soft 404 is a page that returns “200 OK” to browsers but looks missing or empty to Google — so Google treats it as not found and keeps it out of the index.

What a soft 404 is

Google’s definition: the page returns a user-friendly “not found” message, but not a 404 HTTP response code. In practice Google also flags pages that are technically “found” but have so little content they might as well be missing.

The six usual causes

• Custom “not found” pages that return 200. The page says “Oops, nothing here” but the server reports success.
• Empty category, tag or search pages. “No products found” or “No posts yet” with nothing else on the page.
• Out-of-stock or expired items reduced to a title and a “no longer available” line.
• Redirects to an irrelevant page — especially mass-redirecting deleted URLs to the homepage. Google often treats those as soft 404s.
• Thin placeholder pages — “coming soon,” near-empty templates, auto-generated location pages.
• Rendering failures. JavaScript that fails for Googlebot, or resources blocked by robots.txt, so Google renders a blank page.

Fix it by page type

• Shops: keep temporarily out-of-stock products live with full details, alternatives and a restock note. For permanently discontinued items, 301 to the successor or category — or return 404/410.
• JavaScript sites: use URL Inspection → Test live URL → View tested page. If the screenshot is blank, fix rendering (server-side rendering, unblocked resources) before anything else.
• WordPress: make sure your theme’s 404 template really returns a 404 status, and noindex empty tag archives with your SEO plugin.

FAQ

“Alternate page with proper canonical tag” means this URL points to another page as the main version and Google agreed — in most cases that is your canonical setup working exactly as intended.

What “Alternate page with proper canonical tag” means

Google’s description: the page is marked as an alternate of another page and correctly points to the canonical page, which is indexed. You said “the main version lives over there,” and Google said “agreed.”

When it’s completely normal (most of the time)

• Tracking and sort parameters — ?utm_source=, ?sort=price — pointing to the clean URL.
• Separate mobile or AMP versions that point to the main page.
• Product variants (colour, size) that canonicalize to one main product page.
• Syndicated or republished copies that credit the original.

In all these cases, a growing number in this report simply means Google is discovering more variants and handling them correctly. You don’t need to “fix” anything, and you don’t need to click Validate fix.

When it’s a real problem

It’s a problem only when a URL in this list should be indexed in its own right. Typical culprits:

• A theme or plugin bug that sets every page’s canonical to the homepage or to page 1 of a blog.
• Copied templates where a hard-coded canonical from one page ended up on others.
• Paginated pages (page 2, 3…) canonicalized to page 1, which hides the posts linked only from deeper pages.
• Language versions canonicalized to one language instead of each pointing to itself and using hreflang.

How to fix a wrong canonical

• Make unique pages self-referencing. Each page you want indexed should point its canonical at itself.
• Find the source. Check your SEO plugin’s per-page canonical field, your theme header, and any “canonical URL” setting that was filled in by mistake.
• Handle languages with hreflang, not canonicals. Each language version is its own canonical; hreflang links them together.
• Then validate. After fixing, use Validate fix or URL Inspection → Request indexing for the key pages, and give Google time to recrawl.

FAQ

“Duplicate without user-selected canonical” means Google found near-identical pages on your site, you never said which one is the main version, so Google picked one itself — and this URL lost.

What “Duplicate without user-selected canonical” means

Google’s own wording: the page is a duplicate of another page, although it doesn’t indicate a preferred canonical page. Two things are true at once:

It’s the “silent” sibling of Duplicate, Google chose different canonical than user. There you declared a canonical and Google disagreed; here you declared nothing at all.

The usual causes

• URL parameters. ?utm_source=, ?sort=, ?ref= and session IDs create endless copies of one page.
• Protocol and host variants. http vs https, www vs non-www — if both resolve without redirecting, you have twins.
• Trailing slashes and case. /page and /page/ are different URLs to Google.
• CMS extras. WordPress attachment pages, tag and archive pages that mirror post content, printer-friendly versions, faceted filters in shops.
• Missing canonical tags. A theme or setup that simply doesn’t output rel=”canonical”.

Check it in 60 seconds

How to fix it (in order)

• Add self-referencing canonicals everywhere. Every indexable page should declare itself as canonical. On WordPress, Yoast SEO, Rank Math and All in One SEO do this automatically — check your page source for rel=”canonical”.
• Redirect the obvious twins. Force one protocol and host with a 301 (https + either www or non-www) and pick one trailing-slash style.
• Point variants at the original. Parameter and filter URLs should carry a canonical pointing to the clean URL.
• Make your signals agree. Sitemap, canonical tags and internal links should all name the same URL. Link internally to the clean version only.
• Make genuinely different pages different. If two pages are “duplicates” because they share 90% of their text, rewrite or merge them — a canonical tag can’t make thin twins unique.

FAQ