Rebuilding an Online Store from the Wayback Machine: WooCommerce vs Shopify

An archived storefront gives you product pages, category pages, images, descriptions and the look of the checkout. It does not give you orders, customers, stock levels, payment credentials, shipping rules, the Liquid theme source or the collection rules behind a Shopify store. Rebuilding a store from the Wayback Machine is therefore two different jobs: reconstructing the public catalog and design from evidence, and configuring commerce operations fresh under the owner’s own accounts. This guide covers both, for WooCommerce and for Shopify, and ends with how to choose between them.

If a working native store or a usable full backup survives, repairing it is usually preferable to rebuilding from captures, and a closed Shopify store can sometimes simply be reopened; check that before anything else. For the general limits of the archive, see What the Wayback Machine Can and Cannot Recover. For post-launch link, canonical and sitemap checks, see After Website Restoration: The SEO and QA Checklist.

What the archive gives a store, and what it cannot

Public captures can support a product’s name, description, visible images, attribute labels and the category it was listed in on a given date. They cannot establish today’s stock, every variation that was actually sold, supplier cost, current price or anything that lived behind a login. Keep recovered information separate from current business decisions from the first day.

Start with a platform-neutral loss assessment. List what is lost: public descriptions, images, theme design, product records, orders, credentials or access. These are different recovery problems. A design rebuild cannot substitute for missing private history, and a product export does not restore checkout configuration. Then list what survives and its dates: native backups, CSV exports, media folders, theme source, owner documentation and public captures. Choose the destination platform after understanding these inputs, not before.

The aim is a usable, reviewable catalog rather than the largest possible product count. A smaller set of verified products is safer than a store filled with plausible descriptions, invented variation combinations and misleading availability. Our ecommerce website restoration and Shopify website restoration services are scoped on exactly that boundary: public storefront reconstruction on one side, private commerce data and fresh operational configuration on the other.

Rebuild the product catalog one field at a time

Give every product a source-backed identity, then recover each field against its own evidence. A clear product photo is not evidence for the specification table beside it, and a size selector is not evidence that every size was sold. Treat one good screenshot as support for the fields it actually shows.

Use authorized native exports first where they exist, because they retain structured data a storefront view does not expose, and preserve the original file unchanged with its date. Product names are poor identifiers: they change, different items share labels and the same item appears in several categories. Use a confirmed SKU or owner-held identifier where available; otherwise assign a provisional recovery reference and keep the original URL, source date and distinguishing details together. Do not convert that provisional reference into a claim that the original internal product ID was recovered. Public page identity, SKU and CMS record number are three separate things.

A product evidence card, kept in a spreadsheet without customer or payment data:

• Identity: verified identifier if any, original URL and working recovery reference.
• Field and value: the exact name, description, image association, attribute or category under review.
• Source and date: the export row, capture or supplied document supporting this value.
• Conflict or gap: another source disagrees, the text is cut off, or the value is not visible.
• Decision: recovered unchanged, owner-approved current replacement, or withheld pending review.
• Acceptance: the value appears on the intended product and the public result has been checked.

Preserve readable product facts and mark truncated specifications unresolved rather than finishing a sentence from what similar products usually say; dimensions, compatibility and warranty claims affect purchasing decisions. Trace each image to the intended product, model, color and variation, not to a nearby filename, and confirm reuse is authorized. Record owner-supplied replacement photos as replacements. Note that WooCommerce’s CSV importer expects images to be pre-uploaded or downloadable from their URLs and does not update alt text, so plan an image-description pass after import.

Categories and variations are relationships, not fields. A category capture shows which products were listed on that date but may be paginated or incomplete; combine it with each product’s recorded relationships rather than assigning everything to a broad category to make navigation look full. For variations, record each evidenced combination separately and request an export or owner confirmation where the public view does not resolve price, stock or image per combination. Historical price is dated evidence, not permission to sell: before any product becomes purchasable, the owner approves the current price, currency, availability and conditions. Do not infer stock from an old Add to cart button, and keep discontinued products out of the purchase path even where their URLs and content are worth preserving.

Work in batches: rebuild one representative category completely, review it with the owner, refine the process, then move on. Test a small import on staging first with a simple item, a variable item and a multi-category item, and read the skipped-row report rather than trusting the processed count. New products get new IDs, so keep an old-to-new map where relationships depend on them.

Preserve product and category URLs

Match each old address to the same product, variant or category meaning before choosing its destination. A valuable historical product link still fails if it opens the wrong item, loses the selected variation or lands on a generic homepage. Keep existing addresses wherever the platform supports them, and treat every exception as a documented, approved decision.

One product may be reachable through several category paths, tracking URLs and variant links, while similarly named products may be different items. Build a verified identity map first and attach every known URL to it. Record what each address meant: a product, a selected option, a collection, a filtered result or a paginated page. A color-specific link is not equivalent to the parent product’s default view, and a filtered category is not equivalent to the whole shop.

