Shopify redirects: the one rule that decides whether yours will work

Published September 3, 2026 by Adot Technologies Inc, the team behind Arvio: AI Store Operator. The measurements below come from requesting nine URL shapes against 20 live Shopify storefronts on September 3, 2026, and from Shopify's own redirect documentation read the same day.

There is a particular kind of Shopify thread that never gets resolved. Someone set up a URL redirect, saved it, tested it, and nothing happened. No error. The old URL still loads. They check the spelling four times, clear the cache, ask the forum, and the thread dies.

In these threads there is one rule worth ruling out first, and it is stated plainly in Shopify's documentation without ever being made prominent:

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 it twice, because it inverts the mental model most people bring. A redirect on Shopify is not a rule that overrides a page. It is a rule that fills a hole. If there is no hole, the rule never fires.

Which turns the useful question into one you can answer with a single request: is the URL I am pointing at actually broken? That turns out to be answerable, and the answer is not obvious.

Key takeaways

• Redirects only fire on URLs that already 404. A redirect whose source URL still loads does nothing — that is Shopify's own rule, and its troubleshooting list says as much: "Ensure the Redirect from URL doesn't have an active page." It is the first thing to check when a redirect appears to do nothing.
• The URL shapes people most want to redirect are not broken. An uppercase handle, a trailing slash, and a junk ?variant= parameter all returned 200 on all 20 stores we tested. They are duplicates, not holes, so a redirect will not touch them.
• What is handling those duplicates is the canonical tag, not a redirect — correctly, on 19 of the 20 stores. On the twentieth, the one product we read pointed its canonical at the store's home page instead — a real defect, and not one a redirect would fix. We read one product per store, so that is one page on one storefront, not a measured rate.
• The genuinely broken shapes are consistent. A missing product, a missing collection, and a valid handle requested under the wrong resource type each returned 404 on 20 of 20 stores. Those are the ones redirects are for.
• /collections/all/products/<handle> is the one Shopify collapses for you — 16 of 20 stores redirected it to the plain product URL. The other 4 served the product at the collection path, where the canonical still pointed at the plain product URL.
• Shopify's own page contradicts itself on international subfolders — it says both that redirects do not automatically apply to market subfolders and that they do. Test yours rather than trusting either sentence.

Redirects fix URLs. They do not fix the page you land on

A redirect decides where the visitor lands. What is on that page comes from your catalogue — descriptions, product type, metadata, images — and that half is what Arvio reads, drafts, and hands back for your approval.

Install Arvio on the Shopify App Store →

Which URLs on your store are actually broken?

We took the first product and the first collection each of 20 live Shopify storefronts lists, and requested nine URL shapes for each, following redirects and recording where each one landed. Every shape is one a merchant genuinely runs into — from a bad paste, an old link, a mistyped handle, or a theme that builds URLs a second way.

URL shape	200	404	Path changed	Redirectable?
/products/<handle> (control)	20	0	0	—
/collections/all/products/<handle>	20	0	16	No — it is a fixed Shopify path
/products/<handle>/ (trailing slash)	20	0	6	No — all 20 serve it
/products/<HANDLE> (uppercase)	20	0	0	No — all 20 serve it
/products/<handle>?variant=1 (junk variant)	20	0	0	No — all 20 serve it
/products/<handle>-typo (missing product)	0	20	0	Yes
/collections/<handle> (control)	20	0	0	—
/collections/<handle>-typo (missing collection)	0	20	0	Yes
/pages/<product-handle> (wrong resource type)	0	20	0	Yes

"Path changed" counts the final URL landing on a different path than the one requested, which is not the same as a store running a redirect for that shape. The trailing-slash row is where the difference matters: 14 of the 20 stores serve the slashed URL exactly as it stands, and the other 6 are the host-normalising stores described under Where this stops — their single 301 drops the slash while it moves the host. No store in the sample ran a slash-stripping redirect of its own.

Two things fall out of that table, plus one detail about the redirects themselves.

Every redirect in the run was a permanent one: 70 redirect hops in total, all 70 returning 301, including the 22 that changed the path rather than just normalising the host.

The 404s are clean. Every one of the three broken shapes returned an honest 404 on every store — no soft 404s, no "helpful" 200 landing pages, no silent bounce to the home page. That is good news, and it is the precondition for a redirect to work at all. If your platform returned 200 for missing products, redirects would never fire.

