Old Website Recovery: Getting a Site Back After Years Offline

A client called me last spring with a familiar problem. Her landscaping company had run for years on a website built in 2013, a tidy brochure site, a gallery of finished gardens, and a quote form that brought in most of her work. The domain lapsed in 2019. The hosting account was cancelled long before that. The designer had retired to Portugal and stopped answering email. She asked the question everyone asks in this spot: is old website recovery actually possible, or am I starting from zero?

The honest answer: probably yes, and probably more than you expect. Almost everything a public website ever showed to visitors was copied somewhere, by archive crawlers, by search engines, by somebody's backup script. The job is knowing what survives where, and being honest about the gaps. This is the workflow I use on jobs like hers, and the expectations I set before anyone spends a dollar.

What old website recovery actually means

Old website recovery is not a redesign, and it is not 'build me a new site that looks like the old one.' It means finding existing copies of the site, archived HTML, images, stylesheets, documents, and reassembling them into a working website you own again. One you can put on a domain, edit, and get leads from. The distinction matters because it moves the price tag by an order of magnitude: recovery reuses what already exists, while a rebuild pays someone to recreate it from screenshots and memory.

Three kinds of sources do the heavy lifting. Web archives, above all the Wayback Machine, hold crawled copies of public pages going back decades. Search engine caches used to be the second option, but Google retired its cache in 2024, so that well is mostly dry. And real backups, from your old host, your old developer, or a hard drive in a drawer, are the only place the behind-the-scenes pieces ever survive. Each source hands you a different slice of the old site.

Where copies of your site actually live

Before you restore anything, inventory the sources. Here is what each one realistically holds for a site that has been offline for years:

Read that table and a pattern jumps out: the presentation layer survives, the application layer does not. HTML, CSS, and images were public, so crawlers copied them. PHP scripts, databases, and admin panels sat behind the web server, where no crawler could see. For a brochure site or blog, the presentation layer is nearly the whole site. For a store or forum, you recover the catalog and the content, not the orders, accounts, or private messages.

Realistic expectations for old website recovery

I set expectations with numbers before touching anyone's site, because hope is not a plan. Based on recovery jobs over the past few years, here is what a good outcome looks like:

• Static pages and blog posts: 90–100% recoverable if the site allowed crawling.
• Images: usually 70–95%, depending on how deep the archive crawled and whether they lived on a separate CDN domain.
• PDFs and downloads: a coin flip. Crawlers often skipped files above a size threshold.
• Video: assume it is gone unless it lived on YouTube or Vimeo, in which case it was never lost.
• Databases, products, users, comments, orders: gone unless a real backup exists. Archives only ever saw rendered pages.
• Search rankings: partially salvageable. Keep the original URLs where you can, 301 the rest, and Google re-learns the site faster than you would think.

Two real jobs. A 2009 phpBB forum came back as 400-odd threads of static HTML, every post readable, zero user accounts. A client's WooCommerce store returned with its full catalog, every product description, and most photos, but no order history and no customer list. Both owners were happy, because both knew the shape of the outcome before the work started.

What survives, and what is gone for good

A quick inventory saves people a wasted weekend hunting for things that never had a copy:

• Usually survives: public HTML pages and blog posts, plus the images those pages referenced.
• Usually survives: stylesheets, JavaScript files, fonts, robots.txt, favicon, sometimes sitemap.xml.
• Usually survives: some PDFs and smaller downloads, if crawled pages linked to them.
• Gone without a backup: server-side code, PHP, Python, plugins, the theme's template logic.
• Gone without a backup: the database, products, post metadata, users, comments, orders.
• Gone without a backup: anything behind a login, and every working form, search box, and cart, the archives kept their looks, not their guts.
• Gone without a backup: email accounts, server configuration,.htaccess rules.

Two traps deserve special mention. If the old site had a robots.txt that blocked crawlers, the archives may hold almost nothing, check before you plan anything. And snapshots taken after the domain lapsed usually show a parking page or a scammy doorway site. Always restore from a snapshot taken while the site was genuinely alive; the newest capture is rarely the best one.

A step-by-step old website recovery workflow

1. List the URLs. Pull the site's URL inventory from the Wayback Machine's CDX index or calendar view, and grab sitemap.xml from a healthy snapshot if one exists.
2. Pick the right year. Scan the snapshot calendar for the last period where captures show the real site, not a parking page or a hack.
3. Fill gaps with archive.today. Pages Wayback skipped sometimes exist there, check your most important URLs one by one.
4. Restore the files. For a handful of pages, saving them manually works. For a whole site, run an automated restore: Restorix shows a free estimate with the exact archived file count, total size, and a locked price before you pay anything, then restores the site with internal links rewritten and old analytics stripped if you want.
5. Clean house. Remove archived ad tags and tracking scripts, canonicalize www or non-www, and convert internal links to relative so the site works on any domain.
6. Map the URLs. Keep original paths wherever possible and 301 everything you deliberately drop.
7. Deploy and verify. Crawl the restored site, fix the 404s, then hand a fresh sitemap to Search Console.

Cleanup is where DIY jobs stall. Manual copy-paste from archive.org leaves you with absolute links pointing back at web.archive.org and a decade-old analytics beacon firing on every page. The restore options exist for exactly this: stripping iframes and ad code, minifying assets, and making links domain-agnostic are checkboxes, not afternoons of find-and-replace.

Mistakes that sink an old website recovery

• Restoring from the newest snapshot instead of the healthiest one. The final year of a dying site is often parking pages and malware redirects.
• Letting the domain sit while you deliberate. Buy the domain back first, recovering content onto an address a squatter owns is wasted work.
• Mixing snapshot years. The 2016 navigation links to pages your 2014 copy does not have, and every menu becomes a 404 farm.
• Forgetting the CDN subdomain. If images lived on cdn.yoursite.com, check that hostname in the archive separately, it has its own snapshot history.
• Skipping the rights question. Restoring your own site is standard practice; republishing someone else's content wholesale is a copyright problem.
• Rebuilding on a locked platform before exporting. Get clean files first, structured article export to XML, CSV, or JSON exists for a reason, then decide where they live.

Costs, timing, and doing it yourself vs. hiring it out

DIY with copy-paste: free, and fine up to maybe twenty pages. Budget a weekend and a lot of patience. Free Wayback downloader scripts handle bulk but leave you with broken internal links and missing assets, the cleanup tax again. Paid restores price per file; Restorix charges per restored file with a small flat fee per restore, the first file free, the price locked at estimate time, and nothing that recurs. A few hundred files usually lands in the tens of dollars, and automatic refunds go back to your balance if a restore fails.

Timing breaks down the same way on every job: the restore itself is the fast part, hundreds of pages in well under an hour, and the human work after it is the slow part. My client's landscaping site came back as 86 pages and about 300 images. The estimate took a minute. Her weekend went to wiring up a working quote form and re-shooting two garden photos she had never liked anyway. The recovered site was better than the original within a week, which is the part nobody expects.

Putting the recovered site back online

A recovered brochure site can live happily on cheap static hosting. If the owner wants to edit content, and eventually they always do, deploy with a CMS attached instead of bolting one on later. Restorix deploys to an SSH/SFTP VPS, FTP shared hosting, or S3 in one click, and its deploys include a single-file CMS at /webarchive-cms.php with a per-site admin password, so the owner edits text and swaps images without touching code. Whatever you choose, finish with the boring essentials: fresh analytics instead of the 2013 tag, an XML sitemap, Search Console verification, and 301s for every URL you decided not to bring back.