Give correction requests a clear starting point
Errors on a live website can arrive through a contact form, an email, a colleague, or a routine content check. If each report follows a different route, small fixes may be forgotten and important ones may be changed without enough context. Choose one place to record requests, even if it is only a shared list. Ask for the page address, the text or element in question, what the reporter believes is wrong, and when they noticed it.
Assign someone to decide what happens next. That person does not have to make every edit, but they should confirm the issue, identify who can check the correct information, and keep the request moving. Separate straightforward errors, such as a misspelling, from changes that could affect a reader’s decision. An incorrect service description, broken application instruction, or misleading contact detail deserves more careful review than a misplaced comma.
Avoid treating every suggested change as a confirmed error. A reader may have encountered an older version of a page, misunderstood a term, or found a genuine contradiction elsewhere on the site. Record what you can verify before changing the live copy. This short pause helps the team fix the underlying problem rather than only the sentence that drew attention.
Check the scope before editing
Find out whether the information appears in more than one place. It might be repeated in a page introduction, a reusable block, a downloadable file, a navigation label, or a translated page. Search the CMS for distinctive wording, then check related pages that a visitor might reasonably use for the same task. A correction on one page will not help much if another prominent page still gives the old instruction.
Look at what the change may affect. Editing a heading can alter a page’s outline; replacing a link can change where a button leads; removing a paragraph can leave an unexplained reference later in the page. Keep the correction as focused as possible, but read the whole section before saving it. If several pages need updates, list them in the request so they can be checked together.
Some reports involve personal information or access details rather than ordinary copy. Limit how much sensitive material you repeat in tickets or messages, and use your organization’s established process for handling it. For further browsing on related considerations, see Privacy and Security · Digital Region.
Decide whether readers need to see the correction
Many minor fixes need no public explanation. Correcting a typo that does not change meaning usually makes the page clearer without requiring a note. A meaningful change is different: readers may have relied on the previous wording, shared the page, or started a task using an outdated instruction. In those cases, consider a brief, visible note near the affected information or in a clearly labeled update area.
A useful note says what changed in plain language without reproducing unnecessary incorrect details. For example, it can explain that a page’s submission instructions have been corrected and direct readers to the current steps. Keep the note understandable to someone arriving for the first time; avoid internal ticket numbers and vague phrases such as “content updated.” If the change does not affect what readers need to do, a note may add clutter rather than clarity.
Think about how people heard the earlier message. If an organization also sent the incorrect information in an email or shared it through another channel, changing the website alone may not reach everyone affected. Plan a proportionate follow-up using the channels the team controls. For more ideas about communicating clearly across channels, browse Online Communication · Digital Region.
Publish, verify, and close the loop
Before publishing, have another person review consequential corrections when your team can manage it. Give the reviewer the original report, the proposed wording, and the list of related locations. Their job is to check both accuracy and clarity, not to restart a full rewrite. For a small fix, a quick check may be enough; for a change affecting several pages, allow time to compare them.
After publishing, open the public page rather than assuming the CMS preview matches it. Read the corrected passage in context, test any changed links, and check a narrow screen if the edit changed a button, table, or layout. Confirm that related pages and files were updated or record who will handle them. If the site uses caching, allow for the possibility that the public version may not change immediately.
Finally, close the request with a short record of what changed, where it changed, who checked it, and whether a reader-facing note was added. You do not need a lengthy report for every typo. A consistent record makes repeated mistakes easier to spot and gives the next editor a way to understand why the published wording differs from an earlier version.
