"Redirect error" on Shopify: Googlebot follows ten redirects, Merchant Center allows two

Short answer. Redirect error means Googlebot never reached a page at all: Google's four documented causes are a loop, a chain that was too long, a URL that grew past the maximum length, and a bad or empty URL in the chain. Googlebot follows up to ten hops. Merchant Center disapproves a landing page after two, and on all sixteen storefronts measured for this article an http:// link to the non-primary host already cost exactly two.

A redirect is the one piece of store plumbing that is supposed to be invisible. You change a product handle, you point the old address at the new one, and the link in someone's newsletter from 2023 still works. Nothing about that is controversial, and nothing in Shopify admin suggests there is a limit to how many times you can do it.

There is a limit. In fact there are two, they belong to two different Google systems reading the same URL, and they are five times apart. Only one of them will ever send you a report.

What the status means, and the harmless one beside it

In Search Console's Page indexing report, Redirect error is not a description of a redirect you should not have made. It means the crawl ended without a page. Google's report documentation lists exactly four ways that happens: "A redirect chain that was too long. A redirect loop. A redirect URL that eventually exceeded the max URL length. A bad or empty URL in the redirect chain."

Every one of those is a chain that failed as a mechanism. None of them is about where the redirect was pointing. That matters because the status sitting a few rows away in the same report, Page with redirect, is about exactly that, and it is benign: Google defines it as "This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed." The URL is not indexed because the destination is indexed instead. That is the system working.

The two labels sit a row apart in the same report and describe opposite situations, so the cost of reading one as the other runs in both directions. Read Page with redirect as a problem and you will spend an afternoon removing redirects that were doing their job. Read Redirect error as a cosmetic duplicate-URL notice and you leave a URL that Google cannot resolve at all. If you want the whole set of labels in one place, the Page indexing report statuses are mapped out separately, and the full map of ways a Shopify product leaves Google puts this one in context.

Two systems, two ceilings: ten hops and two

Googlebot is generous. Google's HTTP status codes documentation states it plainly: "By default, Google's crawlers follow up to 10 redirect hops." The same page says that "Any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead." A three-hop chain on a product page is, from Search Console's point of view, a non-event. It will not appear under Redirect error, because none of the four causes applies, and the destination will be indexed.

Merchant Center reads the same URL against a different number. Its documentation for an unavailable landing page lists "Too many redirects: Your landing page redirects too many times" among five causes, and gives the threshold: "To fix this error, ensure your landing page URL doesn't have more than 2 redirects." The link attribute specification adds the softer version of the same instruction, "Use as few redirects as possible. Redirects increase the time between a user clicking on your product and loading your landing page", plus a line that turns out to be load-bearing on a multi-domain store: "Ensure all redirects are set to the same verified domain to prevent errors."

So the band between three and ten hops is a blind spot by construction. A product URL in it is healthy in Search Console and disapproved in Merchant Center. The system with the tighter rule is the one that stops showing your product, and it writes nothing into the Page indexing report at all: the two systems do not share a surface, so there is no screen on which the stricter verdict and the looser one appear side by side.

Where the hops come from: sixteen storefronts, measured

On 3 October 2026 we took sixteen live storefronts that identify themselves as Shopify-served, and followed redirects by hand with a Googlebot user agent: no automatic following, one request per hop, reading the status line and the Location header each time. That is 128 chains followed from 128 starting addresses, 64 of them on the root address and 64 on a product page. The handle for each product came from the store's own public catalogue rather than from a link we chose.

The root addresses produced the same answer on all sixteen stores, with no exceptions:

• https:// on the primary host: 0 hops.
• https:// on the other host, apex or www: 1 hop.
• http:// on the primary host: 1 hop.
• http:// on the other host: 2 hops, which is Merchant Center's documented ceiling, reached before any redirect rule, app or market setting is involved at all.

Seven of the sixteen served the apex as primary and nine served www, so there is no single shape to memorise: the hop belongs to whichever host is not yours. The product pages behaved the same way. Of the sixteen, fifteen resolved in zero hops on the primary host over https, one hop on the other host, and two hops over http on the other host. Sixteen of the 64 product requests sat exactly at two hops.

