Your site was fine yesterday. Today, visitors see a Cloudflare error page with a number on it: 520, 521, 522, 524 or 525. Sales stall and your phone starts ringing.

These errors look alarming, but they’re far more specific than a generic “site down” message. Each code tells you where the connection broke, and that makes them quick to fix once you know how to read them. This guide explains what each one means, how to find out whether the fault is yours or Cloudflare’s, and what to do next.

First: Where Is the Problem?

When you use Cloudflare, visitors don’t connect directly to your server. They connect to Cloudflare, and Cloudflare connects to your server, known as the origin. Errors in the 520 to 527 range almost always mean the link between Cloudflare and your origin has failed, not that Cloudflare itself is down.

The error page helps you confirm this. It usually shows three stages: your browser, Cloudflare and your host. The stage marked with an error tells you where the problem sits. If the host stage is flagged, the issue is on your origin server, and that’s the case for most of the errors in this guide.

Every error page also shows a Ray ID, a unique reference for that request. Write it down, because it’s what Cloudflare support will ask for.

A Quick Diagnostic Before You Dig In

Two checks save a lot of time.

Test the origin directly. Bypass Cloudflare by reaching your server by its IP address, or temporarily set the DNS record to “DNS only” (grey cloud). If the site fails here too, the problem is your server, not Cloudflare. If it loads fine, the problem is in how Cloudflare and your origin connect.

Check whether your server is actually running. Look at your hosting control panel, server status and recent resource usage. A crashed web server, a full disk or an overloaded CPU explains many of these errors on its own.

Error 520: Web Server Returned an Unknown Error

What it means: Your origin server accepted the connection but sent back something Cloudflare couldn’t understand, such as an empty response, a crash or a malformed reply.

Common causes:

• The web server or application crashed while handling the request
• A PHP or application error producing an empty or broken response
• Oversized response headers, such as too many cookies
• Your server resetting the connection, sometimes because a firewall or security module is interfering

How to fix it:

1. Check your server error logs at the time of the failed request. They usually name the cause.
2. Look for application crashes, memory exhaustion or PHP fatal errors.
3. Test the origin directly (see above) to confirm the fault sits there.
4. Review security modules or firewall rules that may be dropping Cloudflare’s requests.
5. Check for unusually large cookies or headers if the error appears only for some visitors.

Error 521: Web Server Is Down

What it means: Cloudflare tried to connect to your origin and the connection was refused. In most cases, the server isn’t accepting connections at all.

Common causes:

• The web server (Apache, Nginx or LiteSpeed) is stopped or has crashed
• The server is offline
• A firewall or security tool is blocking Cloudflare’s IP addresses
• The origin isn’t listening on the port Cloudflare expects

How to fix it:

1. Confirm your web server is running and restart it if it isn’t.
2. Make sure your firewall, hosting security tools and rate limiters allow Cloudflare’s published IP ranges. This is one of the most common causes, and it often appears after a security tool is installed or updated.
3. Check that your server listens on the expected ports, typically 80 and 443.
4. Verify the DNS record points to the correct origin IP.

Error 522: Connection Timed Out

What it means: Cloudflare couldn’t complete a connection to your origin in time. The connection attempt itself stalled.

This is the one people search for most, and it has several possible causes.

Common causes:

• An overloaded server that can’t accept new connections
• A firewall silently dropping Cloudflare’s traffic, so connections hang
• The wrong origin IP address in your DNS records, for example after a server move
• Network problems between Cloudflare and your host

How to fix it:

1. Check your server load. High CPU, memory or connection counts often explain it.
2. Allow Cloudflare’s IP ranges through every firewall layer, including hosting-level and server-level ones.
3. Confirm the DNS record points to the correct, current origin IP.
4. Ask your host to check for network issues or connection limits.
5. If it happens during traffic spikes, look at whether the server is sized for the load, and consider caching more content at the edge.

Error 524: A Timeout Occurred

What it means: Cloudflare connected to your origin successfully, but the origin took too long to send a response. By default, Cloudflare waits roughly 100 seconds before giving up on a proxied request.

The difference from 522 is important: in 522 the connection itself fails, while in 524 the connection works and the server is simply too slow.

Common causes:

• Slow, heavy scripts, such as large reports, imports, exports or backups run through the browser
• Unoptimised database queries
• An overloaded server processing requests slowly
• Long-running admin or plugin tasks

How to fix it:

1. Find the slow request and optimise it, whether that means database queries, plugins or scripts.
2. Move long-running jobs out of the browser request and into background tasks or scheduled jobs.
3. Upgrade server resources if the load is consistently too high.
4. For tasks that legitimately run long, check whether your Cloudflare plan allows a longer timeout. Extended timeouts are generally an Enterprise option, so confirm the current terms with Cloudflare.

Error 525: SSL Handshake Failed

What it means: Cloudflare and your origin couldn’t complete the secure handshake needed to establish an encrypted connection.

Common causes:

• No SSL certificate installed on the origin when Cloudflare is set to a mode that expects one
• The origin doesn’t support the TLS versions or cipher suites Cloudflare uses
• Port 443 isn’t open or isn’t serving SSL
• A misconfigured certificate or server SSL setup

How to fix it:

1. Make sure a valid SSL certificate is installed on your origin server.
2. Confirm port 443 is open and your server is serving HTTPS on it.
3. Review your SSL/TLS mode in Cloudflare, which is covered below.
4. Check that your server supports modern TLS versions.

A related error: 526

