A migration needs an explicit destination for each important old URL
Map each important old URL to an outcome that preserves its actual purpose: keep accurate content at that address, redirect to a genuinely appropriate destination, or return a real missing-content response when the content is gone. Open the proposed destination and assess what it actually says before approving the map. An unrelated homepage or category is not automatically a replacement. Record the expected response, approving owner and later observed result separately; choosing a redirect does not promise indexing or ranking retention.
For: A research-only merchant and its implementer deciding what existing public product and policy links should do after a store migration.
Collect the public URLs present in the current catalog, navigation, policy links, published documents and other genuine store records. Note important outside links already known to the business, including links in previously sent communications. Do not invent a traffic ranking for this list. Its first purpose is to preserve real routes people use to reach a product or understand a policy.
For each URL, record the content and purpose at that address before the move. A product detail page, a shipping policy and a dated policy record serve different needs even when their old paths look similar. Capture what the page currently offers and the owner’s intended outcome. This is a decision map before migration, distinct from an inventory of pages already retired.
Keep private order-payment links and account-specific URLs out of a public migration worksheet. A public product route can be reviewed without copying customer tokens or private order records. Identify any private-route dependency separately through the merchant’s authorized internal process.
Approve a destination for its meaning
Open the actual proposed destination. For a product link, compare the product identity and the offer that a visitor would find there. A different product is not made equivalent by a similar name or by being in the same category. For a policy link, confirm that the destination answers the policy question the old link described and that the merchant has approved the wording.
Where current and historical policy versions have different purposes, decide which record the old URL should preserve. Replacing an old page with current wording is not proof of what an earlier order was shown. Keep any genuine historical record the business needs; the URL map does not decide contractual applicability.
If no destination preserves the old page’s purpose, do not manufacture relevance by sending every retired address to the homepage. Choose whether accurate content should remain at the old address, whether a real successor needs to be completed, or whether the content should be treated as missing. A destination that has only been proposed is still an unresolved dependency.
Make the response match the intended outcome
A retained page should provide the accurate content the URL is meant to serve. A redirect sends the visitor to another URL, so the destination’s content becomes central to the decision. Ask the implementer to record the exact redirect response it will use and the intended destination; the merchant’s approval of the content mapping and the technical response choice are separate entries.
When content is genuinely gone and there is no appropriate destination or retained page, a real 404 or 410 communicates missing content. A page that displays a not-found message while returning 200 is a different response. Google’s HTTP status documentation says error content returned as success can be treated as a soft 404.
The same documentation says a 200 response does not guarantee indexing, redirects lead to destination content that Google processes, and 404 or 410 responses lead to removal of indexed URLs over time. None supplies an immediate search outcome. The map can specify what the store should return; it cannot promise retained rankings or the date an old search result will disappear.
Verify each approved outcome after implementation
Keep the approved old URL, destination and expected response before anyone changes routing. After implementation, compare the old address’s actual response and final visible content with that record. Opening only the new page does not show what a visitor following the old link will receive. Record any unexpected intermediate destination, missing page, wrong product or wrong policy wording.
Update links the merchant controls so they point to the intended public content. Keep known external links marked as outside that control; the old URL’s implemented behavior is still the part the store can verify. A rule entered in an administration screen is a configuration record, while a dated observation of the old URL is evidence of what was delivered.
Assign a person to resolve every unmatched outcome before declaring that part of the migration ready. For a Prism checkout-review consultation, identify the affected product, policy or checkout-adjacent URLs and the specific transition question. Discuss review and any requested implementation responsibilities, fees and terms before work. Send the website, products and question without customer records or private links. The request receives email follow-up; it does not book an appointment, purchase migration work or submit a processing application.
Old-to-new URL decision
Complete one copy for each important genuine public URL. Record intended behavior before the change and observed behavior afterward. An unresolved destination or approval means the mapping is still open; successful loading alone does not show that the right content arrived.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Old-to-new URL decision. The last column is for temporary notes.
Mapping field
Record to use
Acceptance question
Your URL decision
Old URL
Record to useExact public address from the current site or genuine published link.
Acceptance questionCan the implementer identify the same address without including private payment or customer tokens?
Current purpose
Record to useDated observation of the product, policy or reference content at that address.
Acceptance questionWhat information was the visitor seeking, and what real record should survive?
Actual destination
Record to useThe opened destination URL and its visible content, or an explicit decision to retain or remove content.
Acceptance questionDoes this content answer the old link’s purpose rather than merely share a category or brand?
Expected response type
Record to useThe retained-content, redirect or missing-content decision and the exact intended HTTP response.
Acceptance questionDoes the server response agree with the content outcome, including a real 404 or 410 when appropriate?
Owner approval
Record to useMerchant approval of the destination’s meaning and the implementer assigned to configure it.
Acceptance questionWho has agreed this is the right result, and who can resolve a mismatch?
Dependent public links
Record to useKnown navigation, documents, policy references and outside links pointing to the old address.
Acceptance questionWhich links can the merchant update, and which must remain marked outside its control?
Observed result after implementation
Record to useDated old-URL response, any redirect path and final visible content.
Acceptance questionDoes the delivered behavior match the approved map, or which exact difference remains open?
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
This map does not promise ranking retention, indexing, immediate search removal or an uninterrupted migration.
An accurate URL outcome does not erase historical records or determine the legal applicability of a policy version.
Use public URLs only in shared worksheets and inquiries. Exclude private payment links, customer identifiers, credentials and account tokens.
Google HTTP status codes documentation — checked 2026-09-28. A 200 response does not guarantee indexing; error content returned as success can be a soft 404. Redirects lead to destination content. 404 and 410 identify missing content and lead to eventual removal of indexed URLs, without an instant outcome or ranking promise.
Prism solutions — checked 2026-09-21. Public support includes storefront review, processing preparation and provider website questions; scope, fees and terms are discussed before work, and provider eligibility remains a provider decision.
Prism contact — checked 2026-09-21. The form asks for website, products and question while excluding payment details, passwords and customer records. Email follow-up does not create an appointment, purchase or processing application.