One store accounted for every exception, and it is the interesting one. The product handle published in its own catalogue answered with a 301 to a different handle plus a query string, on the primary host, over https. That extra hop pushed the same product to three hops from the http:// non-primary address, over Merchant Center's limit, on a store that is live and serving the product normally. We are not claiming that store is disapproved: our requests came from a datacentre address and Google crawls from ranges it publishes, so what the measurement shows is the hop count of a URL shape, not what Google did with it. But the URL shape is the thing a feed submits.

Two further results are worth recording because they contradict reasonable assumptions. First, of the 126 redirect responses returned across those 128 chains, every single one was a 301; we saw no 302, 307 or 308 anywhere. Google's status-code documentation grades a 301 as a "strong" canonicalisation signal and a 302 as a "weak" one, so on these stores each hop is not merely latency, it is a permanent instruction about which URL is the real one. Second, we asked for the collection-scoped form of each product URL, using /collections/all/products/handle: on eleven of the sixteen it answered with a 301 to the clean product address, costing a hop; three served it directly with a 200; and two returned a 404, because all is not a collection that exists on those stores. Be careful how far you take that: we constructed those URLs rather than following a link a theme emitted, and a product's real collection-scoped URL is a different address which an earlier probe of ours found served directly with a canonical tag rather than redirected. What the result establishes is narrower and still useful — on most of these stores a collection-scoped product address is not simply an alias, it is a redirect, so it is worth checking which form your own internal links and your feed actually use. Which of those URLs Google then chooses to index is a separate question, covered in the user-declared versus Google-selected canonical piece.

Why a chain grows and almost never shrinks

Here is the part that explains the accumulation, and it is two sentences from two Shopify help pages that do not reference each other.

The page where you change a product's address says that "When you create a new product, a URL and handle are automatically generated" and warns that "You can edit the handle to make it match your product title, but don't edit it too often or the product might not display in search engine results." It does not mention URL redirects. The page about redirects states the constraint that decides everything else: "You can redirect only from broken URLs. Broken URLs display error messages, such as Page not found or 404, on a page or in the page title. If the URL still loads a valid webpage, then the URL redirect won't work."

Read those together and the arithmetic is one-directional. A handle change breaks the old address, so you can redirect it, and the chain gets one link longer. But the first URL of an existing chain is not broken: it loads, by redirecting. So you cannot shorten a chain by adding a rule at the front of it: that is the edit the screen appears to invite, and per the sentence above it will not take effect. Shortening it means going back into the existing rules, the domain settings and the app that added a hop, and removing links rather than adding a shortcut.

The same constraint is why deleting a product and redirecting its address is a decision you only get to make once per URL, and why a deleted Shopify product can keep showing up on Google long after the redirect is in place.

That same redirect page also records the ceiling that is never the problem: "You can create a maximum of 100,000 URL redirects unless your store is on the Plus plan, which has a maximum of 20,000,000 URL redirects." You will not hit that. What it does not discuss, anywhere, is a redirect whose destination is another redirect, or a loop. Nor is there a column on that screen for the depth of a chain, which is the practical point: the admin can show you every rule you created and still not show you the thing both Google systems are counting. Shopify's own sitemap behaviour has the same property: the platform is doing something reasonable and telling you nothing about it.

How to count the hops on your own product URLs

This takes about five minutes and needs nothing installed.

1. Take the URL from the system that complained. The example URL under Redirect error in the Page indexing report, or the product link in Merchant Center's Needs attention tab. Not one you type, and not one you click from your own storefront: the hop count is a property of the address you start from, and those are different addresses.
2. Follow the chain one hop at a time. Request the URL without automatic redirect following, read the status line and the Location header, then request that Location, and repeat until something answers 200. Count the 3xx responses. A browser will not help here: it collapses the chain and shows you the destination, which is the one thing you already knew.
3. Compare against both ceilings. Ten for Googlebot, two for Merchant Center. Three hops means you are fine in one system and failing in the other.
4. Test the four URL shapes. Primary host over https, other host over https, then both again over http. If your feed, your ads or your old backlinks use the fourth shape, you are starting at the ceiling.
5. Check whether the hostname changes. A hop that moves you to a different host is a domain or market rule, not a product rule, and it is configured on a different screen from your redirect list.
6. Read your redirect list for rules pointing at rules. Shopify admin, then Content, then Menus, then URL redirects. A rule whose destination is another rule's source is one chain, and each handle change lengthens it.
7. Remove hops, then note the date. Point the feed and the internal links at the final address directly. Write down when you did it, so that if it recurs you can line the recurrence up against your own change log.