If you see 526 (Invalid SSL certificate) instead, the handshake worked but the certificate on your origin isn’t valid, for example because it’s expired, self-signed or issued for a different domain. This appears when Cloudflare is in Full (strict) mode. Install a valid certificate, or use a Cloudflare Origin CA certificate, to fix it.

The Cloudflare SSL Setting That Causes Most Headaches

Cloudflare offers several SSL/TLS encryption modes, and picking the wrong one is behind many 525, 526 and redirect-loop problems.

• Off sends everything unencrypted. It’s not recommended.
• Flexible encrypts traffic between visitors and Cloudflare, but not between Cloudflare and your origin. It’s easy to set up, but it leaves part of the journey unprotected and can cause redirect loops if your origin forces HTTPS.
• Full encrypts the whole path, and accepts any certificate on your origin, including self-signed ones.
• Full (strict) encrypts the whole path and requires a valid certificate on your origin. This is the recommended setting.

The safe approach is to install a valid certificate on your origin and use Full (strict). If you switch modes and errors appear, the cause is usually a missing or invalid origin certificate.

Other Errors You May Run Into

523 (Origin is unreachable): Cloudflare can’t reach your origin, often because of a routing problem or an incorrect IP address in DNS.

502 and 504: These can come from your origin or from Cloudflare, so check the error page to see which stage is flagged.

Too many redirects (ERR_TOO_MANY_REDIRECTS): Usually caused by Flexible SSL combined with an origin that forces HTTPS. Switch to Full (strict) with a valid origin certificate.

When It’s a Hack, Not a Misconfiguration

Occasionally these errors are a symptom of something worse. A compromised site can crash servers, exhaust resources or trigger security tools that start blocking traffic. If errors appeared suddenly alongside strange files, unknown admin users or spam in Google, check our guide on what to do in the first hour of a WordPress hack before you start changing settings.

How to Stop These Errors Coming Back

Most of these errors are preventable.

• Keep your origin server and applications updated and monitored.
• Allow Cloudflare’s IP ranges through every firewall, and keep that list current.
• Install a valid SSL certificate and use Full (strict).
• Size your server for your real traffic, and cache static content at the edge so the origin handles less.
• Move slow scripts into background jobs.
• Set up uptime monitoring so you find out before your customers do.

Don’t Want to Debug This Yourself?

Reading logs and chasing firewall rules is not how most business owners want to spend a Tuesday. That’s what a partner is for.

Tremhost is a Cloudflare partner, and Armor Guard gives you a properly configured firewall, DDoS protection and SSL for $9 per site per month, set up so these connection errors are far less likely to catch you out. For sites that take payments or hold client data, Armor Shield adds firewall rules written for your application, unmetered traffic, free malware cleanup and a named engineer, from $29 per site per month.

If your site is down because of an attack or infection, not a configuration slip, Armor SOS is our emergency cleanup service. Triage is free and usually starts the same day.

Frequently Asked Questions

What does Cloudflare error 522 mean?

It means Cloudflare couldn’t establish a connection to your origin server in time. Common causes include an overloaded server, a firewall blocking Cloudflare’s IPs or an incorrect origin IP in your DNS.

What’s the difference between 521 and 522?

With 521, your origin actively refuses the connection, which usually means the server is down or blocking Cloudflare. With 522, the connection attempt times out, which usually points to overload, dropped traffic or a wrong IP.

What causes Cloudflare error 520?

Your origin returned an empty, malformed or unexpected response. Common causes are an application crash, a PHP error, oversized headers or a firewall resetting the connection.

How do I fix Cloudflare error 524?

The origin connected but took too long to reply. Optimise slow queries and scripts, move long-running tasks to background jobs, add server resources or check whether your plan permits a longer timeout.

How do I fix Cloudflare error 525?

Install a valid SSL certificate on your origin, make sure port 443 is open and serving HTTPS, and review your Cloudflare SSL/TLS mode. Full (strict) with a valid origin certificate is the recommended setup.

Is a Cloudflare error my server’s fault or Cloudflare’s?

For errors in the 520 to 527 range, it’s almost always the origin or the connection to it. Test your server directly, bypassing Cloudflare, to confirm.

Should I pause Cloudflare to fix the problem?

Pausing or switching a record to DNS only is a useful test, because it shows whether the origin works on its own. It removes your Cloudflare protection while it’s off, though, so use it briefly and put it back.

Can Cloudflare errors be caused by a hack?

Yes, occasionally. Malware can exhaust server resources or trigger firewall blocks. If errors coincide with other warning signs, treat it as a possible compromise.

Tremhost is now a Cloudflare partner. If you run a website, a team or a multi-branch business, that changes what you can buy from us and how much it costs. This post explains what the partnership is, what it isn’t, what you can now get and who it suits.

What Is a Cloudflare Partner?

Cloudflare runs one of the largest networks on the internet, sitting in front of an estimated fifth of all websites. It provides the infrastructure: a global content delivery network, DDoS protection, a web application firewall, bot management, and Zero Trust tools for securing staff access and company networks.

A Cloudflare partner is a company that works with Cloudflare to deliver those services to its own customers. Instead of every business signing up directly, configuring everything alone and working out how to respond when something goes wrong, a partner provides the plans together with the setup, monitoring and support around them.

What the Partnership Is Not

It’s worth being clear about this, because it affects what you can expect.

Tremhost is not Cloudflare. Cloudflare owns and operates the network, and its platform and terms still apply to the services we provide. What Tremhost adds is the layer around it: configuring the protection properly, writing rules suited to your site, monitoring it, cleaning up if something gets through and answering your calls and messages. If you’ve ever signed up for Cloudflare, left the settings on default and wondered whether you were actually protected, that’s the gap a partner fills.

