# How do I rebuild a WordPress site from scratch without losing data?

> Rebuild safely by capturing the live site before you touch anything: crawl every URL, export the content, images, and metadata, and keep your analytics and Search Console records. If the database is corrupted, you can still recover the content from the front end by crawling the rendered pages. Then rebuild clean and map every old URL to a 301. WPBuildAI runs that capture-first rebuild, so the content survives even when the WordPress install does not.

Source: https://wpbuildai.com/rebuild-wordpress-site-from-scratch-no-data-loss/
By lawrence-arya · 2026-06-17

---
To rebuild a WordPress site from scratch without losing data, the order is everything: capture the live site before you change a thing, then rebuild from that capture. Crawl every URL, export the content, images, and metadata, and keep your analytics and Search Console history. Even if the database is corrupted or you are locked out of the admin, the content is still recoverable from the rendered front end. Then rebuild clean and map every old URL to a 301. WPBuildAI runs that capture-first rebuild, so the content survives even when the WordPress install does not.

Take the backup before you touch anything, and treat plugin data as the fragile part: Patchstack recorded [11,334 new WordPress vulnerabilities in 2025 with 91 percent in plugins, 9 percent in themes and only six in core](https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/), which is also a fair map of where custom data tends to be stored in non-standard ways.

## Capture before you touch anything

The data you are afraid of losing is, in almost every case, still visible on the live pages. A crawl of the rendered site captures the text, headings, images, and links exactly as visitors and search engines see them. Doing this first, before any change to the site, means you are never working without a safety net. The mistake that causes real loss is starting the rebuild, or deleting the old install, before the capture exists, because then the only copy of some content is the one you just broke.

A complete capture is also more than the words. It includes the full URL list, the metadata, and the internal-link structure, all of which you need later for redirects and for rebuilding the site faithfully. Treat the capture as the master record of the old site, and everything downstream becomes a matter of rebuilding from it rather than reconstructing from memory.

## Recovering from a broken database or a locked admin

The hardest case is when the database is corrupted, the admin will not load, or you have lost access entirely. The reassuring part is that the front end usually still renders, and the front end is where the valuable content lives. A crawl of the rendered pages captures what visitors see without needing the admin, the database, or working plugins, only that the pages still load. This is recovery rather than a database restore, so it will not bring back unpublished drafts or internal settings, but it preserves the published content that has value and rankings.

This is the same approach used to rescue a [hacked WordPress site](/extract-data-from-hacked-wordpress-site/), and for the same reason: depending on the public, rendered pages is more robust than depending on the internal state of a broken install. When the database cannot be trusted, the front end is the source of truth.

## Decide what is worth keeping