The other half of the table is the part that frustrates people: none of the duplicate shapes is broken, so none of them is within reach of a redirect. An uppercase handle returns the product. A trailing slash is served as-is on 14 of the 20 stores, and stripped with a 301 on the other 6 — either way the URL never 404s. A junk variant parameter returns the product on all 20. All three are the same page on a second URL, and because none of them is broken, there is nothing a redirect can do about them.

That is where a lot of frustration comes from. Someone sees the same product at two URLs, reasons "I'll redirect one to the other," writes the redirect, saves it, and the second URL keeps loading. It always will.

What is handling the duplicates instead

The canonical tag. On 19 of the 20 stores, the product page emits a <link rel="canonical"> pointing at the plain /products/<handle> URL — and it keeps pointing there on the uppercase version, the trailing-slash version, the collection-path version, and the version with the junk variant parameter. That is the mechanism telling search engines which URL is the real one, and on 19 of the 20 storefronts we read it was already in place — we changed nothing on those stores, and we did not look at how their themes were configured.

One store out of 20 is the exception, and it is worth naming as a shape rather than a domain: on the one product we read there, the canonical points at the store's home page — and it does that on all five shapes where we captured the tag. We read one product per store, so whether the rest of that catalogue does the same is something we did not test. What is safe to say is that a redirect is the wrong tool for it: that product URL loads fine, so there is no hole for a redirect to fill.

If you want to check yours, it is one request:

curl -s https://yourstore.com/products/some-handle | grep -i 'rel="canonical"'

You want to see that product's own URL come back. If you see the home page, or a different product, that is the thing to fix — before you spend an afternoon on redirects that were never the problem.

The one duplicate Shopify does collapse

/collections/all/products/<handle> — the URL a theme produces when a product link is built from inside a collection — behaved differently from the rest. 16 of the 20 stores redirected it to the plain /products/<handle> URL. The remaining 4 served the product at the collection path, with the canonical still pointing at the plain product URL.

You cannot manage that either way from the redirect tool. Shopify's documentation lists the paths that are off limits: "You can't redirect URLs that use fixed Shopify paths: /products, /collections, /collections/all." The platform handles this shape itself, and where it does not, the canonical covers it.

When you change a product handle

A handle change is what people reach for redirects for, and the same rule decides it: if the old URL returns 404 after the change, it is redirectable; if anything still serves it, no redirect you write will fire.

We did not test this. We created no redirects and changed nothing on any store, and Shopify's redirect page does not mention product handles at all — so do the one check that settles it on your own store. Change the handle on a low-stakes product, then curl -I the old URL. A 404 means you can create the redirect; a 200 means a redirect there would be a no-op no matter how you write it.

The same goes for a change that arrives through an import or an app rather than by hand: the question is never how the change was made, it is what the old URL returns now.

When you delete or hide something

Deleting a product produces a 404 at its URL. That is correct behaviour, and it is not automatically a problem — though whether to archive or delete in the first place is a decision worth making before you get here: a product that never had inbound links or traffic does not need a redirect, and an internet full of redirects to vaguely-related pages is not better than an honest 404.

Redirect when the old URL had something worth preserving — a link from somewhere, a page in the index, a run of traffic. Send it to the nearest genuinely equivalent page, which is usually the collection the product sat in rather than a random other product.

Hiding rather than deleting has a wrinkle that is easy to get bitten by, and it is documented: hiding a collection — or setting a product to Draft, or removing it from all sales channels — makes its URL return 404, which makes it eligible for a redirect — and then, per Shopify, "If you later change the collection's Online store visibility back to Visible, the URL redirect is automatically deleted because redirects only work for URLs that return 404 errors."

So a seasonal collection you hide each summer and redirect elsewhere will lose that redirect the moment you make it visible again. The redirect does not sit dormant. It is deleted, and you recreate it next season.

Creating them, one at a time and in bulk

From the admin, redirects live under Content → Menus → URL redirects. Creating one is: Create URL redirect, fill in Redirect from with the old (broken) URL and Redirect to with the destination, then Save redirect. To send something to the home page, the destination is just /.

