Can AI rebuild an old website?

Partly. A language model can take the text and structure of an old website and turn it into a clean, modern draft in very little time. What it cannot do is know which of the old site's facts are still true, who owns the words it is rewriting, or which old addresses still have links pointing at them. Those three gaps decide whether an AI rebuild is useful or a liability.

The tools sold as AI rebuilders generally read a live site the way a visitor would and hand back a redesign. That is the easy case. The harder one is the subject here: the site has gone, a public web archive holds a partial record of it, and the new draft has to be right about the present.

Given the right inputs, a model is good at the parts of a rebuild that are about form rather than fact.

• Drafting copy from structure. From an old page's headings, navigation and subject, it can write a clear first draft for the same purpose, often an improvement on copy that has aged badly.
• Modernising the layout. Old sites tend to carry dense sidebars, tables used for layout and very long single pages. A model can propose a cleaner structure: sections, headings and a sensible order.
• Summarising old content. Years of news posts or a sprawling "about" page can be condensed into a short history or overview, for a person to check.
• Doing the tedious work. Suggesting page titles, meta descriptions, image alt text and internal links across dozens of pages is quick for a model and slow for a person.

Google has no objection to any of this in principle. Its 2023 guidance on AI-generated content sits under the heading "Rewarding high-quality content, however it is produced" and says plainly: "Appropriate use of AI or automation is not against our guidelines." Its current guidance adds that generative AI "can be particularly useful when researching a topic, and to add structure to original content."

Ask a model to "rebuild example-domain.test" with nothing else and it will produce a plausible website for a business of that name, in which almost every specific is invented. The quality of an AI rebuild depends on what it is given, and three kinds of evidence matter.

1. The archived text and structure. What the old pages actually said, taken from captures in a public web archive such as the Internet Archive's Wayback Machine. Our guide to what can be recovered from an archived website sets out what is usually there and what is not: the text of public pages often, forms, search, logins and databases never.
2. The inventory of old addresses. The list of URLs the old site used, from the archive's index and from the sites that link to it. This tells you which pages existed and which still matter.
3. The owner's current facts. Today's phone number, prices, opening hours, team, services and accreditations. No archive holds these. Only the person rebuilding the site does.

The third input is the one most often missing, and its absence is where the trouble starts. Archived evidence is old by nature. Our archive study looked at 7,310 dropped .uk domains that had homepage history, a sample weighted towards well-linked names. The median gap between the last working homepage copy and the drop was 519 days. A model working only from a copy like that is working from facts that may already have been out of date when the domain lapsed.

Google's guidance gives the underlying reason in two sentences: "Keep in mind that generative models don't retrieve facts, but predict a likely sequence of words based on their training data. Because of this, generative AI outputs may contain inaccuracies (also known as hallucinations)." In a website rebuild, that shows up in four predictable ways.

Invention

Ask a model to fill a services page and it will list services the business plausibly offered. Ask for a pricing table and it will produce prices. A contact section may come back with a phone number in the right format, and a testimonials section with quotes and names. None of this is malicious. The model is doing what it does, which is producing likely-looking text.

Stale facts repeated as current

The subtler failure is a fact that was true once. Suppose, as an example, an old page gives a phone number, says "Winner, Best Local Business 2014" and mentions "a team of 12". The model rewrites the page, the details survive, and a historical record has become a present-day claim. The phone number may now belong to someone else. The award reads as current. The team of 12 may now be two people. Nothing was invented, and the page is still wrong.

Blending the two

The most dangerous output mixes recovered fact and generated text so smoothly that a reader cannot tell which is which. A genuine company history followed by an invented sentence about serving customers across the region lends the authority of the first to the second.

Mixed dates

An archived site is not a single snapshot. Where a capture is incomplete, the Internet Archive says the Wayback Machine "will grab the closest available date" for the missing pieces. A model reading a replayed site can combine one year's price list with another year's team page and present both as a single moment.

The fix is to treat every specific fact on an old page as unconfirmed until the current owner confirms it. The table sets out the kinds of fact that cause the most trouble, what goes wrong if an AI repeats them, and what to do instead. They are the same kinds of detail that DropOps holds back in a rebuilt draft until the owner deals with them.

1. Read every page as a customer would, today. If a sentence would mislead someone acting on it this week, it is wrong, however well written.
2. Mark every specific. Numbers, names, dates, prices, places and claims each need a source: the owner's current information, or a recovered page you have checked.
3. Separate recovered from generated. For every factual sentence, know whether it came from the old site or from the model. If you cannot tell, treat it as generated.
4. Strip facts the model supplied. A model may draft the wording around a fact. It should not be the source of the fact.
5. Test every contact route. Phone numbers, email addresses and forms. A form recovered from an archive never worked there, so it has to be rebuilt and tested.
6. Check rights to every recovered paragraph and picture. Being in an archive is not the same as being yours to republish.
7. Check the people. Names, photographs and quotes of individuals need a reason to be there and, ideally, their agreement.
8. Review the metadata too. Page titles, meta descriptions, structured data and image alt text can appear in search results, so they need the same fact-check as the body copy.
9. Give every old address a decision. Keep it, redirect it to its closest equivalent, or retire it. Do not send everything to the homepage.
10. Decide whether to say how the content was made. Where a reader might reasonably wonder, a short note on how the site was produced helps.
11. Publish only on a person's say-so. Nothing should go live because a model finished.