For each address, keep a commerce URL card: the old path with any meaningful parameter, its verified meaning, the dated source, the planned result (preserve, approved equivalent, historical page, or honestly unavailable), any verified platform constraint, and the acceptance check of response, page identity, selected state and canonical. Variant parameters need an explicit decision; a parameter preserved in the address bar but ignored by the rebuilt page has not preserved the experience. Separate parameters that change which items are shown from those that only change sort order, and avoid generating an uncontrolled number of thin pages from an old crawl.

In practice:

• Export the old address list from captures, old sitemaps and Search Console before building the new store.
• Compare it with the new platform’s URL rules; some add fixed prefixes for products or categories.
• Set slugs and handles to match wherever the platform allows.
• Redirect the rest one by one to the matching product or category, never en masse to the homepage.
• Test the full list of old addresses after launch and after every major change, and keep the spreadsheet as a living document.

Shopify is the main constraint to check early. Its product and collection paths carry fixed prefixes, some paths are reserved, redirects work only from URLs that no longer resolve, and filter and query-string behavior is limited. Do not promise exact preservation of every historical route on Shopify until the specific routes have been tested. On either platform watch for automatic slug changes when a title is edited, numbered duplicates for similar names, category paths embedded in product URLs, and case or trailing-slash differences. Discontinued products with a close replacement can redirect to it; otherwise the relevant category is more useful than a bare error, but do not send many unrelated products to one destination, which visitors and search engines both treat as a soft error.

Checkout: the design is recoverable, the transaction system is not

A captured checkout shows the old purchase interface. It cannot supply payment credentials, shipping rules, tax settings or order records. Rebuild checkout from today’s requirements, using the captures only for layout, wording and the order of steps customers were used to, and verify an approved purchase path in an isolated test environment.

Define the transaction before rebuilding its screen: which products may currently be sold, in which markets, through which payment providers and fulfilment arrangements, with what currency, tax treatment, shipping, stock, refund and notification rules. These decisions come from the owner and their advisers, not from page reconstruction, and credentials never belong in a scope document. Payment settings, keys and connections are created fresh in the provider’s dashboard by the account owner.

Five dependencies the design cannot verify: a purchasable catalog with approved current values; delivery calculation that offers the right options and charges per destination; payment processing that reports its outcome back to the store; order recording with correct items, totals and status and no duplicates; and operational follow-through across notifications, fulfilment, accounting and subscription integrations. Mark each as confirmed, awaiting owner input or awaiting authorized testing.

Test on staging only, using the gateway’s own test mode and published test card numbers. Test orders can still send emails, enter analytics, create shipping labels and synchronize stock, and connected extensions do not distinguish them from real orders, so identify every external effect before the first test and agree a cleanup process. Write each scenario down first: starting cart, destination, payment method, expected charge and expected final order state, for a successful purchase, a rejected payment, an unavailable destination or variation, and the return to the store afterwards. Compare the customer-facing confirmation with the recorded order and the sandbox transaction, because an attractive confirmation page can hide a failed payment callback.

Refund, shipping and privacy policies are linked from checkout and order emails, so the owner must confirm every term before publication; old policy pages guide structure only. Review order, shipping and refund emails for the business name, contact details and references to old processes, and read them on a phone. Switch to live mode only after the owner approves the results, then place one small real order to confirm. Hand over a short note describing which payment methods are active, where shipping and tax settings live, and who to contact when a payment fails.

Shopify: product content from exports versus archives

Recover Shopify product content from a genuine product export before turning to captures. The CSV preserves structured product and variant fields; the capture verifies visible wording and images. Neither is a store backup, and an unreviewed recovery spreadsheet should never be imported into a working catalog, because an update meant to restore one description can overwrite other values or alter variant relationships.

Retain the original export unchanged with its date and intended scope; an absent row may reflect export scope rather than a lost product. Match on handles and identifiers, not titles, and keep established handles where the URL plan depends on them. Identify which required fields survive, which are blank and which depend on information elsewhere. Then use captures to verify readable descriptions, specifications and images, keeping historical prices and stock statements as dated evidence pending approval, and separating a confirmed option from an inferred variation.

Shopify’s CSV rules shape the work. New-product rows and update rows have different requirements, dependent option columns matter, changing option values can replace variant IDs and break integrations, and variant metafields are not supported by the product CSV. Review the current schema rather than a remembered template, and do not delete columns to simplify the sheet without checking what depends on them. The optional Collection column is not included in exports and assigns only one collection, so a product export does not preserve collection membership; review collections separately from surviving admin data, owner lists and public collection captures, and identify the actual rule behind conditional collections rather than hand-assigning products until a page resembles a screenshot.