Why Use a Partner Instead of Buying Direct?

You can buy Cloudflare directly, and many people do. The reasons to go through a partner come down to three things.

Price. Partners buy at partner rates, and that can be passed on. For example, Armor Guard, our entry plan, is $9 per site per month, against $25 per month for Cloudflare’s own Pro plan bought direct.

Setup done properly. Cloudflare’s default settings block very little on their own. A well-configured firewall, with sensible rules, rate limits on login and checkout pages and correct caching, makes a large difference to how much protection you get.

Someone to call. When a site gets hacked, a certificate expires or traffic spikes, buying direct typically means a ticket queue. With a managed service, you reach a person who knows your setup.

What You Can Get From Tremhost Now

We’ve organised the partnership into a set of plans, covering sites, staff and networks.

Protecting your websites

Armor Guard is $9 per site per month ($90 a year). It’s built on Pro-grade protection and includes the firewall, DDoS protection and SSL, which suits informational sites and small businesses. Cleanup is quoted separately on this plan, and there’s a fair-use ceiling of 500 GB and 50 million requests a month.

Armor Shield is $29 per site per month, falling to $27 a site from five sites and $25 from ten. It adds firewall rules written for your specific application, free malware cleanup if you’re compromised, unmetered traffic and a named engineer, and it suits sites that take payments or hold client data.

Protecting your staff and branches

Armor Workforce secures staff access with Zero Trust, at $5 per person (10-person minimum), which replaces shared VPN passwords and helps close leavers’ accounts the day they go. Check the page for the current launch rate.

Armor Network is for businesses with several branches, priced per person from $9 and scoped through a short survey. It connects offices through a cloud network and firewall instead of a hardware appliance at every location.

For larger organisations and regulated sectors

Armor Enterprise is a scoped offer for organisations above 250 staff, and Cloudflare Enterprise is aimed at banks, government, telecoms and universities that need API protection, bot management, an uptime SLA and compliance-ready logging. These are priced on scope rather than from a list.

When something has already gone wrong

Armor SOS is our emergency cleanup service. Triage is free and usually starts the same day. It works on sites hosted anywhere, not just with us.

Who Is This For?

The plans suit several kinds of customers. Small business owners who want proper protection without learning the platform will find Guard and Shield a better fit than the do-it-yourself route. Agencies and developers can use the services behind their own name, since we never contact their clients. Growing companies with distributed teams get Workforce and Network. Larger organisations in finance, government, telecoms and education get a route to Cloudflare Enterprise with a local partner.

It’s not the right choice for everyone. If you have an in-house security team that already manages Cloudflare confidently, buying direct may suit you better. And if you need infrastructure beyond what we deliver, we’ll say so rather than oversell.

What Happens Next

If you’re not sure which plan fits, the Cloudflare plans hub lays out the options side by side. If your site is under attack or already compromised, don’t wait. Message Armor SOS and we’ll start triage immediately.

Frequently Asked Questions

Is Tremhost an official Cloudflare partner?

Yes. Tremhost is a Cloudflare partner, which means we deliver Cloudflare’s services to our customers alongside our own configuration, monitoring and support.

Is Tremhost the same as Cloudflare?

No. Cloudflare owns and operates the network. Tremhost provides the setup, rules, monitoring, cleanup and support around it.

Why would I buy Cloudflare through Tremhost instead of directly?

Mainly for price, proper configuration and a person to call when something goes wrong. For example, Armor Guard is $9 per site per month compared with $25 for Cloudflare Pro bought direct.

Do I need to move my hosting to Tremhost?

No. Armor SOS, for example, works on sites hosted anywhere, and our protection plans sit in front of your site wherever it’s hosted.

What’s the difference between Armor Guard and Armor Shield?

Both are built on Pro-grade protection. Guard is the entry plan at $9 a month. Shield, at $29, adds application-specific firewall rules, free malware cleanup, unmetered traffic and a named engineer.

Can agencies resell these plans?

Yes. Developers and agencies can use the services behind their own name, and we won’t contact their clients.

What if my site is already hacked?

Contact Armor SOS. Triage is free and usually starts the same day.

Your emails stop arriving. Customers say they never got the invoice, quotes bounce back with a cryptic error, and the messages that do get through land in spam. Then you find the reason: your mail server, or your domain, is on a blacklist.

For a business that runs on email, this is a serious problem, and it can happen without you sending a single bad message yourself. This guide explains what a blacklist is, how to check whether you’re on one, how to get removed and, most importantly, how to find and fix the cause so you don’t end up back on it.

What Is an Email Blacklist?

An email blacklist, also called a blocklist or DNSBL, is a database of IP addresses and domains that have been linked to spam, phishing or other abuse. Mail providers and spam filters check these lists in real time. If your sending IP or domain appears on a list they trust, they may reject your mail outright, send it to spam or throttle it heavily.

There isn’t one master list. Dozens exist, run by different organisations with different rules, and different receivers trust different lists. Some, like Spamhaus, carry great weight and are used by a large share of the world’s mail systems. Others are small and rarely matter. This is why you can be blocked by some recipients and not others, which makes the problem confusing to diagnose.

Why Mail Servers Get Blacklisted

Listings aren’t random. They follow from something your server was seen doing. The most common causes are:

