Rebuilding the Site on a Domain You Bought

A domain shows up in your account with a link history attached. Somewhere out on the web, pages still link to URLs on that domain, and every one of those links currently resolves to nothing.

There are two ways to fix that. The simple one is a 301 redirect: how to point the domain somewhere useful, and what actually transfers when you do. It takes an afternoon and it works. The other way is to put a website back on the domain: same subject, same URL paths, new content that you wrote. That takes a weekend, and in some situations it is the better trade.

When Rebuilding Beats Redirecting

Rebuilding earns its extra weekend under a few specific conditions.

The links point deep rather than at the homepage. A redirect sends every inbound link to one destination, so a link that a specific guide earned arrives at a page about something else. Rebuild that path and the link lands on a page answering the thing it was linked for.

The old subject is adjacent to yours rather than identical. If the domain was a soil-testing blog and you sell garden tools, a redirect makes the visitor's journey strange. A rebuilt soil-testing site that links to your shop where it fits does not.

The domain still receives referral clicks. If a forum thread from 2014 sends fifteen people a month, those are visitors, not just crawl signals.

You want a property rather than a pointer, one that can rank on its own and earn new links.

Redirecting stays the right call when the old site covered exactly what you cover, when the link profile is shallow, or when you know you will not maintain a second site. Be honest about that last one before you start.

Recon: Finding Out What the Site Actually Was

Start With What Came With the Listing

Every listing on the marketplace already carries the archived-history signals we verified before it went up: how many Wayback snapshots are on record, the earliest verified year, the category and keyword themes drawn from its content history, and its clean-history status. Once a domain is delivered to your account you can run it through the domain report for the full breakdown of referring domains and history. That tells you what the domain was about. The archive tells you what it looked like.

Pull the Full URL List From the CDX API

The Internet Archive's CDX Server API indexes every capture the Wayback Machine holds, and it is a plain HTTP endpoint. One request returns every URL ever archived on a host:

curl "http://web.archive.org/cdx/search/cdx?url=example.com\
&matchType=domain&collapse=urlkey&filter=statuscode:200\
&fl=original,timestamp&output=json&limit=5000"

The parameters that matter:

• matchType takes exact, prefix, host, or domain. Use host for one hostname, domain to include subdomains, prefix to scope to a path.
• collapse=urlkey removes adjacent duplicates, so you get one row per URL instead of one row per capture.
• filter=statuscode:200 drops the errors and redirects the archive also recorded.
• from and to accept yyyyMMddhhmmss timestamps if you want a specific era of the site.
• fl picks the columns; the defaults are urlkey, timestamp, original, mimetype, statuscode, digest, and length.

What comes back is the old site's real URL inventory. For a single page there is also the simpler Availability API at http://archive.org/wayback/available?url=example.com/about&timestamp=20150601, which returns the closest snapshot to a date.

Read Some Pages, Not Just Count Them

To review the old site properly, wayback-machine-downloader (a Ruby gem, gem install wayback_machine_downloader) fetches a local copy with the directory structure intact and the original files rather than Wayback's rewritten versions. It takes --from and --to for date windows and --only and --exclude for path filters.

Use that copy for reading. Which brings up the part people skip.

The Copyright Rule, Plainly

Buying the domain buys the name. It does not buy the content.

The US Copyright Office is unambiguous: a work is protected "the moment it is created and fixed in a tangible form," and registration is voluntary rather than a precondition for protection. For anything created since 1978, the term runs for the life of the author plus 70 years, or 95 years from publication for work made for hire. A blog post from 2009 is under copyright well into the next century. The author still owns it whether or not they renewed the domain and whether or not they remember writing it.

So republishing the archived pages verbatim is infringement, and the fact that nobody claimed them changes nothing.

What you can take from the archive is the shape of the thing: the topics, the URL paths, the site structure, the questions each page set out to answer. What goes into the pages, you write. Rebuild in spirit, not by copy and paste.

That constraint works in your favor anyway. Google's spam policies define scaled content abuse as generating pages primarily to manipulate rankings, specifically "large amounts of unoriginal content that provides little to no value to users, no matter how it's created." Republished archive dumps sit squarely in that description.

Preserving the URL Structure

This is the technical reason to rebuild at all.

