A Website Content Update Process for Business Changes

Update because something changed

A business website is an operating document. Its service description, hours, contact routes, and pricing explanation can become wrong even when the design still looks current. Maintenance should begin with those facts rather than a desire to display a recent date.

Distinguish a review from a revision. A review asks whether information is still correct. A revision changes the public content because something material needs correction or improvement. Record both internally, but do not imply that an unchanged article has been newly rewritten.

Profound's work on citation decay examines how citations change over time. It is a useful reason to observe sources repeatedly. It does not establish a universal expiry date for every business page, or prove that refreshing a date restores a lost citation.

Assign owners to facts, not just pages

The website editor may know where to change a price but may not have authority to set it. Make that distinction explicit. The person responsible for the business fact should approve the change; the editor should implement it and verify the public result.

The examples are prompts for assigning responsibility, not a claim that every business needs all these channels. Keep the matrix limited to destinations your business actually uses.

Keep a small change log

A useful record includes the old fact, the approved new fact, the reason, the approver, the affected URLs, and the completion date. Add a verification field so “edited” and “checked live” are not treated as the same state.

For example, a fictional tutoring service stops offering weekend sessions. The owner approves the change. The editor updates the service page and FAQ, checks a booking profile, and confirms that the contact instructions no longer promise weekend availability. The log records any external listing that still needs correction.

If the change is temporary, record an end date and the intended follow-up. A seasonal notice without an owner can remain online long after the exception ends. A recurring review can catch these cases, but it should supplement the change process rather than replace it.

Historical change record from this site’s review

These records concern FoundUp’s own website. They separate implementation, production verification and search outcomes. They do not claim a client benefit, a crawler visit or an increase in citations. The timestamps identify the reviewed versions, not the latest state indefinitely.

For your own log, add an accountable business approver and a live-check date when available. Leave those fields pending until they exist. A deployment is the point to verify the public URL again, rather than copy a local pass into the production column.

Decide what to do with an old page

Ask whether the page still serves a distinct customer need. If it does and the facts remain correct, preserve it. Improve a weak explanation when there is a real gap. If two pages now answer the same question with overlapping content, consider consolidating them into the more useful destination.

When a service ends, decide whether customers still need an explanation. A clear notice with an appropriate next step may be useful. If the page is removed, use the correct response and update internal links. If there is a genuine replacement, a direct permanent redirect can help visitors reach it.

Do not redirect every missing page to the homepage merely to avoid errors. The destination should match the user's likely intent. Maintain a record of route changes so old campaign links and downloadable documents can be checked.

Investigate a lost citation before rewriting

Start with the observation: which prompt, platform, date, and URL changed? Confirm that the new test used comparable conditions. Then check whether the original page still loads, contains the relevant facts, and is linked from the site.

Next inspect the answer's current sources. Another page may answer the question more directly, or the system may have interpreted the question differently. That can suggest an improvement, but it does not prove your content is obsolete.

After publishing, verify the response, visible dates, metadata, and related discovery files. Keep the original publication date and change the modification date when a material revision warrants it. Use the business fact record and AI answer correction process to connect maintenance with actual information quality.

Follow-up: the reviewed pages were available online

At 07:42 UTC on September 29, 2026, a public check found all 25 canonical pages accessible with HTTP 200. The ten article routes and six comparison routes that previously returned 404 were available. All 25 normalized main texts matched the reviewed local build. This completes the publication follow-up for the earlier route failures; it does not establish indexing or AI citation.

See the website audit follow-up for the before-and-after observations. The older rows above describe what remained to be done at their recorded times; they are not a current incident list.