Moving a school website without losing useful links

Treat the old site as a collection of addresses

A migration is more than replacing the homepage. Families may have saved a term dates page, search engines may know a policy document, and newsletters may contain links several years old. Record public page and file addresses before changing the site.

Gather the old sitemap, navigation, important downloads and any available search or server reports. Include links from printed material and regularly used parent communications. When data is incomplete, start with the addresses most likely to serve an ongoing need and make missing-address monitoring part of launch.

Map each useful address to a destination

Build a table containing old address, new destination, reason and test result. A direct replacement should receive a permanent server-side redirect. When several genuinely overlapping pages become one guide, map them to that guide. Do not assume the homepage is an appropriate destination for everything.

If a document has been withdrawn and has no equivalent, use a useful missing-page response with navigation. Redirecting unrelated material can confuse visitors and may be treated by search engines as a soft 404. Google's site migration guidance emphasises a URL mapping and monitoring; no migration can promise unchanged rankings.

Keep domain and email responsibilities clear

Identify who controls the domain registration, DNS zone, hosting account and email service. Record the existing configuration before making changes. Moving a website does not normally require changing every DNS record: mail routing, email authentication and other subdomains may support separate services.

Write a change plan that names the exact records to change and the services to verify afterwards. Have access recovery available before the launch window, not while the old administrator is on leave. Confirm renewal responsibility for the domain and certificates as part of the handover.

Prepare a protected staging site

Use a staging environment to review the new site with realistic content. Restrict access appropriately and prevent accidental indexing. Do not place real pupil records in a public test form or copy unnecessary personal information into a development environment.

Before launch, check that production settings will replace staging settings. Important pages should use the correct public domain, intended canonical addresses and suitable indexing directives. A site can look finished while still telling search engines not to index it.

Test the things visitors actually use

Check the homepage, main navigation, search, contact information, forms, downloads and essential parent journeys. Test both a phone-sized display and keyboard operation. A contact form needs a real delivery test and an understood recipient; a success message alone does not prove that anyone received the enquiry.

Test each high-priority old address and follow its response through to the final page. Look for redirect loops, multiple unnecessary hops and destinations that no longer contain the expected information. Check both common hostname variants and the intended HTTPS behaviour.

Agree a launch window and rollback conditions

Choose a time when the people responsible for content, DNS and hosting can respond. Avoid an admissions deadline or major school event when practical. Decide what would justify reverting, such as widespread service failure, and what can be corrected while the new site stays online.

Keep a restorable copy of the old application, content and relevant configuration for an agreed period. Confirm that the old hosting arrangement will remain available long enough for the rollback plan to be meaningful. Do not cancel access before confirming that all necessary material has been transferred.

Check immediately after launch

Verify the production site from outside the school network. Confirm certificate validity, contact details, forms, important downloads and redirects. Remove any temporary launch barriers only when the public configuration is ready. Check that internal links point to the intended live addresses.

Create an issue list with severity and owners. Fix broken essential journeys before cosmetic changes. Inform the office of known issues and the fallback instructions they can give families while a correction is being made.

Monitor the following weeks

Review missing-page reports and search performance for useful old addresses you did not discover earlier. Add precise redirects only when a relevant replacement exists. Keep an eye on outdated indexed documents and accidental duplicates.

Ask staff whether repeated enquiries reveal missing content. The migration is complete when the new site can be maintained reliably, essential journeys work and the people who run it understand ownership, recovery and content review. Use the content audit guide to sustain that work after the launch project ends.