1Footer documentation
Choose how your footer reaches the page
Compare server rendering, build snapshots, CMS exports, compatible edge delivery and browser embeds before connecting a website.
Last reviewed
Start with the HTML visitors receive
To deliver real footer links in the initial document, use server rendering, a build snapshot, native CMS output or compatible edge delivery. Automatic migration repair is a separate capability: installing a package does not give 1Footer access to publish your next website.
| Method | Initial HTML | How later changes arrive |
|---|---|---|
| Server or native adapter | The server includes the footer links and styles in the page. | The adapter loads or synchronizes the publication according to its caching and publishing workflow. |
| Build or CMS snapshot | Published pages contain the exported footer HTML and CSS. | A new build or CMS publication must include the updated snapshot. |
| Compatible edge delivery | The connected edge adds footer HTML before the response reaches visitors. | Managed delivery uses the published footer; the host and domain must permit this setup. |
| Browser embed | An empty mount or script alone does not contain the rendered links. | JavaScript loads the footer after the page arrives. This alone does not establish initial-HTML delivery. |
Server rendering and native delivery
The released native Vercel path covers Next.js App Router and TanStack Start. The React SDK can also load a footer artifact in a server-rendered application. Keep any workspace API key on the server and pass the actual pathname for page targeting.
Native CMS delivery must use the platform’s publishing system. The WordPress package can render on the server; broader automatic native installation and migration repair remain in development.
Build snapshots and CMS exports
Static HTML and CMS exports can deliver usable links without browser JavaScript. Include both the exported HTML and CSS in the published document. Generate the correct footer for each included route.
A snapshot stays at its published version until the website publishes again. A later link edit, pause or page-rule change in 1Footer does not rewrite a disconnected static export. Add snapshot refresh to your existing build or CMS publishing workflow.
Compatible edge delivery across frameworks
Connected Cloudflare delivery can add the published footer to an eligible website’s response without installing a framework-specific source component. This can cover a host or framework change while the connected zone and destination origin remain valid.
The domain and hosting provider must allow the proxy arrangement. Shopify and Wix require native paths. An incompatible proxy is not a supported way to turn their browser widgets into server-rendered footers.
Confirm the public result
- Find the actual current link labels and destinations in the page response.
- Check an included route, an excluded route and navigation between them.
- Confirm the footer remains usable with JavaScript disabled.
- Check the latest public delivery result after publishing, rather than relying on an editor preview.