How to Refurbish an Amazon Listing in Google Sheets

Introduction

Refurbishing a listing means migrating an existing FBA product onto a brand-new ASIN — while keeping the SKU, the FNSKU labels, and every unit already sitting in Amazon's warehouses. Sellers do it to start a listing fresh and regain new-product momentum, without touching physical inventory.

The whole play is four moves:

1. Before: you have SKU1 → ASIN1 (the old listing).
2. Create: create a new product under a temporary SKU2 — partially modify the title, highlight, bullets and description, keep every other attribute — and Amazon assigns a fresh ASIN2.
3. Re-home: delete the old listing, then rebuild SKU1 pointing directly at ASIN2. From now on SKU1 → ASIN2.
4. Move stock: FBA units still reference ASIN1; one support case remaps them to ASIN2. Done.

Doing this in Seller Central means juggling flat files, category templates and inventory loader quirks. With SellerSheet's Catalog spreadsheet, the entire workflow lives in three tabs — Live Listings (backup & verification), Catalog Lookup (Amazon-side backup) and the Publish Queue (every create / update / delete submission).

Prerequisites

Getting Around the Sidebar

Four habits make the whole workflow self-explanatory — the sheet documents itself:

• The sidebar menu must match the active sheet tab. Each section (Live Listings, Catalog Lookup, Publish Queue…) is sheet-specific — the sidebar even says "active tab must match". If a button seems to do nothing, check which tab is active at the bottom of your spreadsheet.
• Hover any button to see a tooltip explaining exactly what it does before you click.
• Read the cell notes. Header cells carry notes (the small corner marker) describing how the column is used, accepted values, and examples — hover to read them.
• Publish Queue row 4 is the built-in manual. For every attribute column, row 4 shows its display name plus a format hint and example (e.g. [P9_type_value_pair → split] Externally Assigned Product Identifier · Type); row 5 is the code key the server reads.

Phase 1: Back Up Everything First

1a. Live Listings — Back Up What You Submitted

Open the Live Listings tab. Enter your store in the Store column and SKU1 in the Sku column, then click Live Listings → Fetch by SKU in the sidebar. The row fills in — and the Json column now holds a complete JSON backup of every attribute on the listing. That's your restore source. Note the Asin column value: that's ASIN1.

1b. Catalog Lookup — Back Up What Amazon Accepted

Switch to the Catalog Lookup tab, enter the store and ASIN1, and click Catalog Lookup → Fetch by ASIN. This captures Amazon's catalog-side, normalized version of your listing — useful for spotting what Amazon rewrote, and as evidence for the support case later.

Phase 2: Create the New ASIN

Here's the balance this phase walks: the new listing must carry the old ASIN's attributes — the Phase 4 support case depends on the two ASINs matching. But submit them 100% identical and Amazon decides the product already exists and binds SKU2 to ASIN1; differ too much and changing the copy back after creation sometimes fails. So: keep every attribute from the old listing, and partially modify only four copy fields — Item Name, Item Highlight, Bullet Point, Product Description — just enough for Amazon to treat it as a new product. Once the new ASIN is created, those four fields are changed back to the old ASIN's exact content (Phase 3, step 1).

1. Load the Product into the Publish Queue

Switch to the Publish Queue tab and follow the numbered groups in the sidebar:

1. Fill Store and Listing Locale (e.g. en_US) in row 3.
2. Enter the productType from your Live Listings backup (e.g. HEADPHONES) in the data row.
3. Click Get Template — it loads every attribute column for that category, like downloading the category's Excel template from Seller Central, but in-sheet.
4. Put SKU1 in the sku column and click Fetch by SKU — the whole row populates.

2. Edit the Row into a "New Product" (SKU2)

Why does creating use UPDATE? UPDATE submits the full listing: if the SKU doesn't exist it is created; if it exists it is overwritten. There is no separate "create" operation — SKU2 takes UPDATE too.

Modify, don't rewrite from scratch. Touch only the four copy fields and change them just enough that duplicate detection sees a new product — restructure the title, reword the highlight and bullets, rephrase the description. Change too little and SKU2 merges back into ASIN1; go far beyond these four fields and restoring the original content later can fail. Everything else stays identical to the old listing.

If SKU1 is a variation child, also clear parentage_level, child_parent_sku_relationship, variation_theme and the theme attributes (e.g. color / size) — create it as a standalone product and restore the variation at the end.

3. Add a DELETE Row for SKU1 in the Same Batch

On the next empty row, enter SKU1 in the sku column and set operationType to DELETE. That's it — a delete row needs only those two cells. Creating SKU2 and deleting the old listing in the same batch frees SKU1 up, so you can rebuild it on the new ASIN2 in Phase 3.

4. Validate, Then Submit

