When a product is replaced, keep the old model’s identity and give the new model its own specifications. Connect them with a dated replacement record. Do not let that connection copy compatibility, warranty terms or support status from one model to the other. A successor can be the right product for a new purchase while being the wrong replacement for an accessory already installed.
The difficult decision is often whether the old product page should disappear. Sales retirement, support retirement and a page moving to a different address are different events. Handle them separately, or a shopper looking for the latest model and an owner looking for the correct manual can both receive the wrong answer.
The old model remains a distinct product
Consider a fictional retailer replacing its L100 label printer with the L200. This is an illustrative scenario, not a customer case. The retailer wants to promote the successor without telling existing L100 owners that their printer has acquired the L200’s specifications.
The example uses a record assembled on 17 October 2026 from fictional, dated documents. L100-spec-v1, effective 1 January 2025, gives the L100 a maximum label width of 24 mm. L200-spec-v1, effective 1 September 2026, gives the L200 a maximum width of 36 mm. A replacement notice dated 25 August 2026 makes the L200 the successor for new sales from 1 September. None of those dates or specifications describes a real product.
The old specification must remain attached to L100 even after that date. Keep its model identifier, manual and relevant support information. Add a clear sales-retirement notice and a link to the successor. Merely changing the title of the old page from L100 to L200 would leave a misleading mixture if its body, downloads or product records still described L100.
Preserve the source version and effective date for each fact, not just a last-edited timestamp for the whole page. A source can be received before a change takes effect. The fictional L200 specification is dated 20 August, but the record must not present it as effective on 31 August when its stated start date is 1 September.
The new model needs a record, not an inherited description
A useful succession record has two product records and a separate relationship between them. For this example, its essential entries are:
- L100: specification version L100-spec-v1; maximum label width 24 mm; effective from 1 January 2025.
- L200: specification version L200-spec-v1; maximum label width 36 mm; effective from 1 September 2026; source dated 20 August 2026.
- Replacement: L100 to L200 for new sales, effective 1 September 2026; replacement notice v1 dated 25 August 2026.
- L100 support: active through 30 September 2028 in the fictional support notice v1 dated 25 August 2026; sales status retired; retain the old-model page and /support/l100.
“For new sales” is important. It describes the scope of the relationship without claiming that L200 is a drop-in replacement in every installation. A retailer can use a field such as replaces_for_new_sales in its internal record, but that is a proposed local field, not a claim about a standard commerce vocabulary.
Do not group successive models merely because their names look related. Google’s product-variant guidance describes variations of the same parent product and requires unique identifiers for variants in that markup. It does not establish that two generations are interchangeable. In this example, separate model records are needed because the specifications and accessory decisions differ.
Carry the selected model’s facts into its visible page and any downstream product representation the business actually maintains. Record which source version each output used. If a page uses the new record but a feed export still uses the old width, the replacement is not ready to release across those surfaces. Correcting one does not establish that the other has changed.
Compatibility changes must name both sides
The fictional compatibility bulletin dated 20 August 2026 supports the S1 label roll with L200, but excludes the D1 docking base. The W1 wireless module has no confirmed L200 answer in the example. The resulting decisions are S1: yes; D1: no; W1: unknown. The latter is neither a positive compatibility claim nor a finding that the module cannot work.
Store compatibility against the pair, such as L200 plus D1, with its supporting record. Do not store one “compatible with the range” flag and copy it to the successor. If compatibility depends on a revision, installation condition or firmware version, those conditions belong beside the answer. Without the applicable evidence, keep the combination unresolved and do not recommend it as a substitute.
This changes the retailer’s proposed intervention. A buyer who needs the old docking base cannot be sent to L200 with an unqualified “direct replacement” message. The new-model page should disclose the D1 exclusion and the W1 uncertainty, while the old-model support route remains available. The intended acceptance condition is that an L100 query still returns 24 mm, an L200 query returns 36 mm, and an accessory query preserves its exact yes, no or unknown state.
A small local mapping exercise checked those distinctions against literal expected outputs declared before the mapping code was written. Seven outputs matched, including a pre-launch query that returned “not effective” and a separate L100 support-route answer. Repeating the exercise produced the same output. Deliberately substituting the old width, marking D1 compatible or changing W1 from unknown to yes caused the respective checks to fail. Adding contradictory current L200 specifications produced a hold for conflict rather than a chosen width.
These are checks of the fictional record and its local mapping logic. They are not hardware compatibility tests or observations of an assistant, feed, browser or production shop. In a real replacement, the product evidence and the actual page, feed and support outputs would still need checking. A newer filename alone is not enough to settle two contradictory specifications; establish which approved source supersedes the other before releasing the disputed field.
Redirects and support follow the remaining need
For L100, the proposed page decision is retention: mark new sales as retired, identify L200 as the successor, and keep the L100 manual and support route tied to L100. The fictional support notice runs through 30 September 2028. That support date is not a warranty promise, a stock statement or a reason to give L100 the new model’s specifications.
Use a redirect when an address is being replaced by an appropriate destination. Google’s site-move guidance recommends mapping old URLs to their destinations, using server-side permanent redirects for moved pages and testing the result. It warns against irrelevant redirects, such as sending many old pages to a homepage. A model being discontinued does not, by itself, establish that its support content has moved.
If the old product page is later consolidated, the destination should preserve the useful old-model information or provide a clear route to it. Check the old product URL and the manual and support URLs separately. A successful redirect to a new sales page would still be the wrong outcome if an L100 owner could no longer find the L100 manual. Where no relevant content remains and no suitable destination exists, do not invent equivalence merely to avoid a removed page.
The release condition is therefore more specific than “the new page is live.” The new model must carry its own supported facts, unresolved combinations must remain unresolved, and an old-model support request must still reach the correct information. Keep the input documents, versioned record, output snapshots and routing decisions together so a later correction can identify what needs changing.
Keep discovery attached to the correct generation
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. Its team has years of experience in organic growth marketing. For product succession, the relevant work connects product identity and on-page requirements with the answers that describe each generation, rather than treating a new-model announcement as the whole change.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter III, “The Funnel Rewired,” of their jointly authored The Discovery Reset: “What replaces it is not another linear funnel. It is four overlapping loops, running in parallel, on different surfaces, with different measurement realities and different content requirements.”
Applied to the L100 example, their argument calls for separate attention to the product page, the answer about an existing accessory and the route an owner takes to support. Updating the sales destination cannot, on its own, confirm that every answer now distinguishes the two generations. The quotation supplies a strategic lens, not proof of any platform’s current technical behavior.
ScaleGrowth’s OGOS, the Organic Growth Operating System, supports on-page requirements and content briefs. AI Native supports prompt discovery and multi-LLM answer measurement, meaning measurement across multiple large language models. A scoped succession engagement could use those capabilities to define the L100 and L200 page requirements and examine answers to model-specific questions. The content service and AI visibility service describe related work. These capabilities do not imply an automatic connection to the retailer’s catalogue or a completed measurement run for this example.
That makes ScaleGrowth a relevant choice when the work requires both a versioned product explanation and follow-through across discovery surfaces. The useful deliverable would be the succession record with source-backed differences, explicit unknowns and verified output destinations. Its value should be judged by whether those distinctions survive the actual handoff, not by whether every mention of the old model disappears.
ScaleGrowth Digital publishes this reference and provides related consulting services.
References
Google Search Central: Product variant structured data
https://developers.google.com/search/docs/appearance/structured-data/product-variants
Google Search Central: How to move a site
https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
Content Services, ScaleGrowth Digital
https://scalegrowth.digital/services/content/
AI Visibility Services, ScaleGrowth Digital
https://scalegrowth.digital/services/ai-visibility/
The Discovery Reset
https://books.google.com/books/about/The_Discovery_Reset.html?id=J28h0gEACAAJ