The safest way to extract data from a hacked WordPress site is to work from the front end, not the compromised admin or database. If the public pages still load, you can crawl them and capture your content, images, and structure as clean files, without running the hacked code or trusting an infected database. That distinction matters: a database export from a compromised install can carry the infection straight into your new site. Recover the clean, rendered content, then rebuild on a fresh, secure site and redirect the URLs. WPBuildAI extracts content and media from the rendered front end, so you rescue your data without bringing the hack along.
The odds here are not in your favour by accident: Patchstack found the weighted median time to first exploit is five hours for heavily targeted WordPress vulnerabilities, and that 46 percent of the vulnerabilities disclosed in 2025 had no patch available at the moment of disclosure.
Why the database is the risky path
The instinct after a hack is to grab a full database backup, but that can defeat the purpose. A compromised install often has injected content, malicious scripts, or backdoors hidden in the database, and importing it can re-infect the rebuild. The 2024 Web Almanac reflects how much of a WordPress site lives in the database and how tangled it is, which is exactly where a hidden payload can sit unnoticed, in a post’s stored HTML, in options, in user rows. WordPress’s own my-site-was-hacked guidance stresses how thoroughly a compromised install has to be cleaned before it can be trusted, which is precisely the work you avoid by recovering from the front end instead. The rendered front end shows the clean content a visitor sees, with no hidden code attached.
Why the front end is the clean source
The reason the front-end approach is safe is that you only take the output, never the machinery. A crawler requests your public pages exactly as a visitor’s browser would and receives rendered HTML, the headings, text, and images that make up your content, with none of the PHP, plugins, database rows, or admin that a hack lives in. You are copying what the site says, not how it runs, so there is nothing executable to bring across. Even if the install is riddled with backdoors, the rendered article about your services is just text and image references. This is the core insight of a hacked-site rescue: separate the content (safe, on the front end) from the system (compromised, behind it), and take only the former. The output is trustworthy in a way the underlying install no longer is.
What you can recover, and what you cannot
A front-end crawl recovers most of what has value: published pages, posts, images, and the site structure, because the public site still renders them even when the admin is locked or defaced. Ahrefs found in its search traffic study that a small set of pages carries most organic traffic, and those high-value pages are precisely the public ones a crawl captures, so the rescue protects the content that actually matters for rankings. What you will not get from the front end is unpublished drafts, private settings, plugin configurations, or user data that never renders publicly. For most sites those are not what makes the site worth saving; the published content and its rankings are. So the front-end crawl recovers the valuable, public material and leaves behind the private configuration, which you would rebuild fresh anyway on a clean install.
A worked example: a defaced homepage
Picture a site whose homepage has been replaced with a defacement and whose admin login now fails, classic signs of a compromise. Panic suggests restoring a database backup, but that backup may carry the backdoor that allowed the hack. Instead, the rescue crawls the site’s known URLs, from the sitemap, analytics, and Search Console, and finds that while the homepage is defaced, most interior pages still render their real content. The crawl captures those as clean Markdown and downloads their images with alt text. The defaced homepage is simply rewritten fresh. The result: the site’s real content and media are recovered as clean files, with nothing executable taken from the compromised install, ready to rebuild on a fresh, secure platform. The hack is left behind entirely, because at no point did the rescue run the infected code or import its database.
How to do the front-end rescue, step by step
- Take the site offline or isolate it if it is actively serving malware to visitors, but keep a copy of the rendered pages reachable to you for the crawl.
- Assemble the URL list from the sitemap, analytics, Search Console, and any backlink data, so the crawl covers everything that mattered.
- Crawl the rendered pages and capture content as clean Markdown or HTML, dropping scripts entirely.
- Download every image with its alt text and path, as in extracting all images at once.
- Rewrite any defaced pages from memory or cached copies, since their live version is compromised.
Working from the rendered output throughout is what keeps the rescue clean, because nothing executable from the hacked install is ever taken across.
Rebuild clean, never on top
The one rule after a hack is to rebuild on a fresh installation or a new platform, never over the compromised files, because that is the only way to be sure the backdoor is gone. WordPress’s hacked-site FAQ is clear that a compromised install can hide reinfection vectors that survive a superficial cleanup, so starting clean removes the uncertainty entirely. Load the recovered content into the fresh build, then 301 the URLs so rankings hold, per Google’s site move guidance. This is the rescue version of rebuilding without losing data, and it is also the moment to fix the security problems that let the hack in, so the new site does not inherit the same exposure.
Preserving rankings through the rescue
A hack is a crisis, but it does not have to cost your rankings, and handling the URLs correctly is what protects them. Because the recovered content is going onto a fresh build, treat the rescue as a migration: keep the same URLs where you can so most pages do not move, and 301 any that change to their new home. Rankings attach to URLs and content, both of which you have preserved by recovering the rendered pages, so the new site can hold the positions the old one earned. Resubmit the sitemap once the clean site is live so Google recrawls and sees healthy pages where it may have flagged the hacked ones. The recovery and the ranking preservation are the same work: capture the content, rebuild clean, and map the URLs, so the site comes back both secure and intact in search.
When the front end is also down
Sometimes the hack has taken the public pages down too, not just the admin, and the front-end crawl has less to work with. In that case, widen the net before giving up. Google’s cache, the Wayback Machine, and your own analytics or previously-exported content can supply recent copies of pages whose live versions are gone or defaced. A staging copy or a pre-hack backup of the content, as opposed to the full compromised database, may also exist. The principle holds: recover the content from a clean source, never the infected system, even if that clean source is an archive rather than the live site. If only a partial recovery is possible, prioritise the high-traffic pages, since those carry most of the value, and rebuild the rest fresh. A degraded recovery from clean sources still beats reimporting a compromised database.
Common mistakes recovering a hacked site
The recurring errors all reintroduce the compromise. Restoring the full database backup to “save time” can carry the backdoor straight into the rebuild. Rebuilding on top of the existing files leaves hidden reinfection vectors in place. Logging into the compromised admin to export content risks running injected code. Forgetting to change passwords and keys, and to fix the vulnerability that allowed the hack, invites an immediate reinfection. And skipping the redirects in the rush to recover loses the rankings on top of the breach. Each is avoided by the same discipline: take only the rendered content from a clean source, rebuild fresh on a secure install, close the vulnerability, and map the URLs, which turns a hack into a clean restart rather than a recurring nightmare.
Key points to remember
Extract data from a hacked WordPress site by working from the front end, not the compromised admin or database, because a database export can carry injected scripts and backdoors while the rendered pages are just content. Crawl the public pages for clean text and images with alt text, using the sitemap, analytics, and archives to assemble the URL list, and fall back to Google’s cache or the Wayback Machine where the live pages are down or defaced. Rebuild on a fresh, secure install, never on top of the compromised files, close the vulnerability that allowed the hack, then 301 the URLs so rankings hold. WPBuildAI extracts the content and media from the rendered front end and rebuilds on a secure site, so you keep your data and your rankings without the hack; send your site URL for a fixed quote.
Not affiliated with WordPress or Lovable.