• A compromised website or mail account. A hacked WordPress site or a stolen mailbox password lets attackers send spam or phishing through your server. This is the most common cause we see, and the owner often has no idea it’s happening.
• A compromised server or account on shared infrastructure. If another customer on your IP is sending spam, your reputation can suffer with theirs.
• Spam complaints. Recipients marking your mail as spam builds a poor sender reputation, even for legitimate marketing.
• Poorly managed mailing lists. Sending to old, purchased or unconfirmed addresses generates bounces and spam-trap hits.
• Missing or broken authentication. Without proper SPF, DKIM and DMARC records, your mail looks forgeable, and attackers can spoof your domain.
• A bad IP history. Sometimes the IP was previously used by a spammer before you got it.
• Open relays or misconfigured servers that let anyone send through them.

If your listing appeared suddenly, check for a compromise first. A site hack and a blacklisting often arrive together, which is why our guide on what to do in the first hour of a WordPress hack lists blocked email as a warning sign.

Step 1: Confirm You’re Actually Blacklisted

Don’t assume. Start by reading the bounce message, because it often names the list or gives a code and a link. Then check your sending IP and domain against a blacklist lookup tool. Several free multi-list checkers exist, and the major lists such as Spamhaus provide their own lookup pages.

Note the exact list or lists you appear on, the reason given and the IP or domain affected. You’ll need all three, because each list has its own removal process and requirements.

Step 2: Find the Cause Before You Ask for Removal

This is where most people go wrong. Requesting delisting without fixing the cause rarely works, and if it does, you’ll be relisted quickly, sometimes with a harsher penalty.

Check these in order:

1. Scan your website and server for malware. Look for web shells, injected scripts and unfamiliar scheduled tasks that could be sending mail.
2. Review your mail queue and logs. A queue full of messages you didn’t write is a clear sign of abuse. Look at which account or script is sending them.
3. Check your mailboxes for compromise. Look for forwarding rules you didn’t create, unfamiliar logins and unusually high sending volume.
4. Review your contact forms and plugins. Spammers often abuse unprotected forms to relay mail.
5. Verify your authentication records (covered below).

If you find signs of a hack, work through the containment steps in our guide first. A compromised site that’s still active will simply get you relisted. And as we explain in our post on why restoring a backup doesn’t fix a hacked website, the entry point must be closed or the problem returns.

Step 3: Fix the Underlying Problem

Once you’ve found the cause, remove it properly:

• Clean the infection and close the entry point, then reset every credential the attacker could have reached, including mailbox passwords.
• Clear the spam from the mail queue so it isn’t delivered after you’ve fixed the cause.
• Remove malicious forwarding rules and rogue accounts.
• Update and patch your website software and delete anything unused.
• Secure your forms with proper validation or CAPTCHA so they can’t be used as relays.
• Clean your mailing lists. Remove bounced, inactive and unconfirmed addresses.

Step 4: Set Up Email Authentication Correctly

Authentication proves that mail claiming to be from your domain really is. Receivers increasingly require it. Gmail, Yahoo and Microsoft have all tightened their expectations for senders, particularly for bulk mail, and missing authentication is a common reason legitimate mail ends up in spam.

You need three things:

SPF lists the servers allowed to send mail for your domain. Keep it accurate and avoid the common mistake of exceeding the limit on DNS lookups, which causes SPF to fail.

DKIM adds a cryptographic signature to each message so receivers can verify it wasn’t altered and really came from you.

DMARC tells receivers what to do when SPF or DKIM fail, and sends you reports. Start with a monitoring policy so you can see who is sending as your domain, then move to quarantine or reject once everything legitimate is passing.

Also check that your sending IP has a reverse DNS (PTR) record matching your mail server’s hostname. Many receivers reject mail without one.

Step 5: Request Delisting

Only now should you ask to be removed. Each list has its own process, and the details differ, so follow the instructions on that list’s own site.

A few general principles apply:

• Use the list’s official removal form. Never pay anyone who promises guaranteed removal, and be wary of lists that charge for delisting.
• Explain what happened and what you fixed. A short, specific, honest statement helps. Vague requests get ignored.
• Expect different timelines. Some lists remove you automatically after a period without abuse. Others require manual review.
• Understand the type of listing. Some lists, such as policy lists covering dynamic or residential IP ranges, aren’t about your behaviour at all. Those are removed through your internet provider or hosting company rather than by appeal.
• Be patient with repeat listings. If you’ve been listed before, expect stricter handling.

Reputation with the large mailbox providers also matters separately from blacklists. If Gmail or Microsoft are still sending your mail to spam after you’re delisted, their own postmaster tools show how they rate your domain and IP.

Step 6: Recover Your Reputation

Delisting removes the block, but your sender reputation takes longer to rebuild. For the next few weeks:

• Send only to engaged recipients and keep volume steady rather than sending large bursts.
• Monitor bounce rates and complaints closely.
• Watch the blacklist status of your IP and domain regularly.
• Review your DMARC reports to catch anyone else sending as your domain.

How to Stay Off Blacklists

Most listings are preventable. The habits that keep you off:

• Keep your website and server software updated, and delete unused plugins.
• Use strong, unique mailbox passwords with two-factor authentication where possible.
• Configure SPF, DKIM and DMARC properly and keep them current.
• Monitor your mail queue for unusual volume.
• Only email people who’ve agreed to hear from you, and make unsubscribing easy.
• Put a web application firewall in front of your site to cut off a common route for attackers.

On that last point, be realistic. A firewall reduces your exposure by blocking attacks it can see, but it doesn’t patch a vulnerable plugin and can’t clean a server that’s already sending spam. Protection and cleanup are separate jobs, and you need both.

Get Help Now: Armor SOS

