Here’s the scenario: You have taken over responsibility for your organisation’s website. It still loads, but the handover came with a warning about changing things. Updates are waiting in WordPress, an upcoming event needs publishing, and nobody is sure what will happen if you touch the wrong setting.
So where do you start?
My starting point is to establish what the team needs to do, what the website depends on, and how you could recover a change if it goes wrong. With that information, you can agree on a safe first step with someone who understands the platform.
You don’t need to diagnose the entire website yourself. You just need enough clarity to stop every routine task becoming a judgement call about whether to risk it.
Separate Content Changes From Software Updates
“Updating the website” can mean two quite different things.
Publishing a news item changes the content. The risk is that you publish something misleading, incorrect or sensitive.
Updating a theme or plugin changes WordPress’ content presentation and functionality. The risk is that your web pages may lose their look and style, or, at a higher risk, WordPress could return an error and crash the entire website, or, at a lower risk, a feature like member registration could stop working.
These need different conversations. If staff are afraid to publish an event, I would want to understand the editing process, their access and what they have been told. If a plugin update previously stopped registrations working, I would investigate that specific failure and the systems involved.
In an organisation I worked with, the team had been advised not to touch the website, and basic publishing had stalled. That experience is a useful reminder that an online website can still be difficult for the people responsible for it to use.
The warning may have been valid. Your task is to recover that reason and find out whether it still applies. “The registration form failed after a particular update” gives a developer something to investigate.
“Everything will break” leaves the team with nowhere to start.
Write Down the Work That Is Being Held Up
Start with the tasks your team avoids or can’t complete.
Keep the descriptions in plain English: publish an event, replace an outdated document, update a member’s profile or check where a form enquiry went.
For each task, record what should happen, what happens now and who is affected. Add a page address or screenshot if useful, along with any deadline. If you have never tried the task because of the handover warning, say so. An untested concern and a known failure are different starting points.
For example, imagine a membership organisation that emails event details individually because staff are unsure how to publish them on the website. The immediate question is whether staff can safely manage events with the current setup. A new event platform might be unnecessary.
I would bring the three most important blocked tasks to the first technical conversation. They give the review a practical focus and help distinguish urgent service problems from improvements that can wait.
Gather What You Know, Including the Gaps
You don’t need a complete technical inventory before asking for help. Gather the records already available and mark anything uncertain as unknown.
- Known access: who can sign in to WordPress, and who controls the hosting and domain accounts? Record where credentials are held securely, rather than copying passwords into a shared brief.
- Support contacts: who hosts the site, who maintains it and who built or changed important features? Include the current agreement if you have one.
- Connected services: note any payment system, membership database, email platform or external forms service you know the site uses.
- Previous problems: gather relevant support emails, error messages and descriptions of changes that failed.
- Backup and recovery: record what you have been told about backups, restoration and a separate test website. Identify what still needs checking.
The reason for gathering this information is to understand dependencies. A registration form might send information to another system. Changing the form could therefore require checking more than the page visitors see.
You are supplying operational knowledge; the developer can investigate the technical connections. Avoid deactivating unfamiliar plugins simply because their purpose is unclear. If you don’t know what a plugin does, highlight it for investigation, and document the outcome.
If nobody knows who can approve work or instruct the provider, nominate someone internally to coordinate the review. I cover that wider responsibility question in my article on website governance.
Ask How Changes Will Be Tested and Recovered
Before significant software changes, I would want a clear answer about backups and restoration. WordPress’s backup guidance explains that a complete backup of a typical website requires both its files and database. Its update guidance also recommends backing up before any updates.
Ask the provider what the backup includes, how recent it is, who can restore it and whether restoration has been tested. A backup listed in a dashboard doesn’t mean it’s trustworthy without testing.
For an unfamiliar site, I would normally recommend testing major updates on a separate copy first, often called a staging site. The provider should configure it so tests can’t accidentally send real notifications, take live payments or change records in connected systems. This environment is often called a sandbox.
Testing should follow the tasks that matter to your organisation. If members register for events, check the registration, confirmation and resulting record in WordPress or any connected external systems. Often a website can deliver pages to visitors, appearing to be working, while systems in the back-end, logged-in or admin dashboard can fail.
A test copy also has limits. Ask what differs from the live website and what must be checked after a change goes live. If the site accepts grant applications or payments, agree how new activity will be protected during deployment or recovery. Restoring an older database can remove records received since that backup.
These are questions for the person managing the change. You should be able to understand their plan without doing the technical work yourself. If you can’t understand their plan, ask them to break it down into simpler instructions until you can.
Agree On a First Action and a Route Out Of the Uncertainty
Caution needs a next step. Leaving software untouched indefinitely is not a maintenance plan: WordPress’s security guidance explains why keeping the platform up to date matters.
Ask your provider to separate items that need prompt attention from changes that need further investigation. A reported security problem or an essential service already failing deserves early assessment. Less urgent improvements can follow a later, agreed plan.
A useful response should explain the specific concern, the proposed action, the checks required and who is responsible. Where there is uncertainty, ask what investigation would resolve it and when you will review the findings.
That first action could be restoring staff access to publish an event, news, or a blog post; checking a payment service; fixing member registrations; or arranging a tested plugin update. A rebuild may eventually be appropriate, but inheriting a website you don’t understand is not enough evidence to go down that route straight away.
The immediate goal is a website task your team can carry out with a known process, supported by a clear plan for the remaining issues.
Bring the Uncertainty To an Audit
If you have inherited a WordPress website and need help establishing where to start, my WordPress Platform Audit + Strategy Session is designed for that investigation.
For AUD $795, I review the platform before a 90-minute strategy session, then provide a structured summary and prioritised next steps. We can use your blocked tasks, known access, support contacts and unanswered questions to focus the discussion on what your organisation needs.
If you are unsure whether it is the right fit, contact me for a free 5–10 minute clarity call. You don’t need to untangle the whole website before we speak.