Destinations inside your own store should be relative (/collections/t-shirts); a full URL is for sending traffic off your domain.

For a batch — a migration, a bulk delete, a taxonomy change — the same page has Import, which takes a CSV. Shopify provides a sample redirect CSV to use as a template; fill that in, then Import → Add File → Upload file → review → Import redirects. Shopify's stated ceilings are 100,000 redirects on standard plans and 20,000,000 on Plus, so the limit is not what will stop you.

What does stop people is further down the same page:

• Some prefixes cannot be the source of a redirect at all. Shopify's list is /apps, /application, /cart, /carts, /orders, /services, /shop, plus the fixed paths above.
• Collection tag-filter URLs are not redirectable — a URL like /collections/name/tag-name is considered valid even when no product carries that tag, so it never 404s.
• .html endings cannot be redirected to the same URL without .html. Shopify treats those as the same URL.
• Query strings are unreliable as redirect sources. The documentation says URLs containing them "might not work as expected."

The source really is a 404 and the redirect still does nothing

The rule at the top of this article answers one half of "my redirect isn't working" — the half where the old URL still loads. If your
source URL genuinely returns 404 and the redirect still does not fire, Shopify's own troubleshooting list has three more steps, and they
are the whole list:

• "Review both Redirect from and Redirect to URLs for any typos."
• "Ensure that the Redirect from URL isn't a fixed path or contains a prefix that you can't redirect." — this is the trap our own
  measurement walked into: /collections/all/products/<handle> 404s for nobody, and 16 of the 20 stores we read redirect it themselves.
  A fixed path is not yours to redirect even when it looks broken.
• "Clear your browser's cache and test the redirect again or try on another device."

Cache cuts the other way too, and it is the reason a redirect you deleted can appear to still work: "301 redirects are cached by
browsers and search engines. If you remove a redirect after customers have accessed it, then the redirect might continue to work in
their browsers until the cache expires." Test in a private window, or with curl -sIL, before concluding anything from your own
browser.

One thing this list does not include is waiting: Shopify's page says "URL redirects start working immediately." If it did not
work a minute after you saved it, more minutes are not the fix.

You have the redirects. Is the page they land on worth landing on?

A redirect moves a visitor to a page. What that page says comes from your catalogue — and Arvio reads your live catalogue, drafts the gaps, and applies nothing you have not approved.

Install Arvio on the Shopify App Store →

The documentation contradicts itself on international subfolders

If you sell into market subfolders — /en-ca, /en-fr — you need to know whether one redirect covers all of them. Shopify's page answers it twice, in opposite directions, in two different sections. Both were on the page when we read it on September 3, 2026.

In the considerations near the top:

URL redirects don't automatically apply to all market subfolders. If you need to redirect specific locales (such as yourstore.com/en-ca/old-page to yourstore.com/en-fr/new-page), then you must create individual redirects for each subfolder.

And in the section headed Redirects and subfolders, with a worked example that walks through a Canadian shopper being redirected inside /en-ca from a single redirect created at the root:

Creating a URL redirect applies to all language or market subfolders set up using international sales tools.

Neither sentence is dated, and we have no way to tell which one is current. So settle it on your own store: create one redirect at the root, then request the subfolder URL and see where you land. One curl -I per market takes a minute; re-reading the page takes longer and still leaves you with two answers.

Where this stops

• We did not create any redirects. Everything in the table is a read of what these stores already serve. The redirect behaviour described in the second half comes from Shopify's documentation, not from our own write test.
• The 301s above are what these stores did on the day. Every hop we recorded was one, but we sampled 20 storefronts on one morning — that is not a statement about how Shopify behaves in general.
• Six of the 20 stores redirect every request once at the host level — the usual www-to-apex or apex-to-www normalisation. A hop that only moves the host is not counted as a redirect in the table, because counting it would have made all nine shapes look like they redirect. Those same six stores are the 6 in the trailing-slash row, and the reason they are there is worth being exact about: on that shape their host hop and the dropped slash are one 301, not two, so the path genuinely changes — but no store in the sample ran a slash-stripping redirect of its own. On the collection-path shape the same six take two hops; the trailing slash costs them none.
• 20 stores is a small sample, and the frame behind it is biased toward stores that are still trading. It was built from 474 publicly posted store URLs, of which 244 no longer served a public catalogue and were dropped before the draw — so this describes storefronts that are alive today, not Shopify as a whole. Nothing here describes Shopify Plus stores behind a CDN, where a rule at the edge can change any of this.

