Redirects, Menus and Policies: The Shopify Store Data That Breaks Quietly

Most conversations about Shopify backups start with the catalog. Products, variants, collections, customers — the records that obviously represent money, and the ones a merchant would notice within hours if they went wrong.

But the data that causes the longest, quietest problems is usually somewhere else. It's the URL redirect table. The navigation menus. The policy pages in settings. The static pages that explain how shipping works. None of it shows up on a dashboard, nobody opens it on a normal week, and when it breaks, the store carries on looking completely healthy.

This post is about that second category: why it's unusually easy to lose, unusually hard to reconstruct, and what a backup actually changes about it.

The store data that doesn't announce itself

A broken product has an obvious symptom. The price is wrong, the image is missing, the variant is unavailable — and someone, eventually a customer, says so.

Configuration data fails differently. A redirect that disappears doesn't produce an error anywhere in your admin; it produces a 404 on a URL that used to work, for whoever happens to follow an old link. A menu item pointing at the wrong collection doesn't look broken, it looks intentional. A policy page overwritten during a theme migration reads as if that's what you meant to say.

There's no alert for any of this, because from Shopify's point of view nothing went wrong. The data is exactly what the admin says it is. The problem is only that it isn't what it used to be, and nothing in the store remembers what it used to be.

Redirects: the quietest thing you can break

URL redirects accumulate over the life of a store. Products get renamed and retired. Collections get restructured. A site migration maps hundreds of old paths onto new ones. Each of those decisions ends up as a row in a table that almost nobody looks at again.

That table is doing real work. It keeps old links — from search results, newsletters, marketplace listings, printed inserts, other people's blog posts — landing on pages that exist. When rows go missing, nothing in the store changes. The pages are still there. Only the paths to them are gone, and the people following those paths are the ones least likely to tell you about it.

Redirects are also the kind of data that's genuinely hard to rebuild from memory. A product list you can re-derive from your own records. A redirect table encodes years of historical URLs that, by definition, no longer appear anywhere in your store. If you don't have a copy of it, the information isn't somewhere else — it's gone.

Menus: structure that lives in exactly one place

Navigation menus are small, edited by hand, and routinely touched by more than one person. A seasonal campaign adds a top-level link. A theme change needs a menu restructured to fit. An agency tidies the footer. Each edit is reasonable on its own, and none of them leave a record of the arrangement they replaced.

The failure mode here is partial. Menus rarely vanish; they drift. A submenu loses three of its entries during a reshuffle. A link that used to point to a curated collection now points to a near-identical one. Nobody notices, because the menu still renders, still has links in it, and still looks like a menu — and the traffic that quietly stops flowing to the collection that fell off the list doesn't show up as an error anywhere.

Policies and pages: small text, real consequences

Refund, shipping, privacy and terms copy tends to be written once, carefully, and then left alone. That's exactly what makes it fragile. The people who wrote it may no longer be at the company, the wording may have been reviewed by someone outside it, and the reason a specific sentence is phrased the way it is may not be written down anywhere.

The same applies to static pages: the sizing guide, the care instructions, the about page, the FAQ that answers the question your support inbox used to get ten times a week. This is content with a long shelf life and no owner, which means an accidental overwrite can sit live for months without anyone realising the previous version was better, or more accurate, or the one legal signed off on.

Why a backup is the only copy that exists

For catalog data, you usually have alternatives. Exports, supplier feeds, your own spreadsheets, an app's own records. For store configuration, those alternatives mostly don't exist. There's no supplier feed for your footer menu. Nobody emails you a copy of your redirect table.

This is where backup coverage matters more than it first appears. Vaultkeep backs up products, pages, collections, customers, redirects, menus and policies — deliberately including the configuration layer, not just the commercial records, because the configuration layer is the part with no second copy.

Two things make that useful in practice:

• Version history. The question with quiet breakage is never just "what does this look like now" — it's "when was it still right". History turns a vague sense that something changed into a specific earlier state you can look at.
• Granular restore. When you find a redirect set or a menu that regressed, you want that resource back and nothing else. Rolling an entire store back to last month to recover one footer menu creates a bigger problem than it solves.

Daily backups matter here for a particular reason: you will almost never discover this class of problem on the day it happens. By the time anyone notices a missing redirect, the change could be weeks old. A history that only reaches back a few days can't help with a problem that surfaces slowly.

Where backups stop

Worth being plain about the boundary. Orders, draft orders and abandoned checkouts are captured in your backups, so you retain a record of them — but they can't be restored, because Shopify's API exposes no way to recreate an order once it's gone. That's a platform limit, not a product gap, and we'd rather state it than let it surprise someone mid-incident.

The restorable surface is the part of the store people edit by hand: catalog, content and configuration. Which is, conveniently, exactly where quiet breakage happens.

A short check worth running

None of this needs a project. If you want to know where you stand, three things are enough:

1. Open your redirect table and your menus. Just look. Does the structure match what you'd describe if someone asked how the store is organised?
2. Check that your backup history covers them. Not only products — confirm redirects, menus, pages and policies are in the snapshots too.
3. Confirm how far back the history reaches. Then ask whether a change made before that point would still be recoverable. For slow-surfacing problems, depth matters more than frequency.

Ten minutes, and you'll know whether the invisible half of your store is actually covered.

The point

Backups get justified with dramatic scenarios — the bad import, the rogue app, the catastrophic bulk edit. Those happen. But the more common use of a restore is undramatic: something small drifted a while ago, you've just noticed, and you'd like it back the way it was.

That only works if the thing that drifted was being backed up, and if the history goes back far enough to reach a version that was still correct.

If you'd like help setting up daily Shopify backups with version history and granular restore across your catalog, content and configuration, get in touch — we'll look at your store with you.