Your Store Breaks Its Own URLs and Never Tells You

Somebody tidied up a collection last spring. "Mens Jackets" looked sloppy, so it became "Men's Winter Coats and Jackets," and while they were in there they fixed the URL to match. Every ranking that collection had earned, every blog post that ever linked to it, and the affiliate who had been sending steady traffic for two years were all pointing at /collections/mens-jackets. That address now serves your 404 page.

Nobody noticed. There was nothing to notice.

Editing a title is safe. Editing the handle is not.

Start here, because most merchants have this backwards.

Shopify builds the handle from the title exactly once, when you first create a product, collection, page or blog post. After that the two fields are independent. Rename a live product from "Blue Wool Scarf" to "Merino Wool Scarf, Navy" and the URL does not move. You can rewrite every title in your catalogue without breaking a single link.

The handle is a separate field, sitting in the search engine listing section of the same page, labelled URL and handle. Change that and the old address stops resolving the moment you hit save.

Shopify does try to help here. Edit a handle in the admin and it shows a checkbox offering to create a redirect from the old one, already ticked. Leave it alone, save, and the redirect appears under Content, URL redirects. The old address keeps working.

So the admin, used the ordinary way, is not where stores lose URLs.

Every other route skips the checkbox

The checkbox only exists in the admin form. Nothing else that writes a handle passes through it.

Change a handle through the Admin API and no redirect is created. There is no checkbox in a productUpdate mutation and Shopify does not infer one. It is a recurring question in Shopify's community forums, and the answer is always the same: create the redirect yourself, with a second API call. That covers bulk SEO apps, PIM syncs, ERP integrations, replatforming scripts, and whatever a developer wrote for you two years ago that nobody has opened since.

Bulk editing tools have the same gap, though the better ones will close it if you ask. Matrixify, for instance, documents how to auto-generate the redirects when you change handles in bulk. It is opt-in. Opt in.

Then there is deletion, which catches everyone. Delete a product and its URL 404s immediately. No prompt, no checkbox, no offer of a redirect, and no warning that your navigation menus still link to it. There is a standing request in Shopify's community asking for that prompt to be added to the deletion dialog. Until it is, every discontinued line you clear out of the catalogue takes its URL down with it.

Setting a product to Draft, or unpublishing it from the Online Store sales channel, does the same thing more quietly. The product still exists in your admin. Its URL does not.

The loss never shows up in a report you read

A dead product URL does not produce a bad number anywhere. It produces no number at all.

Your revenue dashboard compares what you sold against what you sold last month. It has no column for orders that would have happened. Sessions do not spike, because there is no session: the visitor hit a 404 from a Google result and left. No abandoned cart, no exit page worth investigating, no error anywhere in the admin. The whole thing surfaces months later as a slow, unattributable softening in organic traffic that gets blamed on an algorithm update.

Your sitemap is the only record of what used to exist

Shopify generates your sitemap automatically at /sitemap.xml and updates it "automatically when you add a new webpage, product, collection, image, or blog post," according to Shopify's own documentation. The root file is an index. The real lists sit in child sitemaps for products, collections, blogs and pages.

The sitemap only ever shows what is live right now. That is the frustrating part, and also the useful one. It has no memory, so give it one.

Save a copy of each child sitemap every week. A cron job or a folder in Dropbox, it does not matter which. Then diff this week's product sitemap against last week's. Anything present in the old file and missing from the new one is a URL your store no longer serves. Some of those disappearances are deliberate. Some are the collection somebody tidied up. You cannot tell which is which until you look.

If you have never done this, you do not have last week's file. Try the Wayback Machine. It archives sitemap.xml for plenty of stores, and one snapshot from a year ago is worth more than a month of diligent record-keeping starting today.

Search Console tells you which ones mattered

The sitemap diff tells you what vanished. It does not tell you what it was worth.

For that, open the Page indexing report in Search Console and look at the Not found (404) status. Google is relaxed about this by default: "404 responses are not necessarily a problem, if the page has been removed without any replacement," and the documentation advises concentrating on the 404s you link to yourself or list in your sitemap.

Then cross-reference. Take the dead URLs and check them against the Performance report to see which were bringing clicks before they died. That list is almost always much shorter than the raw 404 count, and it is the actual work. The rest can wait, or stay dead.

Send each one to the closest thing that still exists

Shopify's built-in URL redirects are 301s, which is the right status code. Google is explicit about why it matters: with a permanent redirect, "the indexing pipeline uses the redirect as a signal that the redirect target should be canonical," while with a temporary 302 the pipeline "doesn't use the redirect as a signal." If you are doing anything custom at the theme or DNS level, confirm you are not quietly issuing 302s.

After that, a few rules that are easy to get wrong.

• Do not send everything to the homepage. It is tempting and it is one line of CSV, but Google's site move guidance is blunt: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error." You spend the redirect and get nothing back for it.
• Point at the real equivalent instead: the replacement product, the variant that superseded it, or failing that the collection it belonged to. Relevance is what carries the signal across.
• If there is no equivalent, let it 404. A clean 404 on a product that is actually gone is a correct answer, and Google says as much.
• Do not build chains. Googlebot will follow up to 10 hops, but the advice is to redirect "to the final destination directly," and where that is impossible to keep the chain "ideally no more than 3 and fewer than 5." Shopify will happily let you point A at B in March and B at C in September. Go back and repoint A at C.
• Leave them in place once created. Google recommends keeping redirects "for as long as possible, generally at least 1 year," which is roughly what it takes to transfer all the signals.

On that last point, set your expectations properly. The same documentation notes that a small to medium site "can take a few weeks for most pages to move." Fix a redirect today and you are not getting the ranking back on Friday.

A backlog is a CSV job

If your diff turns up two hundred dead URLs, do not create them one at a time in the admin. Go to Content, then Menus, then URL redirects, and use Import.

The file needs two columns, headed exactly Redirect from and Redirect to. Use paths, not full URLs: /products/old-thing, not https://yourstore.com/products/old-thing. Shopify offers a sample CSV to copy the shape from.

You have room to work with. Shopify allows "a maximum of 100,000 URL redirects unless your store is on the Plus plan, which has a maximum of 20,000,000," per the help centre. Nobody hits that ceiling by accident.

The fix that holds is the one nobody has to remember

Everything above is cleanup, and cleanup has a half-life. You will do it once, feel good about it, and four months later an app will rewrite eighty handles overnight while you are asleep.

The gap worth closing is the one between the moment a handle changes and the moment a redirect exists. In the admin that gap is zero, because of the checkbox. Everywhere else it is however long it takes a human to notice. If you have a developer, the fix is genuinely small: subscribe to the products/update and collections/update webhooks, compare the incoming handle against the one you stored last, and when they differ, create the redirect through the API before anyone can hit the old address. If you do not have a developer, use an app that does it for you, and check before you trust it that it covers deletions and not just renames. Those are two different jobs.

Seokai does both of them, and it is worth saying how, because the two halves work differently. Renames it closes at the source: turn the toggle on and the redirect is created the moment a handle changes on a product, collection or page. Deletions it cannot pre-empt, because nothing announces those in advance. So it does the other thing this post has been arguing for and gives the sitemap a memory, keeping last week's URL set, comparing, and listing what has stopped resolving since with the redirect one click away.

The handle is the one field in your admin where a careless edit is permanently expensive. It looks like metadata. It is an address, and other people's links, bookmarks and rankings are all written against it. Treat it the way you treat a price. Nobody changes it in passing, and every change leaves a record.