Use the Capture, Rebuild, Reconnect, or Retire framework, a worked landing-page example, and a downloadable worksheet to turn an imported draft into a verified migration.

When you import a website with AI, the first draft can look reassuringly complete. The headline is there. The image is in roughly the right place. The call to action has the right label. That is useful progress, but it is not yet proof that you migrated the landing page.

A public page exposes what a visitor’s browser can observe. It does not automatically expose where a lead goes, which CRM owns the record, what happens after consent, how an ad platform counts the conversion, or which system sends a booking confirmation. Even a close visual reconstruction can sit on top of missing business behavior.

I treat an AI import as a new, editable draft plus a source of evidence. Then I give every detail one of four dispositions: Capture, Rebuild, Reconnect, or Retire. That keeps an agency from confusing “the page looks copied” with “the client can safely switch the domain.”

Decide what “import” means for this client

“Copy this page” can describe three different assignments:

• Close reconstruction: preserve approved copy, visual direction, URL, and behavior where the new platform supports them.
• Content migration: bring approved text and assets into a new design system.
• Redesign reference: use the old page as evidence of the business, then intentionally change its message and presentation.

Choose one before the import. Otherwise, every difference becomes an argument. The developer thinks a new mobile layout is an improvement, the designer thinks it is a regression, and the client thinks the old page was supposed to stay intact.

Record who owns the source and who authorized the copy. Confirm rights to the copy, photography, illustrations, icons, video, downloads, and fonts. A public URL is accessible, not automatically reusable. If a paid font or third-party asset cannot move, identify the replacement and approval path before launch.

I also take a source snapshot for review: full-page desktop and phone screenshots, the page title and metadata, the visible heading structure, primary links, menus, form states, and any animation or hover behavior that matters. Capture the source at a named time because campaign pages change.

Understand what a public-page import can observe

Current import products describe a similar basic mechanism with different output. Repaint’s import documentation says it reads visible text, downloads images, and uses screenshots to understand layout, then rebuilds a separate editable site. It also says content behind a login is unavailable and that forms, accounts, checkout, and private records do not copy directly.

InstaWP Studio’s public-site copy documentation makes the boundary concrete in another system. Its workflow copies public pages into a new WordPress site, not the original database or plugins. It lists changed motion, altered form handling, protected pages, blog structure, licensed fonts, and inaccessible images among the details that may differ.

Those are vendor-specific implementations, not a universal specification. They still illustrate the right question: what did this importer observe, what did it reconstruct, and what remains outside the draft?

An HTTP success is narrow evidence too. It means a request returned a response the browser accepted. It does not prove that the response contains the approved page, that the form delivered a lead, or that a conversion event fired once.

Make a source inventory before you evaluate the copy

Do not begin the review by scrolling the new page and asking what feels off. Build a small inventory from the source first.

For a single landing page, I would record:

• the exact source URL, final redirected URL, title, description, canonical, robots directives, social image, and structured data;
• every visible section, heading, paragraph, list, testimonial, price, guarantee, legal note, image, video, icon, and download;
• header, footer, sticky bars, cookie controls, menus, tabs, accordions, sliders, dialogs, and hover or scroll states;
• every form field, label, required rule, validation message, success state, and failure state;
• every outbound destination, including phone, email, calendar, checkout, CRM, file download, and thank-you page;
• analytics, advertising, consent, and experiment events the client expects;
• campaign links, old URLs, QR codes, email links, ads, and partner pages that send traffic here.

This inventory is not a demand to preserve every artifact. It is a way to make removal intentional. A dead tracking tag can be retired. An obsolete testimonial can be removed after client approval. A legacy form can be replaced. The worksheet should say so instead of letting omissions masquerade as successful automation.

Compare more than one screenshot

A visual comparison is necessary for a close reconstruction, but one desktop image is a weak test. It can hide a broken mobile menu, the wrong font fallback, clipped text, a missing focus state, or a form that changes height when errors appear.

Compare source and draft at representative desktop and phone widths. Open the navigation. Trigger an accordion. Tab through links and controls. Enlarge the text. Submit the form empty, with invalid input, and with a clearly labeled valid test. If the source has a video modal, sticky call to action, or consent banner, inspect that state explicitly.

The W3C Web Accessibility Initiative’s Easy Checks cover useful first-pass areas such as page titles, image alternatives, headings, contrast, resizing, keyboard access and focus, and form labels and errors. W3C is equally clear that these quick checks are not a definitive accessibility evaluation. Use them to find problems, not to manufacture a compliance claim.

When a difference is intentional, record the decision and approver. When it is accidental, record the selector, viewport, state, expected result, and evidence needed to close it. “Looks close” is not an acceptance criterion.

Use Capture, Rebuild, Reconnect, or Retire

Here is the framework I use to turn the inventory into work:

This is more useful than a binary “imported/not imported” field. A form’s labels may be captured, its validation rebuilt, its CRM route reconnected, and an obsolete autoresponder retired. One visible component can require all four dispositions.

Keep secrets out of the worksheet and prompts. Record the system owner, approved configuration path, and test evidence, not the credential value.

Rebuild the business journey from click to destination

Start with the primary conversion. Follow it beyond the browser.

