Rebuild an archived product catalog from evidence one field at a time. A captured product page can support a name, description or image that is genuinely visible. It does not establish today’s stock, every historical variation, supplier cost or current selling price. Keep recovered information separate from current business decisions before importing or publishing products.
The aim is a usable, reviewable catalog, not the largest possible product count. A smaller set of verified products is safer than a store filled with plausible descriptions, invented combinations and misleading availability.
Give every product a source-backed identity
Start with authorized native exports when available, then compare public captures and owner-held product material. A native export can retain structured information that a storefront view does not expose. Preserve the original source file unchanged and record its date before preparing a working copy.
Product names alone are poor identifiers. Names change, different items can share a label, and the same item can appear in several categories. Use a confirmed SKU or other owner-held identifier where available. Otherwise, assign a provisional recovery reference and keep the original URL, source date and distinguishing details together.
Do not silently convert that provisional reference into a claim that an original internal product ID has been recovered. Public page identity, SKU and CMS record number are separate concepts.
A product evidence card
Use the following record for each recovered item. It can be maintained in a spreadsheet without storing customer or payment information.
- Identity: source identifier if verified, original URL and working recovery reference.
- Field and value: the exact name, description, image association, attribute or category under review.
- Source and date: an export row, capture or supplied document that supports this particular value.
- Conflict or gap: another source disagrees, the text is incomplete 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.
This field-level approach avoids a common error: treating one good product screenshot as evidence for every field on a rebuilt product. The image may be clear while the specification table is unreadable or the selected variation has no captured price.
Recover descriptions and images without completing the gaps by guesswork
Preserve readable product facts and check them against surviving supplier or owner material. If the capture cuts off a specification, mark it unresolved. Do not finish a sentence using what similar products usually contain. Dimensions, compatibility and warranty claims can affect purchasing decisions.
Trace each image to the intended product, not simply to a nearby filename. Check whether it shows the correct model, color and variation. Obtain authorization for reuse. A replacement image supplied by the owner should be recorded as a replacement rather than described as recovered photography.
For WooCommerce, the current CSV documentation explains that images must be pre-uploaded or downloadable from their supplied URLs. The core importer does not update image alt text. Plan an independent image-description review instead of assuming a successful product import completed accessibility work.
Reconstruct categories and variations as relationships
A category page can show which products were listed there at a capture date, but it may be paginated or incomplete. Combine relevant category evidence with each product’s recorded relationships. Avoid assigning every recovered product to a broad category merely to make navigation look populated.
For variations, record each evidenced combination separately. Seeing a size selector and a color selector does not prove that every size-color combination was sold. Nor does it establish its price, stock or image. Request a genuine export or owner confirmation where the public view does not resolve those relationships.
Use the destination platform’s current product schema when preparing imports. WooCommerce distinguishes parent products and variation rows. Version-specific importer behavior can differ, so verify the installed version and review skipped-row reports rather than copying an old tutorial’s assumptions.
Historical price is not current permission to sell
Keep captured prices as dated evidence. Before a product becomes purchasable, the owner must approve the present selling price, currency, availability and relevant sales conditions. The latest surviving capture can still be years out of date.
Do not infer stock from an old Add to cart button. Do not treat a missing stock label as unlimited supply. If the business has not confirmed an item is currently offered, keep it out of the live purchase path until a deliberate decision is made.
The same principle applies to discontinued products. They may have valuable historical URLs and explanatory content, but their recovery does not require offering them for sale. Separate URL/content preservation from present inventory decisions.
Review a small import before scaling up
Use an authorized isolated review environment and a representative product set: a simple item, a variable item, a multi-category item and an item with an unresolved field if those cases exist. Check identity, relationships, images and status after the import. Do not infer success from the number of processed rows alone.
WooCommerce’s documentation recommends a backup and staging tests for larger imports. New products receive new available IDs rather than a chosen original post ID. Preserve an explicit old-to-new identity map when relationships depend on those IDs.
Review duplicate handling before importing the full dataset. Repeated recovery references, ambiguous SKUs and alternate URLs need investigation, not automatic merging. Keep an import log that identifies accepted, skipped and rejected entries without exposing private credentials or records.
Hand off a catalog with visible boundaries
A useful acceptance record states how many products were approved, which fields remain unresolved, and which current values were supplied by the business. Do not call a catalog complete unless the source inventory and defined scope support that statement.
The WooCommerce recovery service separates public catalog reconstruction from private commerce data and fresh operational configuration. For a source set with missing pages or assets, the incomplete-archive source map can help organize supplementary material before catalog work begins.
Catalog recovery questions
Can an archived price be copied into the live store?
It can be retained 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 product relationships. Selector labels alone are not evidence that every possible combination existed or remains available.
