SEO migration: change your website and check enquiries
Meypi Developers · Updated on
An SEO migration requires a decision for every website address and checks that people can still find and contact you. Redesigning a page does not require changing its URL. At Meypi Developers, a software studio in the Barcelona metropolitan area, we suggest reviewing addresses, content and enquiry reception as parts of the same change, using a check of our own website as an example.
1. First decide what needs to change
Separate three decisions: design and content, page addresses, and hosting. If an address still describes the same service, consider keeping it. Changing the look of a website does not, in itself, require replacing every address.
Google distinguishes moves with URL changes from infrastructure changes without new URLs. It also warns that rankings may fluctuate during a move. Preparation reduces avoidable errors; it cannot guarantee the same rankings.
2. Make a list of existing pages
Gather current addresses, including those receiving visits, links or enquiries even if they are absent from the menu. Review languages, forms, downloads and campaign pages. Do not delete a page simply because you do not remember it.
| Field | What to record |
|---|---|
| Current address | The complete URL a visitor can open. |
| Purpose | The question or service the page addresses. |
| Available evidence | Visits, search queries, links or enquiries, with dates and sources. |
| Decision | Keep, move to an equivalent page, or remove with a reason. |
| Destination and check | The final URL, what it must show and the test result. |
This is a proposed worksheet for reviewing each page decision. It does not replace an inventory taken from your website and tools.
3. Give a changed URL an equivalent destination
A redirect takes someone opening an old address to the new one. For a permanent move, Google recommends a permanent server-side redirect, such as301 or 308. Check that the destination responds and meets the same need; avoid sending every old link to the homepage for convenience.
An example from our website: in our check on 29 October 2026, the old Spanish app service route returned a 301 to its current page.
| Previous entry | Indicated destination | Observed result |
|---|---|---|
| /servicios/apps-moviles | /es/desarrollo-de-apps | Permanent 301 redirect. |
| /blog/cuando-no-desarrollar-software-a-medida | No equivalent | Observed removal response: 410. |
The same check preserved a 410 removal response: a page without an equivalent is not given an invented destination. Review each decision separately. The destination, links and contact journey also need checks; a 301 does not demonstrate that an enquiry reaches the team.
4. Review links, languages and the preferred page for each piece of content
Menus, cards and text links should point to the final addresses. On a multilingual website, also check every language selector: it should open the equivalent content.
A canonical address indicates the preferred version of duplicate or very similar content. Links, the sitemap and that indication should agree.Google’s canonicalisation guide explains these signals. A canonical does not replace the redirect needed by someone opening an old address.
5. Follow a contact test through to reception
Prepare an authorised, recognisable test for each contact journey. Whoever runs it should know whether it stores information, sends a notification or opens an external channel. Then review the result with the person responsible for receiving it.
- On a phone and computer: open the page, understand the offer and reach the contact route.
- Submit a test enquiry when authorised and check the response shown to the visitor.
- Confirm that the request is saved and reaches the place where the team handles it.
- Distinguish a saved request, a sent notification and a human reading it: these are separate checks.
- Trigger a controlled error and check that the visitor can continue without losing their text or repeating the request.
A tool counting a click on “Contact” does not establish that a request was received. Receiving it does not yet establish that it fits the service.
6. Agree when to proceed and when to roll back
Before publication, agree who accepts the checks and how the previous version can be restored. Check that recovery preserves enquiries received during the change. Do not assume a fault is resolved because the homepage looks right.
- An important URL opens the wrong page: correct the mapping or stop publication.
- A request is lost or confirmed without being saved: stop the change and review reception.
- A tool shows no data: check permissions, consent and configuration before concluding that nobody visited.
Afterwards, record the actual change date and compare equivalent periods. Review URL errors, enquiry reception, traffic and commercial opportunities separately. Early checks help find defects; they do not justify a promise of business recovery.
7. What we need to review your website change
Bring the current website, the reason for the change, its languages, the pages that generate business and how you receive enquiries today. If you are changing providers, locate the domain accounts and measurement tools too.
See our web design service and website cost guide. If you already have a website to replace, tell us what needs to be preserved.
Keep reading
- Custom web design
Planning your company’s new website.
- Website cost guide
What to specify when comparing proposals.
- Website maintenance
What to review after a website is published.
Tell us what you need
What you want to build, by when and with what budget.