Click Validate (Preview) and check the Submission Log tab for ERROR-level issues — validation is a preview, nothing publishes. Once clean, click Create/Replace/Del. to submit (instant for up to 20 rows, dispatched per row's operationType; use Submit Feed for larger batches).

5. Verify ASIN2 Was Born

Wait 10–15 minutes. In Live Listings, fetch SKU2 and read the Asin column — that's ASIN2. The critical check: ASIN2 ≠ ASIN1. You can cross-check in Seller Central too.

Phase 3: Rebuild Your SKU on the New ASIN

1. Restore the Original Copy on SKU2 First

Before rebuilding SKU1, copy the original copy from your Phase 1 Live Listings backup back onto the SKU2 row and submit with operationType=UPDATE. The column mapping:

Why this matters: it makes ASIN2's attributes identical to ASIN1's. When you open the support case in Phase 4, support can't reject the remap on the grounds that the two ASINs are different products. After submitting, fetch SKU2 in Live Listings once more and confirm it still resolves to ASIN2.

In the same submission, lock the identifier to the new ASIN — so every later update lands on the newly created ASIN (with the identifier left empty, Amazon can sometimes spawn yet another listing):

Identifier and GTIN exemption are mutually exclusive: if SKU2 was created via exemption (supplier_declared_has_product_identifier_exemption = TRUE), clear the TRUE first — it cannot coexist with externally_assigned_product_identifier.

2. Rebuild SKU1 Pointing at ASIN2

Back in the Publish Queue:

1. The row's attributes already match SKU1 exactly and the identifier points at ASIN2 from the previous step — just change the sku cell to SKU1, with operationType = UPDATE.
2. Confirm SKU1 is fully deleted — Fetch by SKU on SKU1 in Live Listings shows SKU … not found in the Json column. If it still resolves, wait and re-check before submitting.
3. Validate (Preview) → Create/Replace/Del.

3. Verify the Rebuild

• Live Listings — fetch SKU1: the Asin column should now read ASIN2.
• Seller Central — Manage All Inventory shows SKU1 / ASIN2; Fix Stranded Inventory shows SKU1 / ASIN1. The stranded entry is expected — your FBA units still reference the old ASIN until Phase 4.

Phase 4: Move the FBA Inventory & Clean Up

1. Open the Support Case

Go to Seller Central → Help → Get support → Selling on Amazon → Products and inventory → Fix a product page, and use this one-liner (swap in your own SKU1 and ASIN2):

If support asks for evidence, provide a Manage All Inventory screenshot and your Phase 1 Catalog Lookup backup showing the two ASINs are the same product. Once processed, the stranded entry clears and your stock is sellable under ASIN2 — no relabeling, no new shipment.

2. Clean Up

• Delete SKU2 — after the remap it's just a duplicate empty offer on ASIN2 that can interfere with pricing and the Buy Box. Add a DELETE row in the Publish Queue.
• Restore the variation (children only) — re-add parentage_level=child, child_parent_sku_relationship, variation_theme and a theme attribute value that doesn't clash with existing siblings.
• Archive the backup rows, the case ID and the timeline.

Common Pitfalls

Frequently asked questions

Do I need to relabel or move my FBA inventory?

No. FBA inventory is tied to the FNSKU, which never changes in this workflow. After you rebuild your SKU on the new ASIN, a short support case asks Amazon to remap the existing inventory — no removal orders, no relabeling, no new shipment.

Why does the temporary SKU need a new UPC or GTIN exemption?

Amazon matches products by GTIN before it looks at your title. If the temporary SKU carries the old UPC, it attaches straight back to the old ASIN and no new ASIN is created. Use an unused UPC, or leave the identifier empty and set the GTIN exemption flag if your category allows it.

My temporary SKU came back with the OLD ASIN — what went wrong?

Either the identifier matched (same UPC) or the four modified copy fields were still too similar, so Amazon's duplicate detection merged it into the existing ASIN. Delete the temporary SKU, increase the changes to those four fields, and resubmit.

Why does Fix Stranded Inventory show my SKU with the old ASIN?

That is expected mid-workflow. Manage All Inventory shows your SKU on the new ASIN, while the FBA units still reference the old ASIN until the support case remaps them. Once the case is processed, the stranded entry clears and the stock is sellable under the new ASIN.

Can I refurbish a variation child?

Yes. Note the parent SKU, variation theme and theme attribute values first, clear the variation columns when creating the temporary SKU, and re-attach the rebuilt SKU to the parent at the end — using a theme value that does not clash with existing siblings.

Why restore the original copy before rebuilding the SKU?

The support case succeeds when the two ASINs clearly represent the same product. Restoring the original title, bullets and description makes the new ASIN's attributes identical to the old one, so support has no grounds to reject the remap as a different product.