Broken Website Editor: What to Do When Nobody Can Update Your Site
A long-established organisation that supports patients had a website that no longer worked for its own team. The site was many years old. The page editor had stopped loading properly, and the person who looked after it was not technical. Updates that should have taken minutes were impossible, and important information sat out of date.
A broken website editor is more than an annoyance. It freezes your content, hides mistakes and stops you responding to patients. Here is how we would approach the problem, and how any clinic or organisation can get back in control.
Work out what is actually broken
Before spending money, find out exactly what has failed. Is the editor not loading, or are pages not saving? Does the problem affect every page or only some? When did it start, and what changed just before? Note error messages and take screenshots. A clear description lets a developer diagnose quickly, and prevents costly guesses.
Common causes of a broken website editor
Editors usually fail for a handful of reasons: outdated plugins or themes, a clash between two tools, a server that no longer meets the software’s needs, or a failed update. Older sites are especially exposed, because parts of the system stop working together over time. Knowing the likely causes helps you ask better questions.
Take a backup before anyone touches anything
Before any repair, make sure a complete backup of the site and its database exists, and that you know where it is stored. If something goes wrong, you can restore it. Ask your host or developer to confirm the backup works, since untested backups sometimes fail when they are needed.
Use a test copy for repairs
A safe repair happens on a copy of the site, not on the live one. The developer fixes the problem there, checks every page and only then applies the changes. This protects your visitors from broken pages, and reduces the risk of losing content while the work is under way.
Decide whether to repair or rebuild
Sometimes a repair is quick and sensible. On a very old site, a rebuild may cost less over time than patching problem after problem. Ask for both options, with costs and timescales. Compare them honestly, including how long the repaired site is likely to last and what it will cost to maintain.
Protect what already works
Whatever you choose, keep a list of the pages that bring visitors and enquiries. Preserve their content and addresses, or redirect them properly. Careless changes can erase years of search visibility. A short list of your most valuable pages guides the whole project, and stops good work being lost by accident.
Make the site easy for non-technical people
The aim is a site that an ordinary member of staff can update. Choose a simple, well-supported editor, keep the design clean and ask for a short training session and a one-page guide. If your team can change a page without fear, the site stays current, and small fixes do not wait in a queue.
Keep ownership in your hands
Make sure the organisation, not an individual, owns the domain, hosting and logins. Record who has access and review it regularly. If the person who looks after the site leaves, the rest of the team can carry on without interruption. Our article on developer dependency explains this in more detail.
Keep information accurate in the meantime
While repairs are under way, use whatever route you have to correct urgent details, such as contact information or important notices. If no route exists, add a temporary banner or ask your developer to make emergency changes. Out-of-date information erodes trust, especially for organisations that patients rely on.
Ask the right questions of a developer
When you speak to a developer, ask what they think caused the fault, how they will test the fix, how long it will take and what could go wrong. Ask whether the repair will still work after the next software update, and what maintenance the site will need. Clear, plain answers are a good sign. Vague ones suggest you may want a second opinion before you agree to anything.
Plan for future updates
A repaired site can break again if updates are ignored. Agree who applies software updates, how often, and how each update is tested before it goes live. A simple monthly routine prevents small issues turning into a crisis. Keep a short log of what was changed and when, so that anyone who steps in later can understand the history of the site quickly.
Keep your visitors informed
If the repair will take a while, tell visitors. A short notice about planned improvements, and where to find urgent information, keeps trust intact. Patients and families would rather read a brief, honest message than find outdated details. Once the work is finished, check contact forms, links and key pages carefully, since problems often appear in the parts nobody thought to test.
Check that the fix has really worked
After a repair, do not assume everything is fine. Open the editor, change a page, save it and view it on a phone and a computer. Test forms, links and images on key pages. Ask another member of staff to try as well. Problems often hide in areas nobody uses every day, and finding them early is far cheaper than fixing them after a patient complains.
A quick checklist
- Record exactly what is broken and when it started.
- Confirm a working backup exists.
- Insist that repairs happen on a test copy.
- Compare repair and rebuild options in writing.
- List your most valuable pages and protect them.
- Arrange training so your own team can make routine edits.
Our companion article on rebuilding a patient organisation website on a small budget covers the wider project, and our guide to medical website design on a budget explains how to phase the work. If you would like help, we are glad at Pulse Digital Health to talk.
Frequently asked questions
Why has my website editor stopped working?
The usual causes are outdated plugins or themes, a clash between two tools, a server that no longer suits the software, or a failed update. A developer can identify which one applies by reviewing error messages and recent changes. Recording when the fault began makes their job much faster and cheaper. Keep a note of the date the fault began and any recent changes, since that timeline helps a developer find the cause quickly.
Is it safe to fix a broken editor on the live site?
It is safer to repair a copy first. Testing on a copy lets the developer check every page and confirm nothing is lost before the changes go live. A full backup should also exist beforehand, so the site can be restored if something unexpected happens during the work. A written backup plan with a named person and a tested restore step turns a stressful problem into a routine one.
Should I repair or rebuild an old website?
It depends on the age of the site, the extent of the problems and the cost of ongoing patches. Ask for both options in writing with timescales. A repair may suit a younger site, while a rebuild often makes more sense when problems keep returning and maintenance costs keep rising. Ask each option to be priced with an estimate of how long the result should last, so the comparison is fair.
Can a non-technical person manage a website?
Yes, if the site is built with a simple, well-supported editor and the team is trained. A short session and a one-page guide cover most routine tasks, such as editing text, changing images and adding news. Keep a developer available for anything more technical. Even a one-page guide with screenshots can give a new team member the confidence to make routine updates.
How do I protect my search visibility during a repair?
List the pages that bring visitors and keep their content and addresses unchanged, or redirect them properly if they must move. Check key pages after the work and watch traffic for a few weeks. Careful handling stops years of visibility being lost by accident. Check the pages again a few weeks after launch, because subtle losses in traffic can show up slowly.
Who should own my website and domain?
The organisation itself should own them, with suppliers given access. Record who holds each login and review it regularly. That way, if a volunteer or developer leaves, the rest of the team can carry on without losing control of the site. Write the owner names next to each login in a shared, secure document so access never depends on one person.
