Diagnosing a broken site starts with what changed and when. Without a record, that question is unanswerable and the work becomes guesswork. A simple log kept by whoever makes changes converts most incidents into a quick reversal.

The question that cannot be answered

Something stops working. Enquiries stop arriving, a page displays wrongly, or the site slows down.

The first useful question is what changed and when, because the answer usually is the cause. Software rarely breaks spontaneously; it breaks after something.

Most small businesses cannot answer it. Several people can make changes, updates apply automatically, and nobody records anything. So the diagnosis starts from nothing and takes hours instead of minutes.

What actually changes on a small business site

More than owners realise, which is why the record matters.

That last category catches people out. A tracking script or an embedded widget can change what it loads without you touching anything, which produces a site that broke with no local cause.

The simplest useful version

A shared document. Date, what changed, who made the change.

Three columns, one line per change, taking about ten seconds. Not a project management system, a text file or a spreadsheet that whoever touches the site adds to.

That alone answers the question in most incidents, because the change list for the previous week is short and the culprit is usually on it.

It also survives staff changes and supplier changes, which is where undocumented knowledge is usually lost.

What the platform already records

Worth knowing before building anything, since some of this exists.

Most content systems keep revision history for pages, showing who edited what and when, and allowing a previous version to be restored. That covers content edits entirely and many businesses have never opened it.

Update logs record which plugins and components were updated and on what date, which covers the automatic changes.

Server logs record errors with timestamps, which is how you correlate a break with a change.

Between those three, a good deal is already recorded. The gap is settings changes and anything done outside the system, which is what the manual log is for.

Version control proper

For a site with a developer or any custom code, this is what they should be using.

It records every change to every file, with who made it and why, and allows any previous state to be restored precisely. That is a different level of rigour from a change log and it is standard practice in development.

For a business owner the relevant questions are whether the developer uses it, whether you have access to the repository, and whether it is included in a handover. A site whose history lives only on one person's laptop is a dependency worth removing.

Where a site is built from a content system with no custom code, this is generally not needed, and the change log plus the platform's own history is sufficient.

Before making a change

Two habits that turn an incident into an inconvenience.

A backup immediately before, particularly before an update. That is the reversal mechanism when the change turns out to be the problem.

One change at a time, where practical, so a problem is attributable. Updating twelve plugins simultaneously and finding the site broken means testing twelve possibilities.

Neither is difficult and both are skipped under time pressure, which is exactly when the incident happens.

When something breaks

  1. Check the change log for the previous few days.
  2. Check the update history for anything automatic.
  3. Check the error log for the timestamp when it started.
  4. Reverse the most likely change and see whether it resolves.
  5. Record what it was, so the same thing is recognised next time.

That sequence takes minutes where the records exist and hours where they do not, which is the entire argument for keeping them.

The handover case

Worth mentioning because it is where the absence hurts most.

A new supplier taking over a site with no history has to reverse-engineer what was done and why. Every unusual configuration is a mystery, and the safe assumption is to leave things alone, which means problems persist.

A change log handed over with the site turns that into a briefing. It is one of the cheaper things to maintain and one of the more valuable to receive, and it belongs alongside testing changes somewhere safe first, as covered in updating a site without breaking it.

Frequently asked questions

Why does tracking changes matter?

Because the first question when something breaks is what changed and when, and the answer is usually the cause. Software rarely breaks spontaneously.

What is the simplest useful record?

A shared document with three columns: date, what changed, who changed it. Ten seconds per change, and it answers the question in most incidents.

What does the platform already record?

Most content systems keep page revision history, update logs record which components were updated and when, and server logs record errors with timestamps.

Do I need version control?

For a site with custom code, your developer should be using it, and you should have access to the repository. For a content system with no custom code, a change log is sufficient.

What should I do before making a change?

Take a backup immediately before, and make one change at a time where practical so a problem is attributable rather than one of twelve possibilities.

Why does this matter at handover?

A new supplier with no history has to reverse-engineer what was done and why, so the safe assumption is to leave things alone and problems persist.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Site broke and nobody knows what changed?

We set up the record that answers it in minutes, and check what your platform is already logging that nobody has looked at.

Start a Conversation