Changing a school website address: what to check first

A new school name, a trust reorganisation or a shared education project can prompt a rethink of the website address. Before approving a domain, work out how the proposed change would affect the people who use it.

Families need to reach the right information. Staff need working email and access to their systems. The useful starting point is a list of the services connected to the address, with a clear decision about each one.

Choose the address and check how to acquire it

Start with the purpose. Is the address for an individual school, the trust itself or a separate project? Consider whether a page within an existing website would meet the need before adding another domain to manage.

For a trust or education project considering an existing .uk or .co.uk name, DomainSabre's guidance on UK domain auctions explains the research and buying decisions involved. DomainSabre currently publishes guides while preparing its marketplace; auctions are not open yet.

An available name can usually be registered through a registrar. Acquiring an existing registration involves a separate transaction. Before entering a domain auction, confirm the exact name, the seller's authority, the charges and the transfer arrangements. Check its previous use and whether the wording could confuse families about who operates the website.

A .sch.uk address follows a separate school-domain process. Nominet sets school-specific eligibility and naming rules. Confirm the applicable application or change procedure with Nominet or your domain provider, including what happens to an existing school address.

Define what the change includes

Write a short description of the intended result. “Launch the school's public website at the new address” is precise enough to discuss. “Move everything to the new domain” leaves several different decisions unresolved.

Separate the proposal into:

• Public website: the address families visit and the pages they use.
• Email: the addresses staff send from and the mailboxes receiving enquiries.
• Staff identity: the names used to sign in to systems and recover accounts.
• Connected services: forms, parent apps, payment links and other tools that refer to the domain.

Ask each service owner to confirm the intended change. A new public website address does not automatically require new staff email addresses or account usernames. Record the agreed scope before commissioning technical work.

Make a service register that people can use

Bring the school office, website editor and IT support together. Each will know about dependencies the others may miss: a form notification, a supplier account or an address printed in a recurring letter.

For every relevant service, record:

• Its purpose: what a parent or staff member needs to do.
• The address it uses: a website link, email address or account identifier.
• The responsible person or supplier: who can confirm and make changes.
• The required action: what must be updated, preserved or investigated.
• The acceptance check: how someone will confirm that the service works afterwards.

Keep passwords and recovery codes out of this shared register. Record how authorised staff can obtain access through the school's approved arrangements.

For schools in England, the Department for Education's digital leadership and governance standard also supports keeping technology, contract and information records current. Use existing school records where possible, with links to the relevant contracts and support contacts.

Give email and staff sign-ins their own checks

A website redirect does not forward email or change an account username. Those tasks belong to different services and need separate decisions.

Ask IT support to review the domain's DNS settings: the records that direct services such as website traffic and email. Identify the records required for the website change and preserve those supporting other services. If DNS management is moving to another provider, the review needs to cover the complete existing configuration.

Where email addresses will change, agree how messages sent to old addresses will be handled and test both sending and receiving. Include shared addresses used for office enquiries, admissions and automated notifications.

For staff systems, ask whether the email address is a contact detail, the sign-in name or part of a central sign-in service. These uses can require different changes. Confirm the provider's process before editing accounts, particularly where access to existing files or records depends on the account identity.

Follow the whole route into parent services

A school website may link to a separate payment platform, booking service or parent app. Check the link destination and the account arrangements behind it separately.

For example, the payment service's public login page might stay the same while a school administrator's account uses an email address that is changing. A working website button would not confirm that the administrator could still sign in.

Ask the office to test the journeys families actually use: find meal information, reach the correct payment service, open a trip letter and send an enquiry. Check where form messages arrive; a success message on screen does not establish that the office received anything.

Use approved test accounts and fictional details where the provider supports them. Our school website planning guide can help identify the everyday tasks to include.

Agree the sequence before announcing the address

Set a launch window with the people responsible for the affected services. Record which preparations must be complete, who will make each change and who can authorise a pause if an essential check fails.

For the public website, map important old pages to their relevant replacements and arrange suitable permanent redirects. Follow our school website migration guide for the page-by-page work, launch checks and monitoring.

Confirm how long you can retain control of the old address and the services needed to support it. School-domain arrangements may impose conditions on an address change, so obtain a confirmed transition plan before promising that old links or email addresses will continue indefinitely.

Give families the complete new address, the date it takes effect and clear instructions for accessing parent services. Update recurring communications as well as the launch announcement.

A worked example: one new address, several decisions

This is a fictional planning example. A school adopting a new name plans to replace its public website address. The first project note says that all online services will move at the same time.

The service register reveals that office email, staff access to a parent app and automated form notifications also use the existing domain. The team agrees to launch the public website separately, with any email and account changes handled through their own approved plans.

During testing, an enquiry reaches an old shared mailbox that nobody has been assigned to monitor. The team corrects the destination and confirms receipt before launch. It also gives the office a brief explanation of which addresses families should use.

The exercise turns a vague instruction into specific actions, responsible people and evidence that each important journey works.

Keep responsibility clear after launch

Assign someone to collect reports of failed links, missing messages and account problems. Record the affected service and person responsible for resolving each issue.

Keep domain administration, renewal obligations where applicable and supplier contacts in the school's normal review process. The project is ready to close when the agreed journeys work and the people responsible can maintain them.