Almost every WordPress restoration request we get sounds the same on the first call. "The site's showing a blank white screen." "Google's flagging us as a security risk." "Our host emailed saying they suspended the account for malware." "We can't log into wp-admin anymore." Different symptom, same underlying job: something broke or someone got in, and now there's a business sitting behind a site that doesn't work.

We get this request often enough, "WordPress Site Restoration," "WordPress Site Restoration from Backup," "Website restoration," "Website Migration and Design," that it's worth writing down the actual sequence we run, instead of re-explaining it on every call. This is the agency-side version: what we check first, when a backup restore is the right call versus a rebuild, and where migration quietly becomes the better fix than repair.

What do you do in the first ten minutes?

Nothing that touches content yet. The first move is isolation.

Take the site offline or lock it down. If it's actively compromised, a live hacked site keeps getting re-indexed by Google with the malicious content, keeps serving malware to visitors, and in the worst cases keeps letting the attacker back in while you're trying to clean it. A maintenance page or, if the host allows it, a full suspend buys you room to work without the damage compounding.

Change every credential that touches the site. WordPress admin, hosting control panel, database, SFTP/SSH, and any connected email account. If one of these was how the attacker got in, cleaning the files and leaving the same password in place gets you compromised again within days. We've seen it happen inside a week.

Pull a snapshot of the current broken state before changing anything else. Even a hacked or crashed site is evidence. If you're going to involve a host's support team, file a report, or later need to prove what happened for a client or insurer, you want a copy of the compromised state, the error logs, and a list of recently modified files before you start restoring or cleaning.

Check what your host actually retains. This is the step people skip, and it's the one that decides everything downstream. Log into the hosting panel and find out how many days of backups exist, and how far back they go. Most shared hosting plans retain 7 to 30 days. If the site was compromised weeks ago and only surfaced now, which is common, the backup that would restore you also restores the vulnerability, or worse, doesn't go back far enough to predate the infection at all.

Restore from backup, or rebuild?

This is the decision point that actually matters, and it's not the same question as "do we have a backup." You can have a backup and still not want to use it.

Restore from backup when:

  • You have a clean backup that clearly predates the incident, confirmed by comparing the backup date against your server's access logs and file-modification timestamps
  • The cause was identified and isn't still present in the current theme, plugin stack or server configuration
  • The site's core content and structure haven't changed enough since the backup to make restoring it a net loss of recent work

Rebuild or clean-in-place when:

  • The only available backup is from before the vulnerability was introduced, which just restores the hole along with the site
  • You can't pinpoint how the attacker got in, which means restoring blind is a coin flip on whether it happens again
  • The backup itself is suspect, some backup plugins happily back up an already-infected site for weeks before anyone notices

The instinct on a "restore from backup" request is to treat it as a pure file-recovery job. It isn't. Restoring the files is the easy half. Confirming the backup is actually clean, and that the door that let the attacker in has been closed, is the half that determines whether you're fixing this once or fixing it again in a month.

When is migration the better fix than repair?

Sometimes the ticket says "restore my site" but the honest diagnosis is that the site needs to move, not just get patched back to its previous state. This comes up more than people expect, and it's usually one of three patterns.

The host is the actual problem. A site that keeps getting compromised on the same shared hosting account, despite clean WordPress core, updated plugins and hardened passwords, often has a server-level issue: a neighboring account on the same shared server that's compromised, outdated PHP with known vulnerabilities the host hasn't patched, or simply a host with weak isolation between accounts. Restoring the site again on the same infrastructure just resets the clock until the next incident. Migrating to a properly isolated, current environment fixes the actual cause.

The plugin or theme stack has outlived its support. A site running a theme that hasn't been updated in three years, on a PHP version the plugin authors dropped support for two versions ago, isn't really restorable in the sense of "get it back exactly as it was." That state is what got it broken. A restoration that puts the same outdated stack back online is a temporary fix on an expiring clock. This is usually where a scoped rebuild of the affected areas, on a current stack, costs less over a year than repeated restoration cycles.

The request started as "restoration" but the real ask is redesign plus recovery. We get a meaningful number of "Website Migration and Design" requests that begin with a broken or hacked site and end with the client deciding, reasonably, that if they're rebuilding the compromised sections anyway, this is also the moment to fix the design and information architecture problems they'd been living with. That's a fair call, but it changes the scope and the timeline, and it's worth naming explicitly rather than letting a restoration quote quietly turn into a redesign one without the client agreeing to that shift.

What does a proper restoration actually involve, end to end?

Once isolation is done and the restore-versus-rebuild call is made, the sequence looks like this:

  1. Confirm the entry point. Check access logs, recently modified file timestamps, and any known CVEs for the installed plugin and theme versions around the incident date. Restoring without knowing this is restoring blind.
  2. Restore or rebuild the affected layer. Files, database, or both, depending on where the damage is. A defaced homepage might be a files-only issue. A spam-injection attack that's been running for weeks is usually in the database too.
  3. Update everything before bringing the site back. WordPress core, every plugin, the theme, and PHP version, all current, before the site goes public again. Restoring old files and then updating afterward leaves a window where the same vulnerability is live again.
  4. Scan clean, then scan again. A malware scan immediately after restoration, and a second one a few days later, catches the cases where a backdoor was planted somewhere the first pass missed, a fake plugin file, an injected line in functions.php, a scheduled task that reappears.
  5. Remove the site from any blocklist. If Google Safe Browsing, a hosting provider, or an email deliverability service flagged the domain, that flag doesn't clear on its own once the site is clean. Each one has its own review request process, and this step is easy to forget because the site "looks fixed" from the inside while still showing a warning to every visitor.
  6. Put monitoring and backup retention in place going forward. The single most common reason we see the same domain again eighteen months later is that nothing changed after the first incident: same host, same backup schedule, same lack of a security plugin actually configured to alert anyone.

What should you have ready before you call an agency about this?

Whether you come to us or anyone else, this shortens the diagnostic phase by a day or more:

  • Hosting control panel access, or confirmation of who has it
  • WordPress admin access, if it still works
  • Any error messages, screenshots, or the exact wording of a host suspension notice
  • Rough timeline: when did it last definitely work, and when was it first noticed broken
  • Whether a backup exists and, if you know it, how far back it goes

None of this needs to be perfect. Half of what we do on the first call is reconstructing this timeline from whatever the client has, because the honest answer to "when did this start" is usually "we're not sure."

Where to go from here

If your site is down or flagged right now, isolate it first, change your credentials, and check your host's backup retention before anything else. That sequence costs you nothing and it's the difference between a clean restoration and restoring straight back into the same problem.

We run this exact process as part of our broader web development work at GoDesign, restoration and migration included, not as an afterthought bolted onto new builds. If you're earlier in the decision, still weighing whether the agency that built or "fixed" your site last time is worth going back to, our sister site GoDesign has written the buyer-side version of this same problem: what to do when a WordPress or Shopify site needs recovering after a bad agency covers the questions to ask before you hand the keys over a second time.