Before a Shopify redesign, record each existing URL, the buyer question it answers and the content evidence behind it. Choose whether that route and answer should stay, merge, move, retire or wait for confirmation. For every proposed destination, name the information that must survive, who accepts it and how the changed route will be checked. A new visual layout does not require every URL to change.

This is preparation before implementation. The existing 404 review guide already explains equivalent replacements, source-link repairs and why unrelated URLs should not all point to the homepage. Here, the deliverable is a URL and content map for pages that may still be working, before a redesign changes them.

Which existing URLs belong in the inventory?

Start with the routes and content you can identify from the current store, available sitemaps, exports and internal links. Record where each URL came from, when it was checked, its current response and final destination. Check the present route even when an older project spreadsheet lists it.

Google's site-move guidance recommends preparing a mapping from old URLs to their intended new locations. For a redesign brief, extend that map with the question each page answers and the evidence you have for keeping or changing it.

Keep meaningful language, market, query or section context in the inventory when it affects the visit. Also note linked images and documents that the reader needs. If analytics, Search Console or inquiry records are unavailable, say so. An absent export does not mean a page has zero traffic or no business role, and it cannot support an invented priority score.

What content must stay attached to each URL?

Record the useful answer, its qualifications and its applicable source version. Include the relevant product or service reference, source documents, images and next step. A destination can load correctly while omitting the condition that made the old answer accurate.

Our page content-brief guide covers the evidence and review scope for one page. In the redesign map, connect each old page to its proposed destination. Identify which existing item goes to which destination section, which item needs revision and who can confirm that choice.

For the teaching example below, assume Note N1 supplies an option-selection explanation and Note N2 supplies useful supporting guidance. A configuration-confirmation condition must remain visible. These notes and all example paths are authored assumptions, not GRC product facts, customer pages or an approved migration plan.

When should the existing path stay the same?

Keep the path when it remains appropriate for the page's reader task and the agreed redesign does not require a move. In example U1, /pages/material-options can retain its route while the layout changes. The content reviewer still checks the N1 explanation, qualification and source reference in the new presentation.

A keep decision needs evidence too. Record the retained path and the content checks, rather than leaving its destination cell blank. The operator can then distinguish a deliberately unchanged route from a page nobody reviewed.

U4 has a different reason to stay separate: a care question is not the same task as choosing a material option. A shared term or a desire for fewer pages does not establish that one destination can replace both answers. Record the distinct job before proposing a merge.

How do you choose between keeping, merging and moving?

Compare the old reader task with what the proposed destination will actually explain. If two pages belong together, list the useful material and conditions that the combined answer must retain. If the route moves, identify the replacement content and its acceptance state. If the evidence or destination is missing, leave a specific decision open.

Each row in this fictional map is a proposal to review. None represents a created redirect, retired page, tested destination or real business approval.

Scroll inside the map to read the decision, retained content and acceptance columns. Row IDs repeat across the table.

Fictional pre-redesign map / proposals only, not redirect commands
Existing route / buyer task Proposed decision / destination Content to carry or hold Acceptance / next owner
U1 / /pages/material-options / choose an option U1 / Keep / same path U1 / Retain the N1 explanation, configuration-confirmation condition and source reference. A layout change alone does not require a new path. U1 / Content reviewer compares old and proposed content; operator checks the retained route after an authorized launch.
U2 / /pages/material-notes / read supporting notes U2 / Propose merge / /pages/material-options U2 / Carry useful N2 material and its qualification into the destination. Agree where each retained item will appear before retiring the old page. U2 / Content owner confirms coverage; operator evaluates an eligible old-route redirect only after the approved target is ready.
U3 / /pages/request-drawing / prepare a drawing question U3 / Propose move / /pages/drawing-review U3 / Preserve required inputs, source-version references and the stated review boundary. Target is still a proposal, not a live result. U3 / Owner accepts the target content first; then approve the exact route change and verify the resulting path and next step.
U4 / /pages/care-guide / answer a care question U4 / Keep separate / same path U4 / The care question differs from material selection. Shared vocabulary alone does not justify merging the answers. U4 / Reviewer records the distinct reader task and evidence; operator checks its own source and contact links.
U5 / /pages/past-event / review an ended event U5 / Propose retirement / no equivalent target identified U5 / Owner must confirm retirement and whether useful content belongs elsewhere. Do not choose the homepage merely to fill a target cell. U5 / Technical owner verifies the appropriate unavailable response if removed; no Shopify 410 configuration is assumed.
U6 / /pages/technical-claims / check an unconfirmed claim U6 / Hold / destination undecided U6 / Applicable source or confirmation owner is missing. The map does not turn the claim into approved new-page copy. U6 / Information owner resolves the fact/scope gap; keep the affected mapping and implementation decision pending.