The causes, and which one is yours

Ordered by how quickly you can rule each one out rather than by how often it happens, because the number of hops in a chain is not something we can measure from the outside across a population of stores.

• The submitted address is not the address you serve. Cheapest to check, because it needs no store knowledge at all: compare the scheme and the host in your feed against the host that answers 200 with no redirect. This is the two-free-hops case from the measurement above, and the fix is in the feed or the link, not on the store.
• Two redirect rules in a row. A handle changed twice, or a migration rule and a later tidy-up rule, each individually correct. Visible only by reading the destination of one rule against the source of another.
• A market, locale or country rule on top of a redirect rule. This is the case that changes the hostname mid-chain. One of the sixteen stores sent product URLs from its apex to an entirely different subdomain, which is a perfectly ordinary market configuration and also a hop that no redirect list mentions.
• An app that redirects product URLs. Out-of-stock handling, A/B tests, link shorteners and geolocation apps all add hops, and none of them writes into the URL redirects screen. When such an app points a live product somewhere else entirely, the symptom is different and more severe, and it is covered in the product page that redirects to the homepage.
• A loop. Two systems each certain they own the destination, for instance a redirect rule in admin pointing one way and a market or app rule pointing back. This is the one that genuinely produces Redirect error, and it is also the only cause on this list that a browser will tell you about, because it fails for shoppers too.

If your product URLs resolve in one hop and the report still flags them, the failure is upstream of the redirect: the request is not arriving in a usable state. That is a different investigation, and three pieces cover its branches, depending on what came back instead of a page: the product page unavailable piece for the reachability side, Server error (5xx) for a response Googlebot could not use, and blocked due to access forbidden (403) for a layer in front of the store refusing the request outright.

Why it comes back after you fix it

Nothing on this list is an outage, and nothing on it announces itself. A handle gets edited for a seasonal name. A second domain is bought and pointed at the store. A market is added for a country you started shipping to. An app is installed for a reason that has nothing to do with URLs and quietly inserts itself into the path. Each of those is a normal Tuesday, each adds a hop, and the hop is permanent because every one of the 126 redirects we observed was a 301.

The asymmetry is what makes it expensive rather than merely untidy. The system with the generous ceiling is the one that reports; the system with the strict ceiling is the one that stops showing the product. So a chain crosses the line that costs you listings while staying comfortably inside the line that would have told you. And because Redirect error only fires at the far end of the range, the report you are looking at is close to silent across the entire band where the damage happens.

There is also a delay built into noticing. Neither system re-checks on your schedule: the hop you added today is counted whenever that URL next comes up for a crawl, so the disapproval and the handle change can sit weeks apart. That gap is the same one that makes "Discovered - currently not indexed" so hard to read as a signal, and it is why lining a change log up against a date is more useful here than inspecting the page.

Counting the hops on one product URL, once, is a five-minute job. Counting them on every product URL, after every handle change and every app install, is a different kind of problem, and it is the one that decides whether this comes back on a store that already fixed it once.

Is this happening on your store right now?

Search Console will not page you when this happens. The product page loads fine in a browser, the sitemap looks clean, and Google quietly stops crawling or indexing it anyway. The only way to know is to check the pages the way Google sees them.

• 90+ checks, the way Google crawls and indexes your store. Noindex tags, canonicals, redirects, robots.txt, sitemap coverage.
• Read-only. No app to install, no admin access, nothing changes on your store.
• The exact fix for each page, in plain English, so you or your developer can act the same day.

Across full-catalog scans of more than 90,000 Shopify product pages, roughly 46% of stores had at least one critical Google visibility issue.

Scan my store for free

Free scan: issue types, counts and first fixes. Full report on every product page, not a sample: $49 once, no subscription.