1. Open the draft in a fresh session at phone and desktop widths.
2. Check labels, required fields, consent language, validation, and a deliberate failure.
3. Submit a clearly labeled test using non-sensitive data.
4. Confirm the browser’s success state or thank-you route.
5. Confirm the record in the approved inbox, CRM, booking tool, database, or payment sandbox.
6. Confirm the expected analytics event in the intended property and verify it did not fire twice.
7. Remove the test record when appropriate and retain non-sensitive evidence.

Repeat the same logic for phone links, email links, downloads, scheduling, account creation, checkout, or document uploads. If the client cannot identify the destination owner, that is a migration blocker, not a detail for after launch.

Fork’s agent documentation recommends giving the agent an outcome and a verification target. For an imported form, I would ask for both: “Route valid submissions to the approved lead destination, show an accessible success or failure state, and verify one labeled test from the browser through the destination.” The prompt guides the work. The observed test provides the evidence.

Preserve discovery paths and the production origin

If the domain and path stay the same, you still need to compare titles, descriptions, canonicals, robots rules, structured data, social cards, internal links, and the sitemap. If paths change, create an old-to-new URL map before cutover.

Google’s site-move documentation recommends preparing and testing the new site, mapping old URLs, updating canonicals and internal links, using server-side permanent redirects where possible, testing those redirects, removing migration-only noindex rules, submitting the new sitemap, and monitoring after the move. It also says ranking fluctuations can occur during significant moves. Preserving a path is useful; it is not a ranking guarantee.

Do not redirect every removed URL to the homepage. Give each valuable old URL a relevant destination, or return an appropriate not-found response when the content is truly gone.

The hostname is another operational boundary. Fork’s custom-domain documentation separates ownership verification, routing, and TLS provisioning, and recommends one canonical application origin for callbacks, cookies, and generated links. A DNS change is not the final test. Open the production hostname and repeat the critical journey there.

Worked example: a lead-generation landing page

Consider a fictional landing page for Northstar Renovation, a made-up design-build firm. Assume the source has a hero, three service cards, two testimonials, a project brief form, a downloadable planning PDF, a scheduling link, analytics, an advertising conversion event, and the path /start. There is no login or checkout. This is an illustrative plan, not a client project or migration result.

The first imported draft may finish the Capture rows quickly. The migration is held until the navigation works, the lead reaches the correct CRM pipeline, the calendar confirms a test, and the analytics behavior matches the approved consent states.

This example also shows why I would avoid redesigning the copy, changing the domain, replacing the form, and altering the campaign path in one untracked step. Separate intentional changes from migration defects so the team knows what caused a difference.

Keep recovery claims bounded

Retain the source and a rollback route through an agreed window. Record the source owner, new release identifier, cutover owner, rollback decision owner, and conditions that would trigger a reversal.

On Fork, file-changing work is checkpointed automatically, and history and snapshots provide read-only previews and explicit restore points. The documentation warns that a restore replaces current workspace state. I would preserve important later work before restoring.

I would not describe that workspace snapshot as a recovery plan for a CRM, mailbox, calendar, analytics property, payment provider, or DNS account. Those systems keep their own state. If the new page created an external lead or booking, restoring website files does not necessarily undo it.

Download the landing page import worksheet

I turned the framework into a downloadable landing page import worksheet. It includes the authority record, source inventory, four-disposition matrix, URL map, end-to-end acceptance record, release decision, and production pass.

Use only the rows that match the page. A brochure landing page does not need checkout tests. A page collecting health, financial, or other sensitive information needs a much deeper privacy, security, authorization, retention, and specialist review than this worksheet provides.

Common questions about importing a website with AI

Can AI copy a landing page exactly?

It can produce a close reconstruction in some cases, but “exact” needs a defined acceptance test. Compare approved content, assets, desktop and phone layouts, interactive states, and business behavior. Vendor documentation itself often lists elements that change or need rebuilding.

Will the old website change when I import it?

A public-URL import is commonly described as read-only and separate from the source, but verify the actual product and method you are using. Keep the old site live while you review the draft, and do not provide source credentials unless the chosen migration method explicitly requires an authorized transfer.

Does a copied form keep working?

Do not assume so. The visible fields may be reconstructed while delivery, validation, consent, spam controls, attachments, notifications, CRM routing, and analytics need new configuration. Test from input through the approved destination.

Does keeping the same URL preserve SEO?

Keeping useful paths reduces one source of change, but it does not guarantee unchanged search performance. Compare content and metadata, check canonicals and indexability, test redirects where needed, submit the intended sitemap, and monitor after cutover.

When is the import finished?

When the approved candidate matches the import contract, every inventory item has a disposition, critical journeys pass end to end on production, discovery paths are correct, the client has approved intentional differences, and the team has a bounded rollback plan.

Treat the import as the starting point

The valuable promise of an AI import is not that migration work disappears. It is that the agency can start from the client’s real page instead of a blank canvas.

Fork positions website import as the starting point for ongoing content, updates, and growth. Its agent can then work inside the selected website space, where changes can be inspected and verified. That is the right sequence: bring the page in, identify what the public page could not carry, reconstruct the business journey, and prove the result.

Before the domain moves, run the complete release through the live client website launch checklist. If you want to explore this workflow for your agency, join the Fork waitlist while access opens in batches.