If your mail server is blacklisted and you suspect a compromise, Armor SOS is Tremhost’s emergency cleanup service. Triage is free and usually starts the same day. We contain the attacker’s access, find and remove whatever was sending the mail, reset compromised credentials, handle your Google and blacklist delisting, and give you a written report on how they got in. We work on sites hosted anywhere, and developers can use us behind their own name, since we never contact your client.

Message Armor SOS now →

Make Sure It Doesn’t Happen Again: Armor Shield

If your site takes payments or holds client data, the smartest follow-up is Armor Shield, at $29 per site per month. It includes firewall rules written for your specific application, unlimited malware cleanup if you’re ever compromised again, Google and blacklist delisting handled by us, a monthly report and a named engineer with a four-hour response. It costs less than a single emergency cleanup.

See Armor Shield →

For simpler informational sites, Armor Guard gives you the firewall, DDoS protection and SSL for $9 a month. Cleanup is quoted separately on that plan.

Frequently Asked Questions

How do I know if my email server is blacklisted?

Check the bounce messages for a list name or error code, then run your sending IP and domain through a blacklist lookup tool. Major lists such as Spamhaus also offer their own lookup pages.

Why did my email server get blacklisted?

Common causes are a compromised website or mailbox sending spam, spam complaints, poor mailing list hygiene, missing email authentication, a bad IP history or a misconfigured server. A hacked site is the cause we see most often.

How do I remove my IP from a blacklist?

Find and fix the cause first, then use the list’s official removal process and explain what you fixed. Requesting removal before fixing the problem usually fails or leads to relisting.

How long does delisting take?

It varies by list. Some remove you automatically after a clean period, while others review requests manually. Listings caused by an unresolved compromise can keep returning until the cause is fixed.

Should I pay a service to get me delisted?

Be cautious. Legitimate lists provide official removal forms, and anyone guaranteeing removal for a fee deserves suspicion. Fixing the cause matters more than any paid service.

Can a hacked website get my email blacklisted?

Yes. Attackers commonly use compromised sites and server accounts to send spam or phishing, which damages your IP and domain reputation.

Do I need SPF, DKIM and DMARC?

Yes. Receivers increasingly expect all three, and missing or broken authentication is a common reason legitimate mail lands in spam or gets rejected.

Why is my email still going to spam after I was delisted?

Delisting removes the block, but your sender reputation takes time to rebuild. Check authentication, send only to engaged recipients and watch your reputation in the major mailbox providers’ postmaster tools.

How much does it cost to fix a blacklisted server?

With Tremhost, triage is free and cleanup is quoted after we see what we’re dealing with. On Armor Shield, cleanup and delisting are included at no extra charge, every time.

Your site gets hacked, and the answer seems obvious: roll back to a backup from before it happened. The site looks normal again, and you breathe out.

Then, days later, the same spam pages appear, or the same redirect, or the same Google warning. You restored a clean-looking backup and the hack came back anyway.

This is one of the most common recovery mistakes, and it’s understandable, because restoring a backup is exactly what backups are for. This guide explains why it often fails after a hack, when a backup genuinely helps and how to recover so the problem stays fixed.

What a Backup Actually Contains

A backup is a snapshot of your site at a moment in time. It captures your files, your database and your settings exactly as they were. That’s the whole point, and it’s also the problem.

If your site was vulnerable at the time of the snapshot, the backup is vulnerable too. It faithfully preserves whatever was true when it was taken: the outdated plugin, the weak admin password, the forgotten user account. Restoring it puts all of that back.

Why Restoring a Backup Usually Brings the Hack Back

There are four reasons a restore fails to end a compromise.

1. The vulnerability is still there

Most hacks begin with a weakness: an outdated plugin, an abandoned theme, a nulled (pirated) download or a stolen password. A restore doesn’t fix any of these. If the attacker got in through a plugin flaw last week, the restored site still runs that same plugin, so they simply walk back in.

2. The backdoor may be in the backup

Attackers rarely rely on one entry. They leave backdoors, small hidden files or database entries that let them return whenever they like. If the backdoor was planted before your backup was taken, the backup contains it. You restore the site and the backdoor together, and the attacker still has a key.

3. You may not know when the compromise began

To restore safely, you need a backup from before the break-in. But many compromises sit quietly for weeks before anything visible happens. Casino spam, hidden redirects and credential theft are often designed to stay invisible. If you pick a backup from the day before you noticed the problem, it may already be infected.

4. The stolen credentials survive the restore

A backup of your site files doesn’t change the passwords the attacker already stole. If they captured your admin login, hosting password or FTP details, those still work after the restore. They can log straight back in and reinfect the site, and the restored site never gets a chance.

The Hidden Danger: Restoring Destroys Evidence

There’s a second cost that people rarely consider. Restoring over a compromised site overwrites the evidence of how the attacker got in.

Without that evidence, nobody can say which plugin was exploited, which account was used or what else was touched. Without knowing the entry point, you can’t close it, and a site whose entry point stays open is a site that gets hacked again. This is why we always advise taking a forensic copy and preserving the logs before touching anything. Our guide on what to do in the first hour of a WordPress hack explains how.

Signs You’ve Been Reinfected After a Restore

If you’ve already restored a backup, watch for these signs that the compromise survived:

• The same spam pages, redirects or defacement reappear within days
• Pages you don’t recognise show up in Google again (see our guide to casino and gambling pages under your domain)
• Google Search Console shows a returning security issue
• Admin users you didn’t create reappear
• Your hosting provider flags the account again
• Your site is flagged with a warning such as “Deceptive site ahead”

A hack that returns after a restore is almost always a sign the entry point or a backdoor is still in place.

When a Backup Is Genuinely Useful

