September 2, 2026

Shopify Archive vs. Delete: What Actually Happens to the Product URL

Published September 2, 2026 by Adot Technologies Inc, the team behind Arvio. The numbers below come from reading the public /products.json catalog and sitemap.xml of 39 live Shopify stores twice — on August 26 and September 1, 2026 — and then requesting every product URL that had disappeared in between.

The help-page answer takes one sentence: archiving keeps the product and its history in your admin, deleting removes it permanently. That sentence is true, and it doesn't tell you the thing you actually wanted to know — what a shopper with a bookmark, or Googlebot with a stored URL, gets when it hits /products/that-handle tomorrow morning.

So we went and looked at 47 of them.

Archive and delete look identical from the outside

Which means the decision has to be made in the admin, product by product, before it becomes a dead URL. Arvio reads your catalogue and proposes what to do with each removed product.

See Arvio on the Shopify App Store →

Check one of your own URLs before reading further

Take a product you removed recently. Paste this, with your domain and handle:

curl -sL -o /dev/null \
  -w '%{http_code}  %{num_redirects} hop(s)  %{url_effective}\n' \
  'https://yourstore.com/products/a-handle-you-removed'

One line comes back with three fields: the final status code, how many redirects it passed through, and where it ended up. We recorded those same three fields for all 47 URLs, so you can put your own store straight into this table:

What the line prints	What the outside world sees	How many of our 47
`404`, ending at the same `/products/<handle>` path you typed	dead end — bookmark, backlink and indexed URL all terminate here	35
`200` at a different handle	a 301 carries the old address to a live page	11
`404` at a different handle	a redirect that points at something itself removed	1

Read the status code and the final URL. Ignore the hop count: of the 36 dead ends, 27 printed 1 redirect, 8 printed 0, and one printed 2 — that last one is the 301-into-a-404 described below. The 1 versus 0 is just yourstore.com → www.yourstore.com. It says nothing about the product.

If your line ends in 404, archiving rather than deleting changed nothing about it.

What the 47 removed products returned

We pulled the public catalog of 39 comparable stores on August 26 and again on September 1, 2026, and diffed the handle lists. Seven of the 39 stores lost at least one handle in that six-day window, 47 handles in total, and we requested every one of them. (The per-store probe cap was 40; the largest single loss was 32, so nothing was left unchecked.)

Thirty-six of the 47 ended at a 404 (76.6%). Eleven resolved with a 200 at a different product URL.

Read that ratio at the URL level only, because it isn't a store-level one: 32 of the 47 removed handles came from a single store, so one merchant's habit is most of the percentage. The store column is the sturdier number — five of the seven stores that removed anything had no redirect on any of it.

All eleven redirects belong to two of the seven stores. One of them — the store that removed 32 products, two-thirds of everything in this sample — accounts for ten. The other had exactly one removed product, and redirected it. The remaining five stores removed 14 products between them, and all 14 return 404.

Two stores had the redirect habit; five didn't. That split is what a crawler can observe.

Five operations, one identical footprint

A handle vanishing from /products.json can mean the merchant archived the product, deleted it, set it to draft, unpublished it from the online store channel, or renamed its handle. Those five operations are indistinguishable from outside the admin. We can't tell you which of the 47 were archived and which were deleted.

Neither can Google. Neither can the customer who saved the link, the blogger who cited it, or the affiliate whose banner still points at it. The admin-side difference between archive and delete is real and documented — archive is recoverable, delete is not — and it lives entirely inside your admin. Outside it, the two choices produce the same artifact: a URL that is no longer backed by a live product. What that URL then returns is decided by whether a redirect exists, which is a separate action.

That's why the archive-vs-delete framing sends people to the wrong control. You can archive a product with great care and still hand every inbound link a 404, which is what 36 of the 47 URLs do.

The two redirecting stores show the other pattern. Here's what one of that store's chains does:

/products/product_7b274402-6e71-106a-7c77-645cd7d61772
  → 301 → www host  → 301 → /products/engraved-crescent-african-dangle-earrings-…  (200)

That's a handle cleanup — an auto-generated identifier replaced with a descriptive one — and the old address still works. Six of that store's ten redirects look like this; the other four rename one descriptive handle to another.

One URL in the sample shows what happens when the destination itself goes away. The handle authentic-african-yellow-beaded-ethnic-choker-pendant-necklace-copy returns a 301 to another choker handle at the same store — and that handle returns 404. (Three sibling handles at that store differ only in a word or a -1, and those return a plain 404 with no redirect, so the exact string matters if you go looking.) The redirect was set. The thing it pointed at was removed later. From outside, the result is the same dead end as having no redirect at all, which is why the last step below is to request the URL after you build the redirect.

The sitemap warning we could not reproduce

The standard advice says a removed product can linger in your sitemap and keep feeding Google a dead URL. We checked, on the same 39 stores, on the same day.

