Take a backup, change one thing, publish at a time you can watch it, walk the site afterwards, and write down what you changed. That is the whole process for one person.

A process without an environment

Advice about testing assumes a staging site, a second person to review, and a deployment process.

A great many businesses have none of those. One person makes a change on the live site, publishes it, and hopes.

That is not unprofessional, it is proportionate, and it works fine provided a few things are true.

What follows is the version of a process that fits one person and takes about five minutes around any change.

The five minutes

The first is the one that converts a mistake into an inconvenience, and it is the step people skip because nothing has gone wrong yet.

Know the undo before you start

The difference between a bad ten minutes and a bad two days.

For content, that means knowing your platform keeps revisions and where to find them.

For a plugin or theme change, it means knowing that deactivating restores the previous state, and having the previous version available where an update cannot simply be reversed.

For anything structural, it means a backup taken immediately before, not last night's.

Ask yourself the question out loud: if this goes wrong, what do I click. If there is no answer, that is the thing to arrange before making the change.

One thing at a time

The rule that makes everything else work.

Four changes published together means that if something breaks you do not know which caused it, and reversing all four loses work that was fine.

Publish one, check it, then publish the next.

That feels slower and is faster, because the diagnosis when something goes wrong is instant rather than a process of elimination.

The exception is a set of changes that only make sense together, such as a page and the navigation link to it, which is one change in two parts rather than two changes.

Timing matters more without staging

Since your test is the live site, when you publish is part of the method.

Publish in the morning of a working day, when you are around, alert, and able to fix something.

Not on a Friday afternoon, not in the evening, and not immediately before you go away, which are the three occasions when a small problem gets a long run.

Avoid your busiest hours if you know them, which for most local businesses is late morning and early evening.

And leave an hour afterwards where you are not committed to anything else, because the value of publishing when you can watch is that you actually watch.

The walk afterwards

Two minutes, and it catches most of what goes wrong.

Load the homepage, load one service page, load a blog post, and submit the contact form.

Do it on a phone as well as a desktop, since a change can look correct on one and not the other.

Check the specific thing you changed, and then check something you did not, since side effects are the reason this step exists.

Where the change involved a plugin affecting the whole site, add a check of anything interactive: a booking widget, a search box, a filter.

A short fixed list you do every time is better than a thorough check you sometimes skip.

A worked example

A sole trader updated four plugins, changed a theme setting, and edited two pages, all in one evening.

The following morning the contact form was not sending, and had not been since the previous evening.

Because everything had changed at once, finding the cause meant reversing things one at a time on the live site, with the form broken throughout.

It took most of a day and the cause turned out to be one plugin update.

Afterwards they adopted a routine: updates on a Tuesday morning, one at a time, with the contact form submitted after each.

The next time an update broke something, they knew within two minutes which one it was, and reversed it before anybody noticed.

Same fault, same site, and the difference was entirely the sequence.

Write down what you changed

The record that makes future problems solvable.

A single line per change: the date, what you changed, and why.

That takes ten seconds and answers the question that always arrives later, which is what changed around the time this started.

Problems frequently appear days after the change that caused them, particularly with anything cached or scheduled, and by then nobody remembers.

Keep it in one place, with your other operational notes, and it becomes the first thing you consult rather than a reconstruction.

Know what updates itself

The gap in this routine, since not every change is one you make.

Platforms, plugins, and themes increasingly update automatically, which means changes arrive on your site while you are doing something else entirely.

That is generally good for security and it removes the sequence control everything above depends on.

Find out what is set to update on its own, and consider switching the larger components to manual so they arrive on your Tuesday morning rather than on a Saturday.

Leave security updates automatic, since the risk of delay there outweighs the risk of an unwatched change, and make sure the notification of what updated reaches somebody who will read it.

The counter-case

Some changes should not be made on a live site regardless of the routine.

Anything touching payments, a major version upgrade of the platform, a theme change, or a migration all warrant a copy to test on, and for those the answer is to arrange one rather than to be careful.

Most hosts provide a staging environment on request or as part of the plan, which makes this a question rather than a project.

There is also a risk in over-formalising: a one-person business that builds an elaborate process will abandon it under time pressure, which is worse than a short routine that gets followed.

Five minutes every time beats twenty minutes occasionally.

The routine

  1. Answer what you would click to undo it.
  2. Take a backup for anything structural.
  3. Change one thing.
  4. Publish on a weekday morning.
  5. Walk four pages and submit the form.
  6. Check on a phone as well.
  7. Write one line about what you changed.

Step three is the one that turns a day of elimination into two minutes of diagnosis, and it is the hardest to keep to when several things are waiting.

Working with a second copy is covered in staging, production, and not mixing them up.

Frequently asked questions

Can I make changes without a staging site?

Yes, provided you know how to undo each change, make one at a time, publish when you can watch, and check afterwards. That is proportionate for a one-person business.

What is the most important step?

Knowing what you would click to undo it, before you start. That converts a mistake into an inconvenience, and it is skipped because nothing has gone wrong yet.

Why one change at a time?

Because four changes published together means you cannot tell which broke something, and reversing all four loses work that was fine. It feels slower and is faster.

When should I publish?

Weekday mornings when you are around and able to fix something. Not Friday afternoon, not evenings, and not before you go away.

What should the check afterwards cover?

The homepage, a service page, a blog post, and a form submission, on a phone as well as a desktop. Check something you did not change, since side effects are the point.

What should not be done live?

Anything touching payments, a major platform upgrade, a theme change, or a migration. Most hosts provide a staging environment on request.

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.

Several updates waiting?

Do them one at a time on a Tuesday morning, submitting your contact form after each. Two minutes of diagnosis instead of a day.

Start a Conversation