Owning a domain name does not mean owning the words and pictures that used to be on it. In the UK, copyright arises automatically: GOV.UK lists "original non-literary written work, such as software, web content and databases" among the works protected without registration. The Copyright, Designs and Patents Act 1988 says "The author of a work is the first owner of any copyright in it", with the employer as first owner where an employee made the work in the course of employment. Commissioned work is the trap. GOV.UK's guidance is that the self-employed usually keep the intellectual property in work they were commissioned to do unless their contract hands it over, so whoever designed or photographed an old site on commission may still own that work.

Asking an AI to reword someone else's copy does not change who owns it. GOV.UK lists "making an adaptation of your work" among the things copyright stops other people doing, alongside copying the work and "putting it on the internet". Whether a particular rewrite crosses the line depends on how much of the original survives in it, which is a question for a lawyer, not for a model. The archive offers no cover either: the Internet Archive "does not make guarantees as to the copyright status of items" and expects users to make sure their use is "non-infringing".

Old pages often hold personal data too, such as names on team pages and in testimonials. The ICO notes that information about individuals acting as "sole traders, employees, partners and company directors" can be personal data where they are identifiable, and that personal information reused for a new purpose must be compatible with the purpose it was first collected for, and needs a lawful basis. A testimonial given to a previous owner, years ago, was given for that owner's site.

The position is clearest when you are the original owner, when you have the owner's permission, or when you write new content and use the archive only to understand what the old site covered. This is general information, not legal advice. Our guide to restoring a website from the Wayback Machine covers the practical side of a restore.

Review before anything is published

Google's guidance on generative AI content is direct: "It is critical to manually factcheck and review all AI-generated content for accuracy and trustworthiness before publishing." It adds that the review "also applies to metadata", naming page titles, meta descriptions, structured data and image alternative text, all of which can appear in search results.

The risk is scale, not AI

Google's spam policies define scaled content abuse as "when many pages are generated for the primary purpose of manipulating search rankings and not helping users", and give as an example "Using generative AI tools or other similar tools to generate many pages without adding value for users". A rebuilt site of a few dozen pages that serves the same visitors the old site served is a long way from that. A domain bought for its links and filled with hundreds of generated articles is not.

For a lapsed domain, Google's expired domain abuse policy is relevant too. It describes an expired domain "purchased and repurposed primarily to manipulate search rankings by hosting content that provides little to no value to users". Google's March 2024 announcement of the policy put the other side plainly: "It's fine to use an old domain name for a new, original site that's designed to serve people first."

Be open about how it was made, where readers would ask

Google's guidance on people-first content asks: "Is the use of automation, including AI-generation, self-evident to visitors through disclosures or in other ways?" It treats such disclosures as useful where a reader might reasonably wonder how something was created, rather than as a label for every page.

Old addresses need evidence, not a model's judgement

The part of a rebuild that most affects search is often not the copy but the addresses: which old URLs had links pointing to them, which to keep, and which to redirect and where. A model cannot know which old pages earned links unless it is told, and it may suggest addresses that never existed. Google's site-move guidance spells out the cost of getting this wrong: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error." The decision for each old address should come from evidence, meaning the archive's record of what existed and the links that point to it, and should be checked by a person.

DropOps Sites, the DropOps website builder for domains you own, is designed around the risks above. Phone numbers, prices, addresses, staff numbers, testimonials, awards and opening hours recovered from an archive are held back until the owner confirms, replaces or removes them, so they never become current text by default. The AI suggests changes to a draft; the owner reviews each one, applies or discards it, and can undo it. The AI does not publish, and nothing goes live until the owner does.

Each important old address is kept, moved to a clean new address with a single 301, merged, redirected, retired or flagged for the owner, on the strength of linking sites and the archive rather than the AI's judgement, with no chains, no loops and no dumping of old pages on the homepage. Bringing back the previous site as closely as possible is offered only once the owner states that the content is theirs to restore; DropOps keeps a record of that statement but makes no legal determination about it.

These are rules about how the builder behaves. They make a draft safer to review; they do not replace the review. If you would rather settle the approach first, our guide to choosing between restore, modernise, repurpose or start fresh walks through the decision.

Given the archived text, the inventory of old addresses and the owner's current facts, a model can turn an old site into a modern draft faster than a person can, and nothing in Google's guidance objects to that. The draft becomes a website only when someone who knows the business has checked every specific in it: each number, name, price, date and claim.

That check is where the time saved by the model is either banked or lost. Done properly, an AI rebuild is a fast route to an honest site. Skipped, it publishes yesterday's facts and a model's guesses under today's name.