Backups aren’t useless after a hack. They simply aren’t a cure by themselves. They’re valuable in three ways.

As a reference. Comparing your files against a known-good backup helps identify which files were changed or added by the attacker, so a cleanup can be precise.

As a safety net. If a cleanup goes wrong, or if data is destroyed rather than just infected, a backup lets you recover content. This matters most for attacks that delete or encrypt data.

As a rollback after the cause is closed. Once the entry point is found and fixed, and credentials are reset, restoring clean content from a verified-clean backup can be a legitimate recovery step.

The key is the sequence. A backup works after you’ve found and closed the way in, not instead of doing so.

How to Recover Properly

A reliable recovery follows this order:

1. Contain the attacker’s access before anything else.
2. Preserve the logs and take a forensic copy of the compromised site.
3. Find the entry point by working out how they got in.
4. Remove everything malicious, including backdoors and hidden files, in both files and database.
5. Check for rogue users and scheduled tasks that could reinstall the malware.
6. Reset every credential the attacker could have reached.
7. Update and patch WordPress core, themes and plugins, and delete anything unused.
8. Restore content from a verified-clean backup only if needed, such as when data was actually lost.
9. Re-scan after a couple of weeks to confirm the site stayed clean.

Notice where the restore sits in that list. It’s a late step, and only sometimes a necessary one.

How to Make Your Backups Work for You

Good backup habits make recovery easier even though they can’t replace a cleanup.

• Keep backups off the server. A backup stored on the same account can be encrypted, deleted or infected alongside the site.
• Keep several versions over time. Multiple restore points let you find one from before a slow-burning compromise began.
• Test your restores. A backup you’ve never restored is a backup you can’t trust.
• Back up the database too, not just the files.
• Monitor your site so you notice compromises early, because earlier detection means a cleaner backup is available.

If you want automated, off-server backups with sensible retention, look at Tremhost’s Backup Cloud.

Get Help Now: Armor SOS

If your site was hacked and a restore didn’t solve it, Armor SOS is Tremhost’s emergency cleanup service. We take a forensic copy before touching anything, so nothing is lost even if we have to roll back. We then contain the attacker’s access, remove every injected page, shell and backdoor, reset compromised credentials, handle Google and blacklist delisting, and give you a written report on how they got in. We also clean in place wherever possible, and we work on sites hosted anywhere. Triage is free and usually starts the same day.

Message Armor SOS now →

Stop Paying for Cleanups: Armor Shield

If your site takes payments or holds client data, Armor Shield is $29 per site per month. It includes firewall rules written for your specific application, unlimited malware cleanup whenever you’re compromised, Google and blacklist delisting handled by us, a monthly report and a named engineer with a four-hour response. Shield protects the edge and cleans the origin, and it won’t patch a vulnerable plugin for you, but it will tell you exactly what to fix. At that price it costs less than a single emergency cleanup.

See Armor Shield →

For simpler informational sites, Armor Guard gives you the firewall, DDoS protection and SSL for $9 a month. Cleanup is quoted separately on that plan.

Frequently Asked Questions

Should I restore a backup if my website is hacked?

Not as your first or only move. A backup usually contains the same vulnerability, and possibly the same backdoor, so restoring it often brings the hack back. Preserve the evidence, find and close the entry point and reset credentials first.

Why did my site get hacked again after I restored a backup?

The entry point was probably still open, a backdoor was in the backup, or the attacker still held stolen credentials. A restore changes none of those things.

How do I know which backup is clean?

It’s hard to be sure, because many compromises begin quietly before anything visible happens. A reliable approach is to compare the backup against known-good files and scan it, rather than trusting its date.

Can a backup contain malware?

Yes. A backup preserves whatever was on the site when it was taken, including malware, backdoors and vulnerable code, if the compromise had already begun.

Do I lose evidence if I restore over a hacked site?

Yes. Restoring overwrites the infected files, which can destroy the evidence of how the attacker got in. Take a forensic copy and preserve the logs before changing anything.

Are backups still worth having?

Absolutely. They’re a reference for cleanup, a safety net if data is lost and a rollback option once the cause is fixed. They just aren’t a cure on their own.

Does a firewall fix a hacked site?

No. A firewall blocks attacks before they reach your site, but it can’t remove malware that’s already installed. Cleanup and protection are separate jobs.

How much does hacked website cleanup cost?

With Tremhost, triage is free and cleanup is quoted after we see what we’re dealing with. On Armor Shield, cleanup is included at no extra charge, every time.

You open your site and something is wrong. Maybe it redirects to a strange page, or a customer messages to say Google is showing a warning. Maybe you search your own domain and find hundreds of casino pages you never created.

Don’t panic, and don’t start deleting things. What you do in the first hour decides whether the cleanup takes a day or a month, and whether the attacker gets back in a week later. This guide covers how to confirm the hack, what to preserve, what to avoid and how to recover properly.

How to Tell Your WordPress Site Has Been Hacked

Hacked sites don’t always look hacked, and that’s the problem. The most damaging attacks are invisible to you when you visit your own site. Check for these signs:

• Pages in Google you never made. Search site:yourdomain.com and look for gambling, pharmaceutical or foreign-language pages. Attackers often hide them from logged-in owners and show them only to search engines.
• Visitors redirected somewhere else, often only on mobile or when arriving from Google.
• Admin users you don’t recognise under Users in your WordPress dashboard.
• A browser or Google warning such as “Deceptive site ahead” or “This site may be hacked.”
• Your hosting provider suspended the account or sent a malware notice.
• Your email suddenly stops arriving, or your invoices bounce. A compromised account may be sending spam, which gets your server blacklisted.
• A defaced homepage, or a plain blank page.

