Keeping online information useful means noticing when the world around it has changed.
By Arbab Naseebullah Kasi, Chief Executive Officer - CEO, Feel Worldwide Foundation Inc.
A copper leaf-shaped weather vane rises above layers of seasonal leaves, a reminder to notice when conditions change.
An address can be perfectly legible and still send someone to the wrong place.
So can an opening time, an application deadline or a cheerful invitation to a programme that ended months ago. The writing may be clear. The design may be attractive. Yet the person relying on the page is left to discover that its connection to the present has quietly broken.
Consider an illustrative example. A resident finds a community organisation's page offering Saturday advice sessions. They arrange transport and set aside the morning. The sessions have moved to another building, but the original page still appears in search results. The organisation knows about the move. Its website does not.
The cost of that gap falls on the person who trusted the information.
Keeping a website current can sound like a small administrative duty. For the reader, it is part of whether a service works. A useful page needs care after the excitement of publishing has passed.
Begin with what someone might do next
Some pages describe ideas. Others help people make decisions that affect their time, money or access to support. A thoughtful maintenance routine starts by recognising the difference.
Ask what a reader might do because of each page. Travel somewhere? Submit an application? Bring documents? Pay a fee? Decide they are ineligible and stop looking?
Those actions help identify which details deserve attention first. An outdated introduction may be mildly confusing. An incorrect closing date can remove an opportunity altogether.
For a small organisation, a useful starting list might include contact details, locations, opening hours, prices, eligibility, booking instructions and any promises about what will happen after someone applies. This is a practical suggestion rather than a universal ranking. The right order depends on the service and the consequences of an error.
GOV.UK's guidance on managing existing content treats maintenance as continuing work: monitor whether content is useful and findable, correct errors and broken links, update information, and consider retiring material that has become outdated. Its publishing tools can also identify pages overdue for a scheduled review. That is a public-sector publishing approach, not evidence that a particular review timetable will work everywhere. Read the GOV.UK content-maintenance guidance.
A small team can borrow the underlying discipline without copying the whole system. Start with the pages people depend on most.
Let each date mean what it says
The date a page was first published, the date its wording changed and the date somebody checked its facts describe different events.
Keeping those meanings clear helps avoid false reassurance. Correcting a spelling mistake does not establish that the address, fee and eligibility details are still right. Opening a page in the editor does not mean it has been reviewed.
The NHS digital service manual makes this distinction explicit. Its review-date pattern is for situations where users need to know when the whole page was checked and when another check is due. It says not to use the pattern when only part of a page has changed without a full review. It also notes that the pattern has not been tested in forms. These are instructions for that design system, not a requirement to place identical labels on every website. See the NHS review-date pattern.
The broader lesson is simple: describe the work actually done.
For an illustrative service page, “Opening hours confirmed on 4 November 2026” makes a narrower claim than “Page reviewed on 4 November 2026.” Either can be useful if accurate. The first should not quietly stand in for the second.
A review date is also a record, not a guarantee. A page checked yesterday can become wrong today if a venue closes unexpectedly. Readers still need important changes to reach the page promptly.
Give the page a responsible person
“The website team will handle it” can leave an awkward gap between the person who knows a fact has changed and the person who can edit the page.
Make the connection explicit. Who confirms the information? Who can publish the correction? Who covers the task when that person is away?
In a small team, one person may do all three jobs. In a larger organisation, the responsibilities may sit in different departments. What matters is that a change has a clear route from the real service to the public description.
A modest internal list can hold the page address, its purpose, the person responsible, the source used to verify it and the next review point. Keep it short enough that someone will maintain it.
The source matters. A copied paragraph from another page may simply repeat the same old mistake. For opening hours, check with the team operating the service. For an application deadline, check the current programme instructions. Where specialist judgement is required, involve the appropriate expert.
The NHS standard for creating health content, for example, includes a planned review cycle and clinical approval within its checking process. That health-specific responsibility cannot be replaced by a general editor's confidence. The useful wider principle is to match the review to the subject. Read the NHS content standard.
Use both a calendar and a change signal
A scheduled review catches information that has been neglected. A change signal catches information that becomes wrong before the scheduled review arrives.
Both are useful. Neither does the other's whole job.
In an illustrative community programme, the page might be checked before registration opens and after the closing date. Separately, any change to the venue, cost or booking route would trigger an immediate check of the affected details.
There is no need to inspect every page at the same frequency. An organisational history and a page listing this week's opening hours have different needs. Choose review points by asking how quickly the information can change and what happens if someone acts on an error.
A reminder helps only if someone has time and authority to respond. If the list repeatedly becomes overdue, narrow the workload, share responsibility or reduce the amount of duplicated information being maintained. Quietly changing the review date without doing the review hides the problem.
The routine should fit the team's capacity while making its limits visible.
Follow the information beyond the main page
A correction may need to travel further than expected.
The same detail may appear in a downloadable leaflet, an event listing, a translated page, a partner's directory and an old social post. Fixing the homepage can leave several competing versions in circulation.
Return to the illustrative advice-session move. The responsible person could search the organisation's own material for the old address, update the current service page and replace the downloadable leaflet. They could ask the partner maintaining the directory to correct its listing. If existing bookings are affected, the team would also need an appropriate way to inform those people directly.
That last step matters because a website correction cannot reach everyone who already saved the old details.
Where possible, keep changing operational details in one maintained location and link other material to it. Sometimes a printed leaflet must include an address or timetable. In that case, give it a date and a clear route to current information. Do not assume a link makes old instructions harmless.
Check where a link leads, too. A link that opens successfully may still land on last year's application round. Technical availability and useful information are separate things to inspect.
Give old information an honest place to live
An old page may still have value. It can explain what happened, preserve a public record or help someone understand a previous programme. Its age alone is not a reason to erase it.
The important distinction is between historical information and an active invitation.
A past event page can say that the event has ended. A closed application round can point to current opportunities, if there are any. A discontinued service page can explain the closure and provide a relevant next step rather than leaving a live-looking booking instruction behind.
GOV.UK distinguishes withdrawing content, which keeps it online with an explanatory banner, from unpublishing it. Its guidance also warns that withdrawn content can remain discoverable through Google, and that links elsewhere are not automatically removed. Those details describe GOV.UK's system, but they illustrate why changing a page's status does not necessarily end its public life. Read the guidance on retiring outdated content.
Before removing material, consider its recordkeeping purpose and the organisation's retention requirements. Where an old page remains, help the reader understand its status without needing to inspect a small date at the bottom.
Do not give an old page a new date for appearances
A recent-looking date can suggest attention that the content has not received. Resist the temptation to refresh it merely because an older date seems less impressive.
Google's documentation asks publishers to label visible publication or update dates clearly and keep them consistent with equivalent structured data. It also says those dates should describe the page's publication or update, rather than the date of an event mentioned on it. Providing that information does not guarantee that Google will show a date in search results. See Google's publication-date guidance.
For a reader, the underlying value is honest context. If a substantial correction changes what they should do, a brief explanation can be more helpful than a fresh timestamp alone.
For example, an illustrative update note might read: “The Saturday session now takes place at the new venue. Booking arrangements are unchanged.” That tells someone who read the page earlier what deserves their attention.
Make the next correction easier
People using a service sometimes notice stale details before the organisation does. Give them a clear way to report a problem, and make sure the report reaches somebody who can investigate it. Avoid promising a response time the team cannot sustain.
The aim is not to maintain a perfect-looking website. It is to make fewer people carry the burden of its mistakes.
Choose one important page today. Read it as someone preparing to act. Check the details against the service as it operates now. Notice the other places those details appear. Then decide who will check again, and what changes should prompt an earlier correction.
A useful website stays connected to the people and activities it describes. The date on the page is a small part of that connection. The care behind it is the part that makes it worth trusting.

