Does a blank WordPress page mean the site has been hacked?
No. A completely white page is a symptom, not a diagnosis. WordPress commonly calls it the White Screen of Death. Its official documentation lists PHP and database errors among the causes, with plugin conflicts, theme problems, incomplete updates and memory limits as common examples.
A compromise is still one possibility. Injected PHP can stop execution, malware can damage a file, and an attacker can alter server rules. The blank screen deserves a security investigation when another warning sign appears at the same time:
- the outage began without an update, deployment or other planned change
- visitors also report strange redirects, advertisements or pop-ups
- the WordPress dashboard contains an administrator nobody recognises
- the host, a browser or Google Search Console reports malicious content
- unfamiliar URLs or topics appear in search results under the domain
- files, scheduled tasks or server rules changed without an explanation
One symptom cannot prove a compromise or rule one out. A reliable conclusion needs a timeline and corroborating evidence from changes, logs, accounts, files, database records and external warnings.
Which WordPress symptoms suggest a fault, and which suggest a compromise?
Some observations have a routine operational explanation, while others are difficult to explain without an unauthorised change. This table is a triage aid rather than a verdict.
| What you observe | Common non-security cause | Possible security cause | Priority |
|---|---|---|---|
| completely blank white page | PHP fatal error, plugin or theme conflict, memory limit | damaged or injected PHP | high if no planned change preceded it |
| “There has been a critical error” | incompatible update or extension | manipulated file or deliberately triggered failure | medium to high |
| 500 or 503 response | server configuration, overload, broken .htaccess |
malicious rules, bot load or executed malware | high when sudden |
| database connection error | database outage, full hosting account, wrong credentials | altered configuration or abused resources | high because the site is unavailable |
| redirect to an unrelated site | mistaken URL, DNS, cache or redirect rule | injected JavaScript or changed server rules | very high |
| unfamiliar Google results | forgotten test content or indexing mistake | SEO spam, URL injection or cloaking | very high |
| unknown administrator | old agency, developer or service account | attacker-created access or account takeover | very high |
| severe unexplained slowdown | hosting limit, broken plugin, external API | abusive bots, spam generation, mining or malware | high with other indicators |
The useful question is: Can the behaviour be explained by a known change and matching evidence? If a plugin was updated immediately before the outage and the error log identifies that plugin, an ordinary fault is plausible. If there was no change but new accounts and search-only redirects appeared, treat it as a potential incident.
Why does WordPress turn white or show a critical error after an update?
A compatibility or PHP failure is a common explanation after a change. A plugin may call a missing function, a theme may not support the active PHP version, or an update may have stopped halfway through. These causes are all covered in the official WordPress guidance on common errors.
Start with a short timeline:
- Did the problem begin directly after a WordPress, plugin, theme or PHP update?
- Is the public site affected, the dashboard, or both?
- Did WordPress send a Recovery Mode email?
- What error was recorded by PHP or WordPress at that exact time?
- Does an unchanged staging copy or a known clean backup behave differently?
WP_DEBUG can expose useful technical detail. WordPress advises using its debugging tools on development or staging systems rather than leaving debug output visible on a live site. Public errors may reveal internal paths and other information. On production, errors should be recorded securely and kept away from visitors.
An error message is evidence, not the full cause
A PHP log can identify where execution stopped. It does not prove why the file reached that state. Unexplained file changes still need a security check even when the immediate error is easy to reproduce.
What does an unexpected redirect to ads, gambling sites or an unrelated shop mean?
A redirect you did not configure to an unrelated domain is a strong compromise indicator. Attackers commonly inject JavaScript, modify .htaccess or other server rules, alter database values, or load code through a vulnerable extension.
The redirect may not happen for everyone. Malicious logic can target people who:
- arrive from Google or an advertisement,
- use a phone rather than a desktop computer,
- are not signed in to WordPress,
- have a particular language or network,
- visit the page for the first time.
Google notes that hacked sites may use cloaking to hide changes from the owner. A normal visit from your usual browser therefore does not disprove a customer report. There are also non-malicious explanations, including a bad domain redirect, stale cache rule, multilingual plugin error or changed DNS record. To narrow down the cause, compare what happens across devices and entry points, then check the redirect chain and relevant configuration.
Why does Google show strange text or unknown pages for the domain?
Unexpected search results often point to SEO spam or injected URLs. Common examples mention pharmaceuticals, loans, gambling, counterfeit goods or unrelated adult content. The normal home page can continue to look correct while these pages are shown to crawlers or selected visitors.
Google documents several patterns:
- text and links injected into existing pages,
- large numbers of newly generated spam URLs,
- different content for search engines and normal visitors,
- redirects that trigger only after a search click.
A site:example.com search can reveal unfamiliar results, but it provides clues rather than a complete inventory of indexed or manipulated URLs. The Security issues report in Google Search Console is more important. Google explains that its listed example URLs are samples, not necessarily a complete inventory of affected pages.
Deleting the visible spam URLs is therefore not a complete repair. The access path that created them and any persistence mechanism must also be found. Only then should a security review be requested.
How serious is a red browser warning or a “site may be hacked” label?
Treat a browser or Search Console security warning as urgent. Google distinguishes hacked content, malware, harmful downloads and social engineering. Affected pages may receive a search label or an interstitial warning before the browser opens them.
Do not repeatedly open a reported malware URL on an everyday work device. Record the warning, affected address and time. Review Search Console and alert whoever manages the site, hosting account and online store.
After cleanup, the warning may remain until Google has reviewed the site again and updated its status. Request a review only after the known causes and affected areas have been addressed.
Do unknown administrators or password emails prove a hack?
An unknown administrator represents unexplained privileged access until its owner is identified. It may belong to a former agency, host or maintenance provider. If nobody can account for it, establish when it was created, what it changed and whether other access routes exist.
Unexpected emails about password resets, application passwords or account email changes also deserve immediate attention. Removing one visible user may not remove the attacker. They may have:
- created more users or application passwords,
- taken over an existing administrator,
- left code in a plugin, theme or uploads directory,
- scheduled a task that restores access later,
- obtained hosting, database, email or domain credentials.
Our guide to unknown WordPress administrators and application passwords covers those checks in more detail.
Does a slow or unavailable WordPress site indicate an attack?
Not necessarily, although hostile activity belongs on the cause list. Hosting limits, slow database queries, a broken cache, an unavailable third-party service, DNS trouble or a faulty plugin are all common. Google lists server overload, timeouts, DNS errors and refused connections among reasons a URL can become unreachable.
A security explanation becomes more plausible when resource use rises without normal traffic, logs contain large numbers of suspicious requests, unfamiliar PHP processes run, or the site generates spam pages in the background. Brute-force attempts and aggressive bots can also overwhelm a small hosting plan without proving that a login or exploit succeeded.
The timeline matters. When did the slowdown begin? Which requests, processes and database queries were active then? What changed immediately beforehand? Restarting the server may restore availability while erasing the easiest opportunity to understand the cause.
What should you check first without destroying useful evidence?
Record and preserve before deleting plugins or restoring an old backup at random. This is particularly important while a compromise remains possible.
- record the exact message, affected URL, time and a screenshot
- check whether another device and network show the same behaviour
- write down recent updates, deployments and configuration changes
- preserve warnings from the host, browser, Search Console and security services
- retain available access, error, PHP and WordPress logs
- take a snapshot of the current state before making changes
- send only the URL and symptom at first, never passwords through a form
If the site actively redirects visitors, distributes malware or asks for credentials, temporary containment may be necessary. Balance visitor risk, evidence preservation and business impact. The first-hour WordPress incident guide provides a more detailed sequence.
How can an assessment distinguish a hack from an ordinary fault?
A sound diagnosis tests both possibilities in parallel. Looking only for malware can miss a configuration or operational failure. Fixing only the visible PHP error can miss why the file was damaged.
Depending on available access, the assessment should cover:
- availability, HTTP status, DNS, TLS and the redirect chain
- the timeline of updates, planned changes and first symptoms
- PHP, web server, access and WordPress logs
- WordPress core, plugins and themes compared with trusted sources
- users, roles, sessions and application passwords
- database content, options, scheduled tasks and server rules
- Search Console, hosting warnings and unexpected indexed URLs
- other sites and accounts under the same hosting access
A malware scanner can contribute evidence, but it is not the whole diagnosis. It may recognise known patterns and still miss a new or contextual change. See malware scanning versus forensic investigation for the practical differences.
Can we help when the website is not hacked?
Yes. The first job is to identify the real cause, not to force every outage into a security story. If the assessment finds no compromise, we can also resolve ordinary WordPress problems where appropriate. Examples include plugin and theme conflicts, PHP failures, incomplete updates, cache trouble, database errors and incorrect WordPress or redirect configuration.
The outcome should be the same in either case: restore the website quickly without overlooking follow-on damage. For an ordinary fault, we repair the failure. For a confirmed compromise, a complete WordPress cleanup also investigates scope, access path and persistence before the site returns to service.
If a store is affected, the cart, checkout, payment flow, order notes, and scheduled actions may also need review. The shop emergency support page explains which security incidents and business-critical store outages we handle and when a separate quote is required.
If you cannot tell what is behind a blank screen, redirect or warning, use the free initial assessment to send the website address, when the problem first appeared and a short description. We will assess whether the signs point more strongly to an ordinary fault or a security incident and explain the next useful step. Confirming the cause may then require technical access and relevant logs. Do not send credentials through the form. You can also use the contact page for ordinary WordPress faults.