Not every page deserves to be rebuilt. Ahrefs found in its [search traffic study](https://ahrefs.com/blog/search-traffic-study/) that most pages on a typical site earn little or no organic traffic, while a minority carry the load. A full capture lets you see which pages matter, so you rebuild and redirect the valuable ones and retire the dead weight on purpose rather than dragging years of clutter into a fresh site. A from-scratch rebuild is a rare chance to prune, so use the capture to make those decisions deliberately.

Sort the captured pages by traffic and backlinks. The high-value pages get rebuilt carefully and their redirects verified by hand; the long tail can be handled in bulk or retired. This prioritisation is what keeps the rebuild focused on what actually drives the business rather than treating every URL as equally precious.

## Rebuild on a clean, fast foundation

Once you have the content, rebuild on a clean foundation rather than reviving the old one. The point of going from scratch is to leave behind the slow, plugin-heavy install, so the new site should be lean and fast. A lighter build passes [Core Web Vitals](https://web.dev/articles/vitals) more easily, and Portent's study of [site speed and conversion](https://www.portent.com/blog/analytics/research-site-speed-hurting-everyones-revenue.htm) shows how much that speed is worth in revenue. Rebuilding the content onto a fast platform is what turns a forced recovery into an upgrade.

## Protect the URLs, or the rankings go

A clean rebuild keeps its rankings only if the URLs survive. Map every old URL to its new home with a 301, keeping slugs the same wherever you can. Google treats a complete old-to-new mapping as the core of a safe move in its [site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes), and skipping it is how from-scratch rebuilds quietly lose traffic. The captured URL list is exactly the input the redirect map needs, which is another reason the capture comes first. The rankings question is covered more fully in [will I lose rankings if I change platforms](/blog/will-i-lose-google-rankings-if-i-change-my-website-platform/).

## A safe from-scratch rebuild, step by step

1. **Capture the live site** first: crawl every URL and export content, images, and metadata.
2. **Recover from the front end** if the database or admin is broken.
3. **Decide what to keep**, sorting by traffic and backlinks.
4. **Rebuild clean and fast** on a new foundation, from the captured content.
5. **Map every old URL** to a 301, keeping slugs where possible.
6. **Verify on staging**, then cut over on the same domain and watch Search Console.

The order is the safeguard: each step depends on the capture done first, so nothing is reconstructed from memory.

## A worked example: a slow site with a flaky database

Picture a six-year-old WordPress site that has grown slow and occasionally throws database errors. The owner wants a fresh, fast site but is afraid of losing content. The capture-first approach removes the fear: crawl the live pages while they still load, export the content and the URL list, and confirm the capture is complete before touching the install. Even if the database fails entirely the next day, the content is safe in the export.

From there the rebuild is routine. The content goes onto a clean, fast platform, the valuable pages are prioritised, the redirects are mapped from the captured URL list, and the site is verified on staging before cutover. The owner ends up with the same content and rankings on a faster site, and the flaky database is simply gone, not revived. The fear was reasonable; the capture-first order is what answers it.

## How this differs from restoring a backup

Restoring a backup and rebuilding from scratch solve different problems. A backup brings the old site back exactly as it was, which is right when you want the same site after a mishap. A from-scratch rebuild keeps the content and rankings but replaces the foundation, which is right when the old install was slow, fragile, or compromised and you want to leave it behind. The capture is the bridge: it preserves what has value so you can rebuild fresh rather than reviving the install you were trying to escape. Choosing between them is really choosing whether you want the old site back or a better one with the same content.

## What you cannot recover, and how to plan for it

A front-end capture preserves published content, but it does not recover unpublished drafts, private user data, or internal configuration that never rendered. If those matter, you need database-level access while it still works, so the honest plan is to capture the front end as your baseline and, where possible, also export the database before it fails. Knowing the limit up front prevents the unpleasant surprise of expecting a draft to survive a front-end crawl. For most sites the published content is what carries the value, but it is worth confirming nothing critical lives only in an unpublished state.

## Verifying the capture before you proceed

A capture you have not checked is not yet a safety net. Before touching the old install, confirm the export is complete: the page count matches your expectation and the sitemap, the high-traffic pages from analytics are all present, and the content inside a sample of files is the real page, not a half-rendered fragment. Confirm the images came across with their alt text and that the URL list covers everything, including orphaned pages found via the sitemap and analytics. Only once the capture is verified should you make any change to the source site, because that verification is what lets you proceed without fear of losing something you never captured.

## Keep the old site live until the new one is verified

Timing protects you as much as order. Keep the old site running until the new one is rebuilt, verified on staging, and ready to launch, so there is always a working version while you work. Cut over by pointing the domain at the new site only after the redirects are mapped and tested, and keep the old host available during DNS propagation so no visitor hits a gap. Tearing down the old site before the new one is proven is the avoidable mistake that turns a routine rebuild into an emergency, and keeping both alive briefly costs little.

## Rebuilding the media and the internal links

Two things travel with the content and are easy to neglect. Images need to be re-hosted on the new site and their references updated, so nothing points back at the old media library that will eventually disappear. Internal links need to point at the new URLs directly, rather than relying on redirects to catch them, which keeps the link structure clean and fast. The capture should include both the media with its alt text and the internal-link graph, so the rebuild can reconnect them. A rebuild that keeps the text but breaks the images and links is only half done, and the gaps show up as broken pages after launch.

## The 30-day watch after launch

Launch is the start of verification, not the end. Resubmit the sitemap, then watch Search Console for the following month for a spike in 404s or a drop in indexed pages, both of which point at a URL that was missed or misredirected. Spot-check that old URLs return a single 301 to the right page, and keep an eye on rankings for the high-value pages. Catching a missed redirect in the first week, while it is a handful of URLs, is far cheaper than discovering it months later as a slow decline. The capture and the redirect map do the heavy lifting, but the post-launch watch is what confirms they worked.

## When a rebuild is not the right answer

If the only problem is a one-off corruption and the site is otherwise healthy and fast, restoring a clean backup is simpler than rebuilding. If the site depends on a specific plugin or custom system with no clean equivalent, a from-scratch rebuild may not be feasible yet. The capture-first rebuild shines when the foundation itself is the problem, slow, plugin-heavy, fragile, or compromised, and you want the content on something better. Matching the approach to the actual problem keeps you from rebuilding when a restore would do, or restoring a broken site when a rebuild was the real fix.

## Doing it yourself versus handing it off

A capable developer can run this process: crawl and verify the capture, rebuild on a clean platform, map and test the redirects, and watch the launch. The work is methodical rather than mysterious, and the order is the main thing to get right. What it asks for is time and care at the unglamorous steps, the complete capture and the redirect map, which are exactly the steps a rushed rebuild skips. If you would rather not own that risk, a done-for-you rebuild handles the capture, the clean rebuild, and the verified redirects for a fixed scope, so the from-scratch move keeps your content and rankings without you managing each step. WPBuildAI runs that process; send your site URL for a quote.

## Key points to remember

Capture the live site first, recover from the front end if the database is broken, decide what is worth keeping, then rebuild clean and 301 every URL. The content lives on the rendered pages, so a rebuild does not have to mean a loss, and the capture-first order is the safeguard that makes it safe. A from-scratch rebuild is also a chance to leave a slow, fragile foundation behind and land the same content on a faster one. WPBuildAI runs the capture and the rebuild together, so you get a fresh, fast site without losing your content or your rankings; send your site URL for a fixed quote.

Not affiliated with WordPress or Lovable.