Urgent WordPress help when the site cannot wait

Is this the situation?

• The site will not load, or every page is blank and white.
• WordPress shows “There has been a critical error on this website”.
• The page reads “Error establishing a database connection”.
• You are locked out of wp-admin, or the login loops back to itself.
• An update broke the layout, the editor, or a plugin you depend on.
• Customers cannot check out, or orders stopped arriving.
• The site redirects somewhere else, or a browser warns visitors away.

All seven look like emergencies from the outside. In fact they have different causes, different risks, and different first moves. That is why urgent WordPress help starts by naming the fault rather than by reaching for a fix.

Before changing anything

In the first hour, urgent WordPress help is mostly restraint. Three actions cause most of the irreversible damage, so avoid all three until you understand the risk.

• Do not delete files or run an unfamiliar repair tool. A deleted file is also deleted evidence.
• Do not trigger a one-click restore until the risk to newer orders and submissions is understood. A restore rolls the database back too, so yesterday’s snapshot can erase today’s sales.
• Do not disable everything at once. Changing many things together destroys the evidence that identifies the cause, so the site comes back without anyone knowing why it broke.

Preserve what you can see instead. A screenshot of the exact error, with the time on it, is worth more than a paraphrase later.

What the screen is actually telling you

The wording on the page narrows the cause more than most people expect. So read it before you act.

• A blank white page. Usually PHP stopped mid-request with error display switched off. The cause is normally a theme or plugin file, sometimes an exhausted memory limit.
• “There has been a critical error on this website”. The same class of failure, caught by WordPress itself. It also means WordPress has tried to email you a recovery link.
• “Error establishing a database connection”. PHP is running, but MySQL is refusing or unreachable. This one is frequently the host, not the site.
• A 500, 502, or 503 from the server. The request never reached WordPress cleanly, so look at the server, the PHP worker pool, or a proxy such as Cloudflare before touching plugins.
• “Briefly unavailable for scheduled maintenance”. An update stopped halfway and left a .maintenance file behind in the site root.
• An unexpected redirect or a browser warning. Treat this as a compromise until proven otherwise, and read the exception below first.

The one exception: an active compromise

If the site is redirecting visitors, serving spam, or has been flagged by a browser or your host, the priority order changes. Containment comes first, and cleaning comes later.

In that case, change your hosting and email passwords, and go to hacked site recovery rather than working through the general checks below. The first-hour checklist for a hacked site sets out what to preserve before anything is removed.

Recovery Mode: the way back in that WordPress gives you

When a fatal error is caught, WordPress emails the administrator address with the subject “Your Site is Experiencing a Technical Issue”. That message contains a recovery link, and it is the fastest legitimate route back into wp-admin.

The link opens the dashboard in Recovery Mode with the failing plugin or theme paused, and it names the file that threw the error. Consequently you often learn the cause and regain access in the same click, which sometimes removes the need for urgent WordPress help altogether. The link expires, so use the most recent email rather than an older one.

If that email never arrived, the site probably cannot send mail at all, which is its own fault worth reading about in WordPress emails not sending. In that case the remaining route is file access over SFTP or your host’s File Manager, where renaming a single plugin folder disables that plugin without deleting anything.

Safe checks you can run yourself

A few checks are reversible, and each one narrows what urgent WordPress help would otherwise have to look at. First, open the site in a private window, because a cached or logged-in view can hide the real state.

Then check whether your host reports an outage or has suspended the account, since that answers the question immediately. Next, note whether the failure affects every page or only one, because a single broken page and a site-wide failure have almost nothing in common.

Also try /wp-admin directly. A dashboard that still loads while the front end is blank points at the theme or at a front-end plugin, and it leaves you far more room to work. The WordPress troubleshooting FAQ covers these standard first checks in general terms.

What we do not suggest is switching on debug output on a live site. WP_DEBUG writes useful detail, but with WP_DEBUG_DISPLAY left on it prints file paths to every visitor. If it is used at all, it belongs in the log file rather than on the page.

