A website migration can improve the customer experience while disrupting the pages that already bring enquiries. Before an Irish business changes its domain, content platform or URL structure, it needs a record of what currently works and a named owner for checking the release. A polished homepage is only one part of that job.
This checklist is for a business owner working with a developer or SEO specialist. It covers the handover between the old and new site, rather than promising that rankings will remain unchanged. Even a well-managed move can involve temporary search fluctuations. If you are still deciding whether to rebuild, start with your business goals and the scope of your web development project.
1. Separate a redesign from a URL move
Write down exactly what will change: design, hosting, content management system, domain, page paths or several of these. Changing a page's appearance does not automatically require changing its address. Keeping a useful address can avoid unnecessary migration work.
For example, an Irish trade supplier may replace its website platform while retaining its existing service and product URLs. A business combining two sites has a different problem: each useful old page needs a decision about its destination. Treat these as separate release plans with separate acceptance criteria.
2. Build a page inventory before development ends
Combine the current sitemap, a crawl of the website and landing-page reports from Search Console and analytics. Include useful pages that receive few visits but support enquiries, product instructions or existing external references. Record the URL, page purpose, search title, main heading, canonical, indexing setting and intended new destination.
Add a business priority column. A seasonal landing page may look quiet outside its trading period; a thank-you page may matter for measurement even though it should not appear in search. Do not decide a page is disposable solely because one short reporting period shows no clicks.
3. Agree the redirect map with the content owner
Map each moved page to the closest useful replacement. Review the relationship between the old promise and the new content. Sending a discontinued installation guide to an unrelated homepage gives visitors little help.
Google's site-move guidance explains URL mapping, permanent redirects and post-move monitoring. Use that guidance with your developer, and test the actual response from each important old URL. Check the final destination as well as the initial response. Record intentional removals separately so they are not mistaken for missed redirects.
4. Check indexing and page identity on the new site
Before release, compare the production plan with the staging configuration. Staging protection should not accidentally become a production-wide noindex instruction. Equally, account screens and other intentionally excluded pages should retain their exclusions.
For each priority page, confirm one clear main heading, an appropriate search title, a useful description and a canonical pointing to the intended page. Ensure internal navigation links lead directly to final destinations. Review the sitemap against the pages you actually want discovered. These are coordinated checks; changing one setting without reviewing the others can create conflicting signals.
5. Test the enquiry journey, not only the page
Open priority landing pages on a phone, follow the main call to action and submit a controlled test enquiry. Confirm that the message arrives where staff expect it and that the visitor receives a clear result. Ask who owns failed submissions after launch.
Use the accessible enquiry-form guide to review labels and recoverable errors. If submissions trigger emails, include the delivery checks in our transactional-email guide. A migration can preserve visits yet still lose enquiries through a broken handover.
6. Use a written release checklist
Before approval, record an owner and evidence for each item: priority URL responses; redirect destinations; canonicals and robots instructions; sitemap contents; mobile navigation; form delivery; analytics events; and access to Search Console. Save the baseline export alongside the release notes.
Define what would justify pausing or rolling back the launch. Examples include widespread server errors, a production-wide indexing block or failed enquiry delivery. A single day's ranking movement needs investigation, but should not automatically trigger another migration. Make sure the person monitoring the release can reach both the developer and the business decision-maker.
7. Review discovery and business outcomes after launch
Check priority URLs and the sitemap in Search Console, then monitor indexing, landing-page traffic and qualified enquiries together. Compare equivalent periods and account for seasonal changes. Separate branded searches from service searches where the data supports it.
Track any important old references that still send visitors through redirects. Where a genuine partner already references your business, prepare the relevant replacement URL for their next editorial update. Keep a record of corrections and unresolved issues rather than making repeated, unexplained changes to page titles.
Bring the checklist into your project brief
The useful deliverable is a migration register with a decision, owner and evidence for every important URL. Discuss that register with your digital marketing and SEO team before the launch date is fixed. To review a rebuild or migration with Elephantfly, contact the team with the current site, intended changes and any fixed business deadlines.