A controlled order of work: start from the latest export the owner has, compare it with captured product pages to find changed or missing content, update titles and descriptions from evidence with handles unchanged, re-upload images the owner holds with descriptive filenames and alt text, leave variants, prices and inventory untouched unless the owner supplies current values, and import a small batch first. Captured image URLs may still load from Shopify’s CDN but can disappear at any time, so download and keep approved images rather than relying on old links. After import, open a sample of products from different collections and compare each with its evidence, and keep the import file and a list of changed products so mistakes can be traced.

Shopify: rebuilding the theme from storefront evidence

Saved storefront HTML is rendered output. It does not contain the Liquid theme, its sections, settings or app dependencies. Look for a genuine theme copy first; if none survives, use captures as design references and describe the result as reconstruction, not recovery.

Ask the owner and any previous developer for a theme backup, repository or development package, then inspect it rather than assuming it contains everything the storefront used, and confirm license and reuse permission. If native code exists, selective repair may beat a new theme. If only rendered pages survive, map recurring components to editable theme parts: header, announcement bar, navigation, product and collection templates, cart, blog, standard pages and footer, recording for each a source capture, visible requirements, evidence gaps and where its content comes from. A product title belongs to the product record, a shared promotion to a section setting, and a review widget to an approved app, not a copied empty box.

Capture states, not just the first screen. A wide-screen capture does not establish mobile navigation, option selection, gallery behavior or cart entry points; where those are missing, agree a usable contemporary implementation and document it as new. Do not copy a broken replay state into the new store because it was visible. App-generated areas are separate dependencies: captured rating stars do not recover review records, and a subscription selector does not recover subscription contracts.

Rebuild section by section, shared parts first, and put colors, fonts and spacing in theme settings rather than hard-coding them so the owner can adjust the design from the theme editor. Details that are easy to miss: empty collections and carts, sold-out and sale badges, variant selector style, search results and 404 pages, and email and checkout branding, which are configured outside the theme. Preview the unpublished theme with real products: long titles, products with many images, single-item collections and long text pages reveal what demo content hides. Ask the owner to change a banner, a color and a menu item in the editor before publishing, and keep the previous theme in the library for rollback.

WooCommerce or Shopify: the decision

Choose by comparing surviving sources, required operations, who will edit the store and URL constraints. Neither platform can recreate private orders or customers from captures. The better choice is the one that supports the approved recovery scope without hiding missing data or adding avoidable migration risk, and migration itself is a business decision, not an automatic consequence of an archive review.

Work through six questions. Is native recovery available, in which case repairing the original system may beat a rebuild? Does the catalog fit the destination’s importer, tested with a representative product that has real options and media rather than one simple item? Who will edit content after launch, and can that workflow be demonstrated in the proposed implementation? Which commerce dependencies must work on day one: payment, shipping, tax, subscriptions, fulfilment, apps or extensions? Which historical URLs carry value, and can the platform preserve them, given Shopify’s fixed prefixes? And what are the ongoing responsibilities for hosting, updates, subscriptions, licenses and support, compared with actual quotes rather than a general claim that one platform is cheaper?

A small homeware shop with forty captured product pages, six category pages and a few information pages can be planned twice, once per platform, using the same evidence. The comparison usually shows that the difference is less about the products and more about who runs the shop day to day, which apps or plugins are needed, and whether the old URL patterns can be kept. WooCommerce preserves arbitrary URL structures and runs on hosting the owner controls; Shopify removes hosting and update responsibility but imposes its own paths and app ecosystem.

Keep the decision reversible: keep the evidence register, product spreadsheet and image set independent of the platform so the catalog can be imported again from clean sources, and write a short note explaining why the platform was chosen. A preview establishes editing and visual behavior; it is not proof of restored private records or a production-ready checkout.

What to hand over

The owner should receive more than a working shop. A useful handover includes the product spreadsheet used for the import, the folder of approved images with filenames, every old URL with its new address or redirect, short notes on adding a product, changing a price and updating shipping, and a list of installed apps or extensions with what each does and who pays for it.

Record the gaps that remain: products with missing photos, variations that could not be confirmed, pages that were never captured, and checkout scenarios not yet tested. Writing these down prevents confusion months later and gives the owner a clear list of improvements to make as better information turns up. Do not call the store production-ready because one payment method passed one example.

Frequently asked questions

Can an archived price be copied into the live store?

It can be kept as historical evidence. Publishing it as today’s price requires current owner approval, including the correct currency and sales conditions.

Should every visible selector option become a variation?

No. Verify actual combinations and their relationships. Selector labels alone do not prove that every combination existed or remains available.

Can payment settings be copied from a Wayback screenshot?

A screenshot may show which payment option was offered. It does not provide the account configuration or authorization needed to operate it.

Can changing platforms recover missing orders?

No. Historical private records need an authorized surviving source. A new platform supports newly configured operations; it does not recover history.