Why communication matters during a website restoration
When a site changes, users do not need a project report. They need a plain answer to three questions: what is changing, when it affects them, and what they should do next. A clear communication plan reduces confusion, lowers support volume, and keeps small issues from becoming public mysteries.
A useful default is simple: say less, say it earlier, and repeat the parts that affect users directly. That is not dramatic; it is governance.
Define your audiences first
Not every audience needs the same level of detail. Split communication by decision need, not by org chart.
| Audience | What they need | Best channel |
|---|---|---|
| Existing users and customers | What changes in the interface, forms, or checkout flow | Banner, email, help center, FAQ |
| Prospects | Whether key pages and forms still work | Homepage notice, FAQ, contact page |
| Internal teams | Launch timing, rollback conditions, escalation path | Project brief, shared checklist, live status thread |
| Third-party partners | URL changes, integration timing, and test windows | Direct email, partner note, API or integration update |
If you need a simple place to point people, use your contact page for support questions and keep the about page focused on the broader mission, not project noise.
Choose a communication cadence
A reasonable default cadence is pre-change, during change, and post-change. The exact timing depends on risk and audience impact.
- Pre-change: 3 to 7 days before the update for visible changes; 24 hours before for low-risk updates.
- During change: publish a brief status note when the change starts, then update again only if timing, access, or risk changes.
- Post-change: send a confirmation within a few hours if users may need to relearn navigation, update bookmarks, or recheck forms.
For broader context, the Nielsen Norman Group’s guidance on redesign communication is a useful reminder that change is a usability issue, not only a design issue. You can also compare rollout practices with MDN’s update guidance for web apps and the plain-language update notes used by Google Search Central when site changes affect discovery.
What to communicate for each change type
| Change type | What to tell users | Watch for |
|---|---|---|
| Navigation updates | Where common pages moved and how to find them faster | Broken bookmarks, old menu labels, search frustration |
| URL changes | Which links changed, what redirects exist, and whether users need to update saved links | Shared links in email, partner references, and documentation |
| Checkout or form changes | Which fields changed, what validations are new, and where to get help if submission fails | Abandonment, error messages, duplicate submissions |
| Performance changes | Whether pages may load differently and which actions may temporarily feel slower | Timeouts, mobile friction, support questions about slowness |
If the change affects search visibility or URL structure, give partners and internal teams a reference note. A concise explanation with examples is usually enough. A spreadsheet full of hope is not a strategy.
Message templates you can copy
Short banner text
Heads up: We are updating the site on [date]. Key pages and forms will still be available, but some links or labels may move. Check this page for the latest details.
Email update
Subject: Upcoming website changes on [date]
Hi [first name],
We are making a few changes to the website on [date and time]. The goal is to make it easier to find information and complete common tasks.
What is changing:
- [navigation update]
- [URL or page move]
- [form or checkout update]
What you may need to do:
- Update any saved links if a page moved.
- Recheck any form submissions if you see an error.
- Contact us if something looks wrong.
If you have questions, reply to this email or visit our contact page.
FAQ entry
Will I lose access to my account or saved information?
Usually no. If any data entry flow changes, we will say so before the update and note whether you need to repeat a step or confirm a setting.
FAQ structure: the questions that prevent confusion
Use 8 to 12 questions. Keep them specific. The point is not to sound complete; the point is to answer the questions people actually ask.
- What is changing?
- When will the change happen?
- Will the site be unavailable?
- What pages or tools are affected?
- Do I need to update bookmarks or saved links?
- Will forms, checkout, or account actions still work?
- How will I know the update is finished?
- Who should I contact if something looks wrong?
- What happens if a step fails?
- Will there be more updates later?
For a public-facing site index, keep readers oriented through the blog if you want a place for ongoing updates, and use the home page for the shortest path back to core content.
How to handle incidents
When something breaks, the message should do four things: acknowledge the issue, name the impact, give the next update time, and state the owner. Avoid speculation. Avoid decorative optimism. Both tend to age badly.
Incident note template: We are investigating an issue affecting [page or feature]. Some users may see [symptom]. The next update will be posted by [time] and owned by [team or person].
Assign one owner for updates. Not a committee. A committee can review the wording later; it should not be responsible for the wording now.
Measurement: improve the next message
After each update, review three signals:
- Support tickets: Did questions drop, shift, or repeat?
- Form errors: Did validation issues increase after the change?
- “Contact us” reasons: Are people confused about timing, access, or navigation?
Use the results to adjust your next notice. If the same question keeps appearing, the message was not clear enough, even if it was technically correct.
Quick checklist before publishing
- State what is changing in one sentence.
- Include a date or time window.
- Explain who is affected and who is not.
- Add one clear next step for users.
- Link to the right support page.
- Confirm the FAQ answers the top expected questions.
- Assign one owner for incident updates.
- Review the message once for jargon, then remove the jargon that survived anyway.
For readers who want broader site context, link back to the about page and keep the contact page visible wherever the change could affect completion or trust.
Bottom line
During a website restoration, communication is part of the work, not a postscript. Give each audience the minimum they need, publish on a predictable cadence, and keep the templates short enough that someone will actually use them.