U2 records what a merge must carry into the destination, while U3 still needs its proposed target prepared. U5 has no justified replacement yet. U6 lacks applicable claim evidence, so choosing a convenient new address would not resolve it.

Follow the N2 source and condition in the figure. Their destination matters as well as the old-to-new route.

Scroll sideways to follow each retained item into the proposed destination.

Fictional U2 maps material-notes to material-options. Note N2 and its configuration-confirmation condition each have a proposed destination section. The content must be reviewed before an old-route change; no merge or redirect is applied.
A path pair cannot show whether the useful explanation and its qualification survived. Record their destination and reviewer.

What makes a redirect proposal ready for technical review?

Keep the planning row separate from redirect instructions. Shopify's URL-redirect reference describes an old path and a target location. The worksheet includes content and responsibility decisions around those fields; it is not an API payload or import file.

Check the actual route before deciding how to implement a move. Shopify's redirect documentation says that a redirect cannot take effect while its source still loads a valid page. It also lists path and variant limitations. A map does not establish that a particular route is eligible, and this preparation does not authorize deleting a working page.

If content is removed without a similar replacement, Google's crawling-error guidance describes returning an appropriate 404 or 410 response. Have the technical owner check the supported behavior for the actual store. This does not assume that Shopify offers a setting to choose 410 for the example page.

How does one proposed move get checked?

For U3, first prepare /pages/drawing-review with the required inputs, source references and stated review boundary from the old page. The content owner checks the proposed answer before anyone treats the new address as an accepted replacement. In this exercise, the destination remains a proposal.

After a separately authorized implementation, check the old route's actual response and final arrival. Confirm that the destination answers the expected question and that the retained qualification is visible. A successful redirect alone cannot confirm content that was never carried over.

Then check the relevant document, internal reference and contact step. The contact-context guide owns the channel-handoff detail. Here, name that dependency in the row and record what was checked; opening a contact URL is not evidence that a message or its context arrived.

Scroll sideways to read the three separate checks for fictional U3.

Fictional U3 proposes request-drawing to drawing-review. Three separate checks cover destination content, the actual old-route response and arrival, and source or contact links. Each result remains pending; no page, redirect or message was created.
Record content acceptance, route behavior and the relevant next step separately. One passed check cannot supply the other two.

What belongs in the redesign handoff?

Give the implementer the reviewed map version, exact routes, retained-content list, applicable source versions and named acceptance owner. Distinguish proposed, locally reviewed and live-verified destinations. Include unresolved rows and the person who must answer each one, so a blank or pending target cannot become a guessed change.

List internal references, images or downloads and relevant contact links that need updating or checking. Keep prior-state evidence and an agreed restoration approach for the authorized change. Review permission for that specific action separately from accepting the wording or visual layout.

Use the editable worksheet to record those decisions. It is a planning aid, not a claim that an Agent imports the format, creates redirects automatically or decides which business content to discard. Keep unsupported rows open while unrelated preparation continues.

What can the post-launch record actually prove?

Record the actual result for each implemented row, the check date, evidence, partial failures and next owner. A successful destination request shows availability at that time. A route check shows where a particular old URL arrived. Content review records the answer and conditions inspected. Keep those outcomes distinct.

Google notes that significant site changes can cause ranking fluctuations while content is recrawled and reindexed. A completed map or a working route does not guarantee retained positions, traffic or inquiries. Review comparable search and business evidence later when it is available; do not turn a launch check into a performance claim.

GRC's website and theme implementation services connect page architecture, content preparation and reviewed handover. Bring an existing URL list, the content that must remain and the unresolved mapping rows to Discuss your project. The next conversation can clarify source gaps, responsibility and the redesign work to agree.