If any of these match, treat it as a real incident until proven otherwise.

Step 1: Don’t Delete Anything Yet

This is the hardest instruction to follow, because every instinct says to remove the bad files immediately. Resist it.

Deleting files destroys the evidence of how the attacker got in. If you don’t know the entry point, you can’t close it. A site cleaned without finding the way in gets reinfected, often within days, because the same vulnerable plugin or stolen credential is still sitting there.

Step 2: Preserve the Logs and Take a Copy

Server logs are your best record of what happened, and they roll over. On many hosting setups, the evidence of the original break-in disappears within days.

Before you change anything, ask your host to preserve your access and error logs, or download them yourself if you can. Then take a full copy of the site files and database, stored somewhere off the server. This forensic copy lets an investigator work out how the attacker got in, and it protects you if a cleanup goes wrong.

Step 3: Don’t Rush to Change Passwords

This surprises most people. Changing passwords is good practice, but doing it too early can backfire. If the attacker has left a backdoor or a keylogger, they can capture your new password the moment you set it, and you’ve given them fresh credentials.

The better order is to contain first (cut the attacker’s access), then reset every credential the attacker could have reached. That includes WordPress admin accounts, hosting panel, FTP and SSH, database passwords and API keys. If you must act before help arrives, do it from a clean, malware-free device.

Step 4: Don’t Restore an Old Backup and Call It Done

Restoring a backup feels like the obvious fix, but it usually restores the problem. If the attacker got in through an outdated plugin, a backup from last week still contains that plugin, and quite possibly the backdoor too.

A backup is useful as a reference point, not a cure. It’s worth keeping, but a clean-looking restore without finding the root cause just resets the clock until the next attack.

Step 5: Check How Far It Has Spread

A hacked WordPress site is often not the only thing compromised. Check whether:

• Other sites in the same hosting account were infected. Attackers move sideways.
• Email accounts are sending spam or phishing from your domain.
• Your site appears on Google Safe Browsing or on mail blacklists.
• Customer data, such as WooCommerce orders or a contact-form database, may have been exposed. If it has, you may have legal and notification obligations depending on where you operate.

What a Proper Cleanup Includes

“We removed the virus” isn’t a cleanup. A thorough job covers these steps, in order:

1. Contain the attacker’s access before anything else.
2. Preserve the logs and a forensic copy.
3. Remove injected pages, web shells and backdoors, all of them rather than just the obvious ones.
4. Reset every credential the attacker could have reached.
5. Delist the site from Google Safe Browsing and any mail blacklists.
6. Report in writing what happened, how they got in and what was changed.
7. Harden the site so that same route closes permanently.
8. Follow up with a scan a couple of weeks later to confirm the site stayed clean.

If someone offers you a cleanup that skips the report or the root-cause step, you’re buying a temporary fix.

Getting Off Google’s Warning List

If Google has flagged your domain, every visitor sees a red warning page, and your search traffic collapses. Removal requires the site to be genuinely clean first. After that, a review request goes through Google Search Console, and approval can take days. Requesting a review before the cleanup is complete usually gets rejected and can lengthen the process, so clean thoroughly first.

How to Stop It Happening Again

Most WordPress compromises trace back to a short list of causes: outdated plugins and themes, pirated (“nulled”) themes carrying hidden malware, weak or reused passwords, and abandoned admin accounts.

Keep everything updated, delete plugins you don’t use, never install nulled software and enable two-factor authentication on every admin account. A web application firewall adds a strong layer in front of the site, but be clear about what it does. A firewall blocks attacks it can see. It doesn’t patch a vulnerable plugin and it can’t clean a site that’s already infected. Protection and cleanup are two different jobs, and you need both.

Get Help Now: Armor SOS

If your site is hacked right now, Armor SOS is Tremhost’s emergency cleanup service. Triage is free and usually starts the same day, often within the hour. We work on sites hosted anywhere, not just with us. We contain the attack, remove every injected page, shell and backdoor, reset compromised credentials, handle your Google and blacklist delisting, and give you a written report on how they got in. We clean up infections like these across our own fleet every week, so nothing you’re about to describe will surprise us.

Message Armor SOS now →

Make Sure It’s the Last Time: Armor Shield

If your site takes payments or holds client data, the smartest move after a cleanup is to make sure you never pay for one again. Armor Shield is $29 per site per month and includes unlimited malware cleanup whenever you’re compromised, firewall rules written for your specific application, blacklist and Google delisting handled by us, a monthly report and a named engineer with a four-hour response time. At that price, Shield costs less than a single emergency cleanup, which is why most clients who call us once end up on it afterwards.

See Armor Shield →

For simpler informational sites, Armor Guard gives you the firewall, DDoS protection and SSL for $9 a month. Cleanup is quoted separately on that plan.

Frequently Asked Questions

How do I know if my WordPress site has been hacked?

Common signs include unfamiliar pages in Google results, redirects, unknown admin users, security warnings in browsers, a suspended hosting account or blocked email. Search site:yourdomain.com to check for pages you didn’t create.

Should I restore a backup if my WordPress site is hacked?

Not as your first move. A backup often contains the same vulnerability or backdoor, so restoring can reinstate the infection. Use backups as a reference after you’ve found and closed the entry point.

Should I change my passwords straight away?

Contain the attacker’s access first. If a backdoor or keylogger is still active, new passwords can be captured immediately. Reset every credential once access is cut off, using a clean device.

How long does WordPress malware removal take?