If money is moving, start at checkout

A store that loads fine but cannot take payment is an emergency with a shorter fuse than a blank page, because the loss is measurable per hour. So the money path is walked in order: cart, checkout, the payment call, the order record, then the confirmation email.

Note whether any payments were actually taken while the failure was live, since that decides whether this is a repair or a reconciliation. WooCommerce checkout not working walks the same path step by step, and WooCommerce support covers how that work is run.

What to record while it is happening

• The site address, and the exact page where the problem appears.
• What is visible, quoted exactly, and roughly when it began.
• Recent updates, plugin changes, or hosting changes.
• The host, if you know it.
• Whether money is involved: are orders failing, or were payments taken.
• Who else has touched the site recently, including other agencies.

Do not include credentials. Nothing in that list requires a password, and a safe process will not ask for one in a first message. The rules on that are published under access and security.

How urgent WordPress help is actually run here

1. Confirm the incident is in scope, before any access is requested.
2. Agree the minimum necessary access through a safe method.
3. Find the cause, rather than the first plausible explanation.
4. Agree the change and the rollback plan together.
5. Implement, verify the original fault and the paths around it, then document the result.

That sequence is set out in full under how the work runs. It does not change because a situation is urgent, since skipping the diagnosis is what turns a one-hour incident into a three-day one.

No response time is promised, here or anywhere on this site. None is currently measured, so printing one would be marketing rather than a commitment. If a stated response window is what you need, that is a fair reason to choose a provider who publishes one and means it.

Not sure the site is even WordPress?

Plenty of people arrive here in the middle of an outage without knowing what the site is built on, because the person who built it moved on years ago. That is a fair position to be in, and it is worth two minutes to settle before you spend money anywhere, since the answer decides who can help you at all.

Three checks, in order, and none of them require access to anything.

1. Try the login address. Add /wp-admin to your domain. A WordPress login screen is close to conclusive. An error or a redirect somewhere unrelated is a strong signal it is something else.
2. Look at the page source. View source and search for wp-content. WordPress sites reference that path in nearly every stylesheet and script URL, and it survives most themes and caching layers.
3. Check who you pay. A monthly bill to Wix, Squarespace, Shopify or GoDaddy Website Builder usually means the platform is theirs rather than yours, and your fastest route is their support channel, not ours.

If those checks say WordPress, everything above this section applies and you can describe what is broken.

If they say something else, we are not the right people and we would rather say so now than after you have paid for a diagnosis. We work on WordPress and WooCommerce only, and we do not take on Wix, Squarespace, Shopify, Drupal or Joomla repairs. On a hosted builder your realistic options are that platform’s own support, which is the only party with server access, or an independent who specialises in it. Meanwhile the general advice above still holds: stop changing things, write down what you did and when, and do not let anyone restore over your only copy.

One exception worth knowing. If the site turns out to be on another platform and the reason you are here is that it keeps failing, moving it is a separate decision from fixing today’s outage and should not be made during one. That is covered on moving to WordPress from another platform when the fire is out.

What urgent WordPress help cannot fix

Some outcomes are not available at any price. Data that no longer exists anywhere cannot be recovered, and no amount of urgency changes that.

A failed server or a suspended hosting account is your host’s to fix, although the evidence for escalating it can be assembled quickly. Equally, some sites need rebuilding rather than repairing, and hearing that early is cheaper than discovering it after a day of billable effort.

The service scope lists every exclusion in full, so it is worth two minutes before you commit to anything.

Where to go next

If you want urgent WordPress help now, describe what is broken and stop changing things while you wait. If you would rather work through it yourself first, the guides below cover the four failures behind most emergencies.

• The WordPress white screen of death, and how to tell which cause you have.
• Recovering from a failed WordPress update, including stuck maintenance mode.
• A site that went slow after an update, measured before it is changed.
• The first hour of a suspected compromise.

Once the immediate risk is contained, WordPress support is the general starting point, and maintenance plans exist to make the next emergency less likely.