- Assess the need
- Define the scope
- Implement and verify
Inventory before redesigning
Collect current URLs from the website, sitemaps, analytics and Search Console where available. Identify pages with useful traffic, links or business value. Record what each destination does before deciding whether to keep, replace or retire it.
Map old URLs to the most relevant new destination. Preserve a URL when there is no reason to change it. Where a redirect is necessary, test the full destination and avoid sending unrelated pages to the home page simply because it is convenient.
Test the launch conditions
Review indexability, canonical URLs, internal links, redirects, sitemaps and important assets in the new environment. Confirm that staging protections will not accidentally remain on production. Also test forms, booking paths and other customer actions.
Assign a launch owner and a rollback decision. Document which checks must pass before traffic moves and which observations happen afterward. A migration involving several vendors needs a shared sequence, not separate assumptions about who flips the final setting.
Monitor and correct after release
Google advises expecting temporary ranking fluctuations while a move is processed. Track old and new URLs, crawl errors and important conversions. Fix missed redirects and broken links from evidence rather than assuming every short-term movement is a permanent loss.
Dappr can scope migration work alongside design or development. Send the current site, planned platform and launch constraints before the build is finalized. SEO review is more useful while the architecture can still be changed than after the old site has disappeared.
Classify the change before building the checklist
A domain move, platform replacement and content reorganization can have different dependencies. List what will change and what can remain stable. If several major changes are proposed together, identify whether they can be sequenced so the team can understand their effects. A project calendar should reflect those dependencies rather than treating launch as a single unexplained switch.
For a hypothetical service site moving to a new builder, retaining a useful page's URL may be straightforward even if its layout changes. A domain move requires a different mapping and control plan. An archive retirement needs a decision about whether the old information still serves customers. These are planning examples; they do not establish a universal migration method or a Dappr result.
Give each mapping a reason
The URL map should explain whether a destination is retained, replaced by an equivalent page or intentionally retired. A person checking the map should be able to understand why the target is appropriate. Include useful documents and assets where they have an established role, not just pages visible in the main navigation.
Review ambiguous destinations with the content owner. A technical resource should not silently become a generic sales page if the visitor still needs the resource. A discontinued offer should not be redirected to a superficially similar service that does not meet the same need. Good mapping requires business knowledge as well as a list of URLs.
Define launch authority and recovery conditions
Name the person responsible for each launch action and the evidence required before it happens. Hosting, domain control, application deployment, content approval and analytics may belong to different people. Confirm the sequence and how the team will communicate a failed check. Avoid a situation where every vendor assumes another vendor is responsible for the final customer journey.
Recovery planning needs concrete conditions. Identify which failures require stopping, which can be corrected in place and which changes can actually be reversed safely. Keep necessary access and prior configuration records available to the authorized team. The existence of a backup does not prove that restoration is quick, complete or appropriate after new customer activity has occurred.
Test representative journeys and exceptions
Choose examples from the important page types and business actions. Test old links, new navigation, document access, forms and confirmations. Include a missing page and a redirected page so error behavior is understood. A successful homepage test should not be treated as evidence that a product template or booking path also works.
Check that tracking still records the intended actions without duplicating them, and that the business can interpret old and new data consistently. Keep implementation evidence with the launch record. Where search diagnostics are available, use them to investigate specific destinations rather than repeatedly submitting URLs without a clear question. A migration test should produce an actionable finding or a verified condition.
Agree on the monitoring and handoff period
Post-launch review needs a defined owner and a prioritized response process. Track whether important old paths reach the intended new destinations and whether customer actions still complete. Distinguish a technical failure from an ordinary variation in demand or an expected period of search processing. Investigate with evidence before attributing every change to the migration.
The engagement should state whether Dappr provides planning, implementation, independent review or a combination. Access, vendor responsibilities and ongoing monitoring must be agreed for the actual site. Bring the planned platform and launch constraints early enough for findings to influence the build. No responsible migration scope can guarantee zero ranking fluctuation or a fixed date for every search engine to process every changed URL.
Questions before you begin
Can a redesign happen without changing URLs?
Often useful URLs can remain stable, depending on the platform and requirements. Preserve them when there is no reason to change. If destinations do change, map them deliberately and test the full customer path.
Should every retired page redirect to the homepage?
No. Choose a relevant replacement when one exists and make retirement decisions deliberately. A generic destination can fail to answer the visitor's original need. The mapping should explain the reason for each important decision.
What is the most useful migration deliverable before launch?
A verified inventory and destination map, combined with ownership and acceptance checks, makes the launch reviewable. Include important assets and customer actions. A checklist without the actual affected URLs is less useful to implementers.
Can you guarantee that a move will not affect rankings?
No. Google documents that significant moves can involve fluctuations while changed URLs are processed. Careful preparation reduces avoidable problems, but it does not establish a universal timeline or guarantee unchanged search performance.
Who should own the post-launch checks?
Assign an accountable person and define which team fixes each type of issue. Record the monitoring period, priority paths and escalation conditions in the scope. The work should not become unowned once the new homepage is visible.