All 39 stores returned a sitemap. Across the sample they list 20,673 product URLs against 20,659 products in the live catalogs — a gap of 14 in aggregate. Broken out per store, 37 of the 38 stores whose sitemaps we could read in full had zero stale entries, where stale means "listed in the sitemap, absent from the live catalog." (The 39th, lejardinperdu.fr, had one shard that wouldn't fetch; a missing shard can only under-count stale entries, so we left it out of that denominator rather than counting its zero.)

The one exception is a single store: 30 of its 60 sitemap product URLs, exactly half, point at handles that are no longer in its catalog. We requested eight of those 30 — the sitemap probe cap was eight per store — and all eight returned 200 at a different live URL — Spanish handles redirecting to English ones. That store rebuilt its handles and kept the redirects. We didn't request the other 22, so we can't tell you what they return.

All 47 removed products from the other dataset were already gone from their store's sitemap by the time we checked.

The sitemap is being maintained for you. The redirect is not.

The reverse gap exists too and is small: 16 live products across three stores were missing from their sitemaps (13 of them at one store), which is the opposite problem, and not one this post went after.

You have the footprint. The catalogue still has to be gone through

Arvio reads your live products, groups the ones you have stopped selling, and drafts the disposition for each — archive, redirect, leave — for your approval.

Install Arvio on the Shopify App Store →

What to do with a catalog you have been pruning

The decision order that follows from the above:

Ask whether the URL has anything pointing at it. Indexed in Google, linked from a blog or forum post, sitting in an old campaign, saved by a customer. If yes, it needs a destination.
Set the 301 first, from the old handle to the closest live page — the replacement product if there is one, otherwise the collection it belonged to. Shopify's admin has a URL redirect tool for exactly this, under Online Store → Navigation → URL Redirects; Shopify's own page for it opens with the case you're in: "if you delete a product, then you can set up a URL redirect so that when customers enter the URL for that product, they're redirected to a similar product on your store." This step is independent of archiving and deleting. 36 of the 47 had no redirect in place.
Then choose archive or delete on the merits inside your admin: whether you might restock it, whether you want it out of your product list. That's bookkeeping, and Shopify's own documentation is the right source for it.
Verify with the curl line above. A redirect you created but that points at a page you later removed is a 301 into a 404 — one of our 47 is exactly that — and the only way to know is to request it.

To build the list for a catalog you've already been pruning, dump your live handles and diff them against an older export:

for p in 1 2 3 4 5 6; do
  curl -s "https://yourstore.com/products.json?page=$p" \
  | python3 -c 'import sys,json;[print(x["handle"]) for x in json.load(sys.stdin)["products"]]'
done > live_handles.txt

Keep raising the page numbers until a page comes back empty. Then run the check on each removed handle:

while read h; do
  printf '%s  ' "$h"
  curl -sL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' \
    "https://yourstore.com/products/$h"
done < removed_handles.txt

That's the whole audit. Typing the redirects into the admin afterwards, one at a time, is the part that doesn't get done — and 36 of the 47 have no redirect in place.

How this was measured

Sampling frame. Stores that posted themselves in the Shopify Community "Store Feedback" board — 230 of them — drawn down with random.Random(20260826).sample(stores, 60), then filtered to remove stores whose catalog hit our pagination limit, stores with fewer than 10 products, and stores we could not fetch. That leaves 39 comparable stores. This is a convenience sample of merchants who volunteered their storefronts for critique, not a random sample of Shopify. It is not our own customer base.

Store names withheld. These merchants posted their storefronts on a public board asking for design feedback. That isn't consent to be named in a vendor's post as an example of something done badly, so the counts here carry no domains. Product handles are kept because they are the technical evidence and carry no store name.

Window. Two catalog snapshots six days apart, August 26 and September 1, 2026. Six days is short. A store that removes products in monthly batches may show zero movement here.

Exclusions. Two stores returned zero products on September 1 and were dropped from both datasets — a catalog endpoint returning nothing is not evidence that a merchant archived their entire store.

Caps. Up to 40 removed handles probed per store (the largest loss was 32, so all 47 were requested) and up to 8 stale sitemap URLs probed per store (which is why 8 of that store's 30 were checked, not all 30).

Hop counting. Our raw files record the number of requests in a chain; the %{num_redirects} field printed by the curl line above is one less than that. Every hop count in this post is the curl number, so you can compare yours directly.

Probe re-run. The first pass of the URL probe joined relative Location headers against a normalised host, which added a phantom hop to every example.com → www.example.com chain and pushed one URL past the follow limit, where it was recorded as a redirect loop. It isn't one. The probe was fixed and re-run on September 2, 2026, and every number in this post comes from that re-run. Here is what each pass said, so you can see which way the corrections moved: the first pass read 36 dead ends, 10 redirects and 1 apparent loop; the re-run read 32, 8 and 7 outright failures; after re-requesting those 7, 36 and 11. The 7 failures were 6-consecutive within one store's queue plus one elsewhere, which is the signature of a network or rate-limit problem rather than a property of those products, and re-requesting them one at a time at a slower rate returned a definite result for all 7 (four 404s, three redirects to a live page). The correction that mattered most went against the headline: the loop disappeared, and the dead-end count went up, not down.

Sitemap re-fetch. On the first sitemap pass, 8 of the 39 stores recorded no readable sitemap. Those 8 fell in one unbroken run of the alphabetical store order, which is the signature of a network or rate-limit problem rather than a property of eight unrelated stores. We re-ran those 8 on September 2, 2026: every one returned a sitemap, and every one had zero stale entries. The sitemap figures above are the post-repair reading. Had we published the first pass, the denominator would have been 31.

Endpoint limits. Both /products.json and sitemap.xml reflect only products published to the online store channel. Sitemaps are cached, so a stale entry may be one that hasn't refreshed yet rather than one that has sat there for weeks; this snapshot can't say how long anything has been listed.

We are Adot Technologies Inc, and Arvio is our Shopify app. This measurement came out of the work we do on the unglamorous end of running a catalog: arvio.a.xyz/free

Arvio: AI Store Operator — install it on the Shopify App Store. It goes through the catalogue you have stopped looking at.