If your WordPress site is not working, stop making repeated live changes. First record what is broken, when it started and what changed just before it. Test the same URL from a second network, check any known host or service notices, and confirm whether you have a current backup that can actually support the recovery plan.
Your aim is not to guess the faulty plugin fastest. It is to identify the failing layer without destroying evidence or making recovery harder. A domain problem, expired certificate, full storage account, database fault and checkout-provider outage can all look like “WordPress is down” to the person trying to use the site.
If you see signs of compromise, missing data, repeated database errors, unknown file changes, payment or customer-data impact, an unavailable backup, or a change with no clear rollback, stop. Keep the evidence and involve the authorised host, developer, security responder, payment provider or Information Officer as appropriate.
What to do first when your WordPress site is not working
Start with the business impact. “The website is broken” is too broad for safe triage. The answer below changes who should act, how urgently they should act and whether production should be left untouched.
- Total outage: no public page loads for anyone.
- Intermittent failure: the site works sometimes, from some locations or only after a refresh.
- Page-specific failure: one page, template or content type is affected.
- Admin-only failure: visitors can browse, but you cannot log in, edit or publish.
- Journey failure: the site loads, but a form, login, booking, cart or payment handoff fails.
- Visual failure: content exists, but styling, images, menus or mobile layout are wrong.
Then test the exact failing URL on mobile data or ask someone offsite to open it. This matters in South Africa when an office power event, router restart, fibre fault or local ISP route can make a working public site look unavailable. If the site works offsite, investigate the local connection before anyone changes WordPress.
Preserve this evidence before diagnosis
- The exact affected URL, not just the homepage.
- The first known failure time and the last known working time, both with timezone.
- A screenshot and the exact error text or browser warning.
- Whether the failure affects desktop, mobile, Wi-Fi, fibre and mobile data.
- Whether public pages, WordPress admin, forms, checkout and email notifications are affected.
- Every recent deploy, core/plugin/theme update, PHP change, migration, DNS change, certificate event, content edit or integration change.
- Any hosting, CDN, DNS, payment-gateway or other provider status notice.
Do not crop away the address bar or rewrite an error from memory. The exact hostname, path, timestamp and message often separate a certificate problem from a WordPress problem.
A safe WordPress incident decision tree
- Can another person load the same URL from another network? If yes, treat the first report as a device, browser, local network or ISP-path problem until evidence says otherwise. If no, continue.
- Is the whole domain affected? If every page fails, include domain, DNS, SSL, CDN and hosting in scope. If one page or function fails, narrow the scope before touching site-wide settings.
- Does the public site work while admin fails? Protect the working public site. Do not turn an access problem into a public outage with broad live changes.
- Did the failure follow a known change? Record the exact change and time. A correlation gives the authorised technician a starting point; it does not prove the cause.
- Is there a safe diagnostic copy? Prefer staging or a current isolated clone for change testing. Confirm that it does not share live tables, uploads, queues or third-party credentials before treating it as isolated.
- Is the rollback clear and the backup fit for purpose? If either answer is no, stop. An improvised rollback can lose newer orders, submissions, bookings and edits.
For a stable WordPress setup, the hosting and application responsibilities should be clear before an incident. Review what your WordPress hosting environment covers and who owns core, plugins, themes, backups and integrations; do not assume one provider owns every layer.
Match the symptom to the failing layer
This map is for routing, not remote diagnosis. One symptom can have several causes, and two faults can exist at the same time.
| What you see | Layer to check first | Safe next question |
|---|---|---|
| Domain does not resolve, or different networks reach different destinations | Domain and DNS | Were nameservers or DNS records changed, and is the registration active? |
| Browser shows a certificate, privacy or hostname warning | SSL/TLS certificate and hostname routing | Which exact hostname fails, and did a renewal, migration or DNS change happen? |
| Timeout, connection refusal or 5xx error across the whole site | Hosting, server, reverse proxy or CDN | Is there a provider notice, resource event or wider service impact? |
| Old content, different results by location, or a repair visible only to some visitors | Browser, page cache, server cache or CDN | Which layer is serving the response, and was a cache rule or deployment changed? |
| “Critical error”, blank page or a named PHP fatal error | PHP/runtime, plugin, theme or custom code | Did WordPress send a Recovery Mode email, and what component and timestamp does it name? |
| “Error establishing a database connection”, failed writes or repeated database errors | Database service, credentials, capacity or integrity | Is the database service available, and did configuration, migration or capacity change? |
| One template loses styling after an update or content edit | Theme, page builder, asset delivery or page-level cache | Is the failure limited to one template and reproducible on an isolated copy? |
| Uploads fail, updates stop partway, logs cannot write or backups suddenly shrink | Storage capacity, quota, permissions or backup job | Is usable storage available, and are recent backups complete rather than merely present? |
| Pages load but forms, bookings, login or checkout fail | WordPress integration, email delivery, API, webhook, payment provider or security rule | Where does the journey stop, and is the third-party service reporting an incident? |
A certificate warning needs certificate and hostname evidence, not a plugin purge. Allanux's South African SSL certificate guide explains the certificate layer; use it for context, then let the authorised owner correct the actual renewal or routing fault.
Check the change timeline before you touch the site again
Most useful incident reports contain a boring but precise timeline. “It broke after updates” is not enough. Record which component changed, from which version to which version, who approved it, whether it ran on production or staging, and what verification followed.
Also record changes outside WordPress. A PHP-version switch can expose old plugin code. A migration can leave DNS, certificate, cache and database routes pointing at different systems. A content edit can break one layout while the server remains healthy. A payment provider can reject a checkout handoff while the cart works normally.
If there was no known change, do not invent one. Unknown file changes, new administrators, unfamiliar scheduled tasks, unexplained redirects, modified payment details or security warnings move the incident into suspected-compromise territory. Preserve evidence and involve an authorised security responder.
Confirm the backup can support the recovery plan
A successful backup notification is not proof of a successful restore. Before anyone rolls back or repairs production, confirm the recovery point, what the backup contains, where it is stored and whether a restore path has been tested.
- Does it include both the database and the required WordPress files, uploads and configuration?
- Was it created before the suspected fault or compromise?
- Is the backup complete, readable and stored away from the affected environment?
- Can it be restored into an isolated location for validation?
- What orders, form entries, bookings, comments, customer records or content edits were created after that recovery point?
- Who is authorised to accept that data-loss window?
Restoring yesterday's database over a live WooCommerce store can remove today's orders even if the homepage comes back. A repair plan may need to preserve or reconcile newer business data instead of treating a full rollback as the default.
Ongoing website maintenance should define update testing, backup ownership, restore testing and verification before the next incident. Do not buy a maintenance promise based only on backup frequency; ask how restoreability and live transactional data are handled.
When to stop and call the authorised owner
Stop owner-led troubleshooting and escalate when any of these conditions apply:
- You suspect malware, account takeover, injected redirects, unknown administrators or unexplained file changes.
- Personal information, customer accounts, order data or payment activity may be exposed, changed or unavailable.
- Orders, bookings or form submissions may be lost by a restore.
- The database reports repeated connection or integrity errors.
- No current backup exists, the backup is incomplete, or restoreability is unknown.
- The proposed change has no tested rollback or crosses domain, DNS, hosting, database and application boundaries.
- You do not know whether a staging copy is isolated from production.
- Several people or providers are making uncoordinated changes.
For a suspected personal-information security compromise, bring in the organisation's Information Officer or Deputy Information Officer and follow current Information Regulator guidance. A broken site is not automatically a POPIA reportable event, but a real compromise involving unauthorised access, loss, alteration or disclosure of personal information requires prompt assessment and the prescribed response. This article is not legal advice.
