Sometimes a website has one page that starts acting like its own business.

It has a separate audience. It has a separate call to action. It may even have its own lead form, phone number, positioning, and follow-up process.

At that point, the temptation is to rebuild it from scratch as a new site.

That is usually the wrong first move.

The safer move is feature extraction: lift the working page into a new project, prove it still behaves the same way, then adjust the surrounding shell.

Preserve Behavior Before Improving Anything

A page that is already working contains a lot of quiet decisions.

The spacing, form fields, success message, images, button labels, section order, and mobile behavior may not all be documented. Some of those choices came from taste. Some came from testing. Some came from a last-minute fix that nobody remembers.

If you start with a blank project, you risk losing those decisions.

For a standalone extraction, the first goal should be boring:

copy the page
copy the assets it uses
copy the shared styles it depends on
copy the API route if the form needs one
make the page render at /
build it

Only after that should you start changing the project wrapper.

The Wrapper Is Not the Product

Most extraction mistakes happen in the wrapper, not the page.

The new project needs its own package name, metadata, sitemap, robots file, legal pages, and navigation. But those are support systems. They should not become an accidental redesign of the core page.

This is where the order matters.

First, preserve the page body.

Second, remove unrelated routes.

Third, replace broken navigation with links that work in the new single-site context.

Fourth, update labels in the lead flow so notifications and errors match the new purpose.

Fifth, run a production build and a local page check.

That sequence keeps the work grounded. You are not asking, “Can I make this better?” You are asking, “Can I separate this without breaking what already worked?”

Watch for Hidden Dependencies

A page rarely stands alone just because it is one file.

It may import a header, footer, mobile CTA, form component, shared data file, global CSS, image assets, analytics snippet, or API endpoint. If any of those pieces still reference the old site, the new project will look fine at first glance but behave wrong in production.

The practical checklist is simple:

scan for old brand names
scan for old phone numbers
scan for deleted routes
check sitemap and robots output
check form notification labels
build after dependency changes
keep notes on what was copied and what was intentionally left behind

The point is not to over-polish the extraction. The point is to make the separation reliable enough that future work can happen inside the new project without dragging the original site along.

The Takeaway

When one page needs to become its own website, do not begin with a full rebuild.

Extract the working page first.

Then fix the shell around it.

That gives you a clean standalone project without throwing away the behavior, layout, and conversion details that were already doing their job.