My site had 18 URLs flagged as "Redirect error" in Search Console, and the validation sat on "Started" for weeks without moving. The cause was not a broken redirect I had created on purpose. It was Blogger's automatic mobile redirect meeting Google's smartphone crawler.

What the label means

"Redirect error" does not mean "this URL redirects". It means Google's last visit to that URL ended somewhere unexpected, or followed a chain it did not want to follow. The report shows the date of that visit, which matters: if you fixed the issue afterwards, the row is a historical record, not a current fault.

That distinction cost me a week. I was validating a fix that had never been crawled, and the validation stayed pending because there was nothing new to read.

How to reproduce it in a terminal

Send a mobile user agent to the URL and look at the status line and Location header:

curl -sI -A "Mozilla/5.0 (Linux; Android 13) Chrome/125 Mobile" \ https://example.com/some-post.html

On my Blogger site this returned:

HTTP/2 301 location: https://www.example.com/some-post.html

Follow that and the second hop was:

HTTP/2 302 location: /some-post.html?m=1

Two things were wrong at once. The apex to www redirect happened on every request because the origin was reached over the naked domain, and Blogger then answered with a 302 to its ?m=1 mobile variant. A crawler sees a redirect chain ending on a URL it did not ask for, and it records friction.

Why this matters more than it looks

The redirect itself is not fatal. What matters is the cost. Every crawler visit spent on a three-hop chain is a visit not spent discovering new content. On a small site with roughly one crawl request per day, friction is not an annoyance, it is the whole budget.

The fix without touching the origin

Blogger's current UI no longer exposes a mobile template setting, and the origin will keep answering with ?m=1 for mobile user agents. If you run Cloudflare in front, you can normalise the request before it reaches origin:

  1. Redirect http:// and naked-domain requests to https://www. in a single hop.
  2. Rewrite crawler user agents to the desktop agent before origin fetch, so origin answers 200 with no mobile redirect.
  3. Catch any residual 3xx whose Location contains m=1 and turn it into a 301 to the canonical. 
const CRAWLERS = /Googlebot|AdsBot-Google|Mediapartners-Google|Google-InspectionTool|bingbot|PetalBot|Applebot/i; const DESKTOP = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125 Safari/537.36"; export default { async fetch(request) { const url = new URL(request.url); if (url.protocol === "http:" || url.hostname === "example.com") { url.protocol = "https:"; url.hostname = "www.example.com"; return Response.redirect(url.toString(), 301); } const ua = request.headers.get("user-agent") || ""; const headers = new Headers(request.headers); if (CRAWLERS.test(ua)) headers.set("user-agent", DESKTOP); const response = await fetch(new Request(request, { headers })); const location = response.headers.get("location"); if (location && location.includes("m=1")) { return new Response(null, { status: 301, headers: { location: url.toString() } }); } return response; } };

Verify after deploying

Run the same curl against four user agents: smartphone Googlebot, AdsBot-Google, Mediapartners-Google and bingbot. All four should return 200 with no Location header. Then confirm a real mobile browser still gets the normal behaviour, because you do not want to break the site for humans to please a crawler.

The numbers moved for me: redirect errors fell from 18 to 15 in the next Search Console refresh, and indexed pages went from 7 to 14 over the following weeks. The redirect was not the only reason, but it was the one defect entirely in my control.

Originally published on my diary: Google Search Console Says Redirect Error. Here Is What It Actually Means.