Move your website without losing the footer

Before the move

A host move and a public-domain change are different. If the public domain also changes, confirm the website binding and destination ownership in the workspace. Automatic domain reassignment is not available across every platform.

• Keep the website in its existing workspace, with its published links and page rules.
• Check the destination’s delivery and automatic repair availability.
• Connect the account that controls the destination project or domain. Keep private keys in the connection flow.
• Leave an intentional pause in place. A platform move should not resume a paused footer.

What 1Footer does after a supported move

1Footer checks fresh public responses for the current host and framework. For a supported connected destination, it chooses the delivery adapter, prepares a repair and checks the staged result before publishing. The public footer must then match the current publication before the repair is verified.

For example, moving a Lovable-built site to a supported Next.js App Router or TanStack Start project on Vercel can use the released native Vercel path. A leftover Lovable mount does not establish the current host. A move to a different platform needs that destination’s supported adapter and publishing access.

Confirm the destination result

• Open the public domain after its redirects have finished, rather than only an editor or deployment preview.
• Confirm the actual footer links and styles are in the initial page HTML and match the published version.
• Test a real included page and excluded page, including navigation between them.
• Check that there is only one managed footer and that unrelated site navigation is intact.
• Check the latest dated delivery result. A queued or saved connection is not a verified repair.

If the migration needs attention

Keep the last healthy website available where possible. Fix revoked destination access or a conflicting source edit before retrying. An uncertain publishing response needs reconciliation with the provider; repeatedly submitting the same operation can create duplicate changes.

A CMS export or SDK package can deliver real footer HTML while its automatic native repair is still in development. Static snapshots need a fresh publication through the website’s build or CMS workflow. Do not enable an incompatible proxy to work around a native requirement.