The idea, in plain English
Start here.
A migration changes a site’s platform, addresses, hosting or structure. Start by recording exactly what changes. For a URL move, preserve an old-to-new map, use appropriate redirects to genuine replacements, update dependent references and test both content and functionality. Keep implementation checks separate from Google’s later processing and uncertain performance outcomes.
A new design can look finished while an old bookmark leads to the wrong page or a contact form stops delivering. A useful migration plan protects actual information and tasks, as well as search signals. This beginner lesson gives you a small decision record to prepare with the people implementing a move.
A few words you’ll meet.
OPEN WHAT YOU NEED ↙Migration scope
The specific platform, host, address, content or template changes included in the project. A hosting change with unchanged URLs differs from a domain or path move.
URL map
A record of affected old addresses, intended new behavior, relevant destinations, reasons, owners and verification checks.
Baseline
A dated record of the site, routes, content and available measurements before the change, with their definitions and limits.
Rollback plan
An agreed recovery procedure for a serious failed change, with a decision owner and tested steps. Returning safely can involve more than changing DNS.
Name the change and preserve the before
Write what changes: domain, paths, CMS, hosting, design or several of these. Mark what is intended to stay. Google advises sequencing major changes where possible because moving everything at once makes problems harder to isolate. Do not add URL changes merely because the design is new.
Keep a dated crawl, content and asset inventory, useful response observations and available page-level performance data. Merge relevant CMS, sitemap, analytics, Search Console, link or log records rather than assuming one list is complete. Save settings and measurement definitions too. A missing baseline cannot be recreated by inventing pre-move results.
Give every affected address a reasoned decision
For changed URLs, compare each old answer with its intended destination. A permanent replacement normally calls for an appropriate permanent server-side redirect, such as 301 or 308, where possible. An unchanged useful URL can stay. A genuinely removed page without a relevant replacement needs deliberate missing-page behavior rather than an unrelated homepage destination.
Include important images, files and other resources in the plan. Update ordinary links, sitemap entries and canonical annotations to match the intended final addresses. If language annotations or other URL references exist, review those too. A redirect map is a set of content decisions, not just a column of successful response codes.
- Old address and its existing reader task.
- Intended behavior and verified replacement, if one exists.
- Reason, implementation owner and acceptance check.
- Dependent links, files and declarations that need review.
A release gate needs observed checks
Test the candidate and agree the release gate
Test the map and representative templates in the appropriate controlled environment. Check the response, actual final content, images, links, headings and intended indexing settings. Keep preview access protection appropriate; making a staging site publicly accessible is not a requirement for doing useful QA. Review environment-specific settings so development restrictions do not accidentally affect public pages.
Test important tasks end to end with authorized test data: opening an old bookmark, finding a guide, submitting a form or completing the relevant workflow. A thank-you screen alone does not establish that a submission reached its intended destination. Agree which failures prevent release, who decides and how recovery works. A developer or hosting owner should validate the implementation and rollback procedure for the real setup.
Recheck the live result and later processing separately
When an authorized release happens, repeat the actual URL and task checks on the public environment. Hosting or CDN rules can differ from the candidate. Confirm the intended public crawl/index settings, coherent declarations, new sitemap and measurement configuration. For domain or subdomain moves, review whether Google’s Change of Address tool applies; it does not apply to every hosting, protocol or same-domain path change.
Monitor errors, affected page groups and old/new URL information with context. Google processes moves per URL, and ranking fluctuations can occur without a fixed recovery deadline. Its guidance recommends keeping redirects as long as possible, generally at least a year; plan ownership and maintenance accordingly. A correct route is an implementation result, not proof that all search signals or business outcomes have already settled.
A small mapping sheet with different outcomes
Fictional same-domain move for a workshop site. These are proposed decisions before implementation, not a report of a completed launch.
| Old address | Decision | Acceptance check |
|---|---|---|
| /guides/tools/ | Retain this useful unchanged URL. | The guide, images and intended declarations survive the import. |
| /booking-old/ | Permanently move to the verified /workshops/book/ replacement. | The old request reaches the right booking information and the test workflow completes. |
| /event-2021-offer/ | Review deliberate retirement; no relevant replacement exists in this exercise. | The agreed missing-page response and useful navigation appear; no arbitrary homepage redirect. |
| /files/tool-list.pdf | Retain the file or map its actual new location. | The existing download route reaches the intended readable file. |
Put it into practice
Prepare a migration go/no-go note
Use the fictional workshop mapping sheet. The candidate looks good, but the booking form has only shown a thank-you screen; delivery is unverified. The old PDF route has not been tested.
- Write the scope and name the baseline records you would preserve.
- Confirm each URL decision, including unchanged and deliberately retired items.
- Identify the unverified form delivery and PDF route as open checks.
- Assign an owner, expected evidence and release decision for those checks.
- Add live-environment rechecks, later monitoring and a recovery plan without promising a fixed ranking outcome.
Keep your working notes in your own document. This page saves only your completion check, not your answers or customer data.
Check your understanding
Make the call.
Choose an answer for each question. Then compare the reasoning.
You have a useful next step.
- Define the move and preserve a dated before-state.
- Make reasoned URL decisions and test the real content and workflows.
- Use an evidence-based release gate, maintain recovery options and monitor later processing honestly.
Completion is your own learning record. Quiz scores and practice checks are saved separately, on this browser.
Sources & context
The sources below explain the factual foundations and editorial methods used in this lesson. Worked examples, planning models and exercises are illustrative teaching material.
- Google: Site moves with URL changes
Primary guidance on sequencing, mapping, permanent redirects, reference updates, applicable Change of Address, monitoring and redirect retention. The release-gate exercise is original.
- Google: Redirects and Search
Official context for permanent and temporary request behavior and suitable implementation.