It depends on how deep the compromise goes. A single infected site is usually a faster job than a server compromised at root level. Delisting from Google or mail blacklists adds extra time after the cleanup.

Can a firewall clean a hacked website?

No. A firewall blocks attacks before they reach your site, but it can’t remove malware that is already there. Cleanup and protection are separate services.

Will I lose my website during a cleanup?

Rarely. A proper cleanup works in place wherever possible and takes a forensic copy first, so nothing is lost even if a rollback is needed.

How much does hacked website cleanup cost?

Emergency work is often billed hourly and negotiated while your site is down. With Tremhost, triage is free and cleanup is quoted after we see what we’re dealing with. On Armor Shield, cleanup is included at no extra charge, every time.

A 99.9% uptime guarantee has become close to universal across the hosting industry, printed on nearly every pricing page as though it’s a meaningful point of differentiation. It isn’t, really, because almost everyone advertises the same number. What actually separates providers is whether independent, real-world monitoring over extended periods backs that number up, and whether the guarantee itself means anything concrete when it’s missed. Here’s what the available independent testing data actually shows, and how to read a hosting uptime guarantee properly before taking any single advertised percentage at face value.

What 99.9% Actually Means in Real Hours

Before comparing providers, it’s worth translating the percentage into something concrete, because the number alone doesn’t convey much. A 99.9% uptime guarantee allows for a little under nine hours of downtime across an entire year. That sounds generous until you consider that independent testing consistently shows meaningful variation between providers within that same advertised tier, some genuinely approaching 100% over extended monitoring periods, others landing noticeably closer to, or even below, the 99.9% floor they’re advertising, which represents a real, measurable difference in how often a site actually goes dark.

What Independent Testing Actually Shows

Several independent monitoring projects track hosting providers over extended periods, using tools like Pingdom and UptimeRobot to measure real uptime rather than relying on self-reported figures, and the results are informative. Across multiple independent 2026 testing cycles, Hostinger has consistently posted strong results, with monitoring periods showing uptime in the range of 99.9% to 99.99%, and in several tests, a perfect 100% over multi-week windows. SiteGround has performed comparably well across independent tests, frequently landing at 99.99% or effectively 100% over 30-day monitoring periods, consistent with its reputation for premium, well-maintained infrastructure.

Bluehost’s results are worth looking at more closely, because they’re genuinely more variable across different independent testers than the other major providers. Some testing cycles show Bluehost in the 99.98% to 99.99% range, broadly comparable to its competitors, while other independent year-long monitoring projects have recorded averages closer to 99.91%, with one tester specifically noting Bluehost saw the fewest months of perfect 100% uptime among the hosts in its comparison. This doesn’t mean Bluehost is unreliable, it still lands within or close to its advertised guarantee in most tests, but it does mean the gap between “advertises 99.9%” and “independently measured at 99.9%” is real and worth checking rather than assuming every provider performs identically simply because they print the same number.

A2 Hosting has posted consistently strong independent results too, commonly in the 99.98% range across multiple testing cycles, and DreamHost stands out for a different reason, advertising a genuine 100% uptime guarantee, a notably stronger commitment than the 99.9% standard, backed by actual compensation to customers when that threshold isn’t met.

Why the Guarantee Itself Matters as Much as the Number

This is the part that gets skipped in most comparisons entirely, and it’s arguably more important than the percentage itself. An uptime guarantee is only meaningful if there’s a real, specified consequence attached when a provider fails to meet it. Some providers offer genuine, automatic account credit when downtime exceeds their advertised threshold, a real commitment with a real cost to the provider for failing to deliver. Others advertise the same 99.9% figure with no specified compensation at all, meaning the “guarantee” is really just a performance target with no actual accountability behind it if it’s missed.

It’s worth specifically checking, before choosing based on an advertised uptime number, whether that guarantee comes with a defined compensation policy, and what you’d actually need to do to claim it, since a guarantee that requires you to prove downtime yourself through your own monitoring, with no proactive crediting from the provider, functions very differently in practice than one that’s applied automatically.

Why Monitoring Methodology Changes What You’re Actually Comparing

It’s worth being honest that independent testing results vary partly because testers use different monitoring tools, check from different global locations, and run their tests over different time windows, which is exactly why the figures above show ranges rather than single definitive numbers for each provider. A result from a 14-day test window carries less statistical weight than a full year of monitoring, and a test run from a single geographic location may not reflect what uptime looks like for your specific visitor base if they’re concentrated somewhere else entirely. This is a reasonable argument for treating any single test’s results as one data point among several, rather than the final word, and for weighing results that are consistent across multiple independent testers more heavily than a single outlier report in either direction.

What This Means for Choosing a Host

If raw independent uptime data is your primary deciding factor, SiteGround and Hostinger currently post the most consistently strong results across multiple independent 2026 testing cycles, with A2 Hosting close behind. If a genuine, compensation-backed guarantee matters more to you than a marginal difference in measured uptime percentage, DreamHost’s 100% guarantee with real compensation is worth specifically factoring in, since it’s a meaningfully stronger commitment on paper than the industry-standard 99.9%. And regardless of which provider you’re evaluating, it’s worth asking two specific questions before trusting an advertised number: is this figure backed by independent, third-party monitoring data or only the provider’s own self-reported status page, and what, specifically, happens, in writing, if the guarantee isn’t met. Tremhost’s hosting and VPS plans carry a 99.9% uptime SLA across every tier, and the more useful test of that commitment isn’t the percentage printed on the pricing page, it’s being able to actually reach a real support engineer rather than a chatbot queue the moment something does go wrong, which is where an uptime guarantee’s real value shows up in practice rather than on paper.