A link to example.com/guides/soil-ph is a link to that exact path. Redirect the domain and it resolves through a hop to a page about something else. Rebuild the path and it resolves directly, with no redirect chain to maintain and no argument about what a hop costs. The CDX list you just pulled tells you precisely which paths need to exist.

Not every archived URL is worth rebuilding. A ten-year-old site might have 4,000 archived URLs and 40 that anything links to. Cross-reference your CDX list against the domain's referring domains and rank paths by inbound links. Rebuild the ones with links, plus enough surrounding pages that the site reads as a site. The same evaluation logic in how to choose backlinks applies here at the page level.

Match the old URL forms exactly, including trailing slashes, casing, and any index.html suffixes the CDX rows show. Where the archive shows several variants of one page, pick a canonical form and 301 the others to it.

Handling the Paths You Do Not Rebuild

Do not let unbuilt paths return a 200 with an empty template. That is a soft 404 and it wastes crawl attention. Three honest options:

• Map it. If a new page covers the old page's topic, 301 the old path to it. Same topic only; a blanket redirect to your homepage is not a mapping.
• Mark it gone. Return 410. Google treats 404 and 410 nearly the same, but 410 is the unambiguous "removed on purpose" signal and clears the URL out of the crawl schedule faster.
• Leave it 404. Fine as the default for the junk any old site accumulates: session-id URLs, print views, dead feed endpoints, tag pages with one item.

Building It With AI Tools

The workflow is the same whichever tool you pick. Feed in the archived URL list and a summary of what the site covered, have the tool generate the structure and draft the pages, then read every page before it ships.

Claude Code

Claude Code is an agentic coding tool that reads a codebase, edits files, and runs commands. Install it with curl -fsSL https://claude.ai/install.sh | bash, then run claude inside a project directory; it also runs in VS Code, JetBrains, a desktop app, and the browser, and needs a Claude subscription or a Console account.

This is the option when you want a repository you own. Hand it the CDX output directly ("here are 240 archived URLs, create one content entry per path under /guides/") and it writes files across the tree, scaffolds an Astro or Next.js project, and wires up the build. A CLAUDE.md at the repo root holds the standing rules for the rebuild: the subject, the tone, and the instruction never to reproduce archived text.

Lovable

Lovable generates an app from a prompt in the browser. The free tier grants five build credits a day, up to thirty a month. Custom domains require a paid plan, and the project has to be published before a domain serves anything. Connecting one means an A record to 185.158.133.1 plus a _lovable TXT record for verification, with any stray AAAA records removed. SSL usually issues within minutes and can take up to 72 hours.

Pick it for the shortest distance between a prompt and a live page, when you do not need the source in your own git history.

v0

Vercel's v0 starts free with $5 of monthly credits and a seven-message daily cap; Plus is $30 per user per month, Business $100. It deploys straight to Vercel and syncs to GitHub, and it is the strongest of these four on visual design.

It is the weakest on volume. Credits meter actual input and output tokens, so a 200-page content rebuild gets expensive faster here than elsewhere.

Bolt.new

Bolt is StackBlitz's in-browser full-stack builder. Free gives 300K tokens a day and 1M a month; Pro is $25 a month for 10M tokens; Teams is $30 per member. Paid plans include custom domains and drop the Bolt branding, and unused tokens roll over for a month. It imports from GitHub or Figma if you have an existing design to work from.

The Quality Bar

Whatever generated it, the rule does not change: read every page before it ships. These tools are good at structure and unreliable about facts. A rebuilt page should genuinely answer the question its URL implies, and it should be a page you would link to from your own site without wincing.

If you cannot get 40 pages to that standard, ship 12 and 410 the rest. A twelve-page site that is real does more for you than a 200-page site of filler, and it keeps your main property well away from a spam policy.

Shipping It

Hosting

Static output is cheap or free almost everywhere:

• Cloudflare Pages: 500 builds a month on the free plan, up to 20,000 files per deployment, 25 MiB per asset, 100 custom domains per project.
• Netlify: the free plan includes custom domains with SSL, metered through a 300-credit monthly allowance (15 credits per production deploy, 20 per GB of bandwidth).
• GitHub Pages: 1 GB published site size, a 100 GB monthly soft bandwidth limit, and a soft limit of 10 builds an hour. Plenty for a small rebuild.
• Vercel: the Hobby tier is non-commercial under its terms, so a site supporting a business belongs on a paid plan.