How this was measured

The sample. A public frame of 230 live Shopify storefronts, built on August 26, 2026 from store URLs their owners posted publicly. Sixty hostnames were drawn from that frame with a recorded seed (random.Random(20260826).sample), and this article reads the first 20 of those 60 in alphabetical order. The cut to 20 was ours, not the data's: nine shapes per store at one request per second is 180 requests, and we capped the survey there. So the draw is random and the prefix is not — alphabetical order has nothing to do with anything measured here, but it is a convenience cut and you should read the counts as 20 stores, not as a random 20 of the 60. All 20 answered, so no store dropped out at this step.

The requests (September 3, 2026). For each store we read /products.json and /collections.json and took the first product handle and the first collection handle each one returned, then issued one GET per URL shape at one request per second with a user agent identifying our research crawler and carrying a contact address. We followed redirects and recorded the full hop chain, the final URL, the final status code, and — on five of the nine shapes — the <link rel="canonical"> href from the response body. On the other four we did not read the body at all, so their canonical count is zero because we did not look, not because the tag is absent.

"Redirected" means the path changed. Six stores normalise host or scheme on every request. Counting those as redirects would have reported all nine shapes as redirecting on those stores, which is true and useless, so the table counts only redirects where the URL path differs from the one requested.

Rerunning this on your own store takes one line per shape. We have not published the raw hop chains — they name 20 real storefronts — but nothing here needs our copy: curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' "https://yourstore.com/products/your-handle/" prints the same two facts we recorded (where it landed, and with what status), and the nine shapes are listed in the table above.

The uppercase and junk-variant shapes were fetched twice. The first pass did not read the response body for those two, so we refetched both the same day purely to capture the canonical tag. That refetch is recorded separately from the first pass, and the canonical counts in this article come from it for those two shapes only.

The documentation was read on the same day. help.shopify.com returns 403 to a plain scripted request, so the page was read through a normal logged-in browser session and the rendered text — 10,173 characters — was stored whole alongside the numbers. Every quoted sentence in this article is copied verbatim from that capture.

Exclusion rule. A store enters the table only if all of /products.json, /collections.json and the control product page answered. Stores that failed any of those would be absent from every count rather than counted as zeros. In this run the rule never fired: all 20 answered all three requests, so every row's denominator is the full 20.

FAQ

Why isn't my Shopify redirect working?
The first thing to rule out is that the URL you are redirecting from is not actually broken. Shopify's rule is that redirects only fire on URLs that return an error: "If the URL still loads a valid webpage, then the URL redirect won't work." Open the old URL in a private window. If it loads a page, the redirect will never run, and no amount of editing it will change that.

Can I redirect the uppercase version of a product URL to the lowercase one?
No. In our test all 20 stores returned 200 for the uppercase handle, which makes it a working URL and therefore not a redirect source. It is also not the problem it looks like: the page's canonical tag points at the lowercase URL on 19 of the 20 stores, which is the mechanism that resolves it for search engines.

If I change a product handle, do I need a redirect?
That depends on one thing: whether the old URL is broken afterwards. We did not test handle changes, and Shopify's redirect documentation does not mention them, so check rather than take anyone's word — curl -I the old URL after the change. A 404 means you can create the redirect. Anything that still serves a page means a redirect would never fire.

How many redirects can I have?
Shopify documents 100,000 on standard plans and 20,000,000 on Plus. In practice the constraints that bite are the ineligible prefixes and fixed paths, not the ceiling.

Do I need a redirect for every deleted product?
No. A 404 is a correct answer for a product that is genuinely gone and had nothing pointing at it. Spend redirects on URLs that had inbound links, index presence, or traffic, and send those to the nearest real equivalent — usually the collection, not an unrelated product.

Will one redirect cover my /en-ca storefront?
Shopify's documentation says both yes and no on the same page, so test it. Create the redirect at the root, then request the subfolder URL and see where you land. That takes a minute and beats either sentence.

Arvio: AI Store Operator — install it on the Shopify App Store. It reads your live catalogue and drafts the product fields that are missing.