1Footer documentation
Your website moved. What happens next?
See what 1Footer handles after a supported migration, how to read the repair result and what to do about old embeds or changed publishing access.
Last reviewed
Let 1Footer check the destination
For a supported connected destination, 1Footer runs the repair workflow in the cloud: check the current host and framework, confirm the publishing account and project, prepare the delivery adapter, and verify the current footer publication on the public website. You do not need to run a local script or prompt an AI for each migration.
Keep the website in its existing workspace so its published links, page rules and pause state remain available. A changed public domain or publishing account needs the correct updated binding and authorized access. Automatic reassignment is not available across every platform.
What happens automatically, and what needs you
| Situation | What 1Footer handles | Your next step |
|---|---|---|
| Supported destination with connected access | Scheduled detection, supported repair and public delivery checks. | Review the latest result. Your computer can be off. |
| New account or revoked publishing access | Check the destination and report incomplete access. | Connect the account that now controls the website. |
| Intentionally paused footer | Preserve the pause while checking the website. | Resume only when you want the footer back. |
| Disconnected HTML or CMS snapshot | Keep the shared footer publication available. | Refresh and republish the snapshot through your site workflow. |
| Automatic adapter still in development | Identify the available delivery paths and unfinished coverage. | Choose a released compatible path from the platform guide. |
Read the latest result before retrying
Checks and publishing take time. Pending work, a saved connection and a completed build do not establish a verified footer. Look for the latest dated delivery result for the public destination and current publication.
When a supported repair is in progress or a publishing response is uncertain, avoid repeatedly submitting the same change. Supported recovery checks provider state and saved progress before another write. Resolve reported access or source conflicts when attention is required.
An old builder name can remain in your source
A Lovable or Framer marker can survive a rebuild. It describes an earlier installation, rather than proving who hosts the website now. 1Footer uses fresh hosting and framework evidence to choose a supported destination adapter.
If you see two footers, distinguish the obsolete 1Footer installation from your website’s own navigation. Supported cleanup must stay within its owned installation and preserve unrelated content. Old-installation retirement remains incomplete across the full platform matrix; check its result separately from destination delivery.
When Cloudflare delivery is unavailable
Automatic repair is not limited to Next.js or TanStack on Vercel. Released paths also include other Vercel framework installers and native Netlify, WordPress, HubSpot and Shopify workflows, each with its own publishing requirements.
A destination that prohibits ordinary Cloudflare proxying needs its native delivery path. Shopify requires permitted theme access. Wix end-to-end native automation is still unfinished. Detecting a platform or saving credentials does not mean an unsupported native repair has been completed.
Confirm the footer visitors actually receive
- Open the public destination after redirects and publication finish.
- Compare the current link labels, destinations and footer styles with the published footer.
- Check the initial HTML and usable output with JavaScript disabled.
- Test real included and excluded pages, then navigate between them.
- Confirm there is one managed footer and your website’s other content remains intact.
- Review any old-installation cleanup separately. A destination check does not prove retirement finished.