Astro fits this shape of project well, since content collections map cleanly to one file per archived path and the output is static by default. npm create astro@latest starts one, and it deploys to all of the above.

DNS and the Custom Domain

Point the domain at whichever host you chose. On Cloudflare Pages, an apex domain needs the zone on Cloudflare's nameservers and the CNAME gets created for you; a subdomain can simply CNAME to yourproject.pages.dev from any DNS provider. Certificates issue automatically unless a CAA record blocks the certificate authority.

Sitemap and Search Console

Generate a sitemap.xml, reference it from robots.txt with a Sitemap: line, then verify the property in Search Console and submit it there. One file caps at 50,000 URLs or 50 MB uncompressed. Google is blunt about what this buys you: "submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site."

Use the URL Inspection tool for individual pages and the sitemap for everything else. Google notes that "requesting a recrawl multiple times for the same URL won't get it crawled any faster," so asking once is the whole play.

Linking It to Your Main Site

This is the reason you did the work, and the part that decides whether it helps or hurts.

Done properly it looks unremarkable: a maintained site, on its original subject, that links to your main property in the places a reader would want that link. One or two contextual links from pages where your product or guide is the obvious next step. A real about page. Something new published now and then.

Done badly it looks like the practices Google's link spam policy names outright, among them "buying or selling links for ranking purposes," "widely distributed links in the footers or templates," and "low-quality directory or bookmark site links." A sitewide footer link from your rebuilt site to your commercial site is the middle one exactly, no matter how good the rest of the site is.

What the Expired Domain Policy Actually Says

Google's spam policies define expired domain abuse as buying an expired domain and repurposing it "primarily to manipulate Search rankings by hosting content that provides little to no value to users." The illustrative examples are all large topic jumps toward commercial intent: "Affiliate content on a site previously used by a government agency," "Commercial medical products being sold on a site previously used by a non-profit medical charity," "Casino-related content on a former elementary school site."

The March 2024 announcement that introduced the policy states the other half plainly: it is fine to use an old domain name for a new, original site that is designed to serve people first.

Read together, the line is about intent and topical distance, not about the act of buying a lapsed domain.

Why Networks Get Caught and Single Sites Usually Do Not

Detection is a footprint problem. Networks of resurrected domains tend to share a hosting range, an analytics or ad account, a near-identical template, registration patterns, cross-links between members, anchor text that repeats across properties, and pages that read like one article with the nouns swapped. Any single overlap is weak evidence. Ten sites sharing eight of them describe a graph, and graphs get deindexed as a unit, which is why a network penalty tends to remove every link at once rather than one at a time.

One rebuilt site on ordinary hosting, with its own analytics, its own writing, and a couple of relevant outbound links does not form that shape. The risk scales with the number of thin properties you run, not with the fact of having relaunched one.

What to Expect After Launch

Reindexing is slow in a specific way. Google's own guidance is that crawling "can take anywhere from a few days to a few weeks" after a request. A domain with archived history and live inbound links usually sits at the faster end, because those links are already known and get followed. A domain that sat parked for a year has no accumulated crawl demand, and Google rebuilds that gradually.

A rough first quarter: the homepage and sitemap-listed URLs get crawled within the first week or two, with partial indexing. Coverage fills in over the following month or so as internal and inbound links get followed, and long-tail queries surface first. By month three the site is roughly what it is going to be until you change something.

Against a redirect, the equity path differs rather than simply beating it. A 301 consolidates the old domain's signals into your destination in a single move and takes effect sooner. A rebuild keeps those signals on the domain and passes a share along the specific links you place, which is slower and more work, and leaves you with a property that ranks on its own and keeps forwarding referral clicks from links nobody had to buy.

Choose the redirect when the old subject and yours are the same subject. Choose the rebuild when the domain earned deep links you would rather resolve than forward, and when you will still be updating the site in six months. Most rebuilds that fail do not fail on that choice. They fail because nobody touched the site after launch week.

Related

For the redirect route done properly, including how to build a page-level URL map, what Google's expired domain rules allow, and which signals tell you the equity actually transferred, see redirecting an aged domain so its link equity transfers.