How do I keep my SEO when moving off Framer?

To keep your search rankings when moving a site from Framer to Next.js, keep every URL exactly the same, carry over your redirects and page metadata, point metadataBase, robots.txt and sitemap.xml at your production domain, and switch DNS only after the new site is tested. A project converted by Deframer already preserves most of this: src/proxy.ts keeps each page's URL form, next.config.ts keeps the redirects your published site answered with, and every route file carries its title, description, Open Graph data and canonical URL. What remains is a short list of checks that only you can do.

Search engines care about continuity. If the same URLs return the same content with the same signals, a change of hosting is mostly invisible to them. This guide goes through each part in the order you would check it.

1. Keep every URL identical

The most important rule is the simplest: don't change URLs during the migration. If you want to restructure, do it later, as a separate change with redirects.

A converted project protects URL forms for you. Framer publishes each page at one form, usually without a trailing slash (/about), sometimes with one, and redirects the other form. The converted src/proxy.ts reproduces that policy:

• each page answers at the URL form the site published;
• the other form gets a 308 redirect to it, keeping the query string;
• URLs that match no page answer with the 404 page.

Because the proxy decides URL forms, next.config.ts sets skipTrailingSlashRedirect: true so Next.js doesn't apply its own trailing-slash rule on top. Leave both as they are unless you deliberately change your URL style.

In Next.js 16, proxy.ts is the file that used to be called middleware.ts. If you add your own request logic later, extend the existing proxy rather than creating a second file.

2. Carry over redirects

If you set up redirects in Framer's site settings, the converted next.config.ts lists them in redirects() with the same status codes, for example:

// Redirects the published site answers with (site settings → Redirects).
async redirects() {
  return [
    { source: "/old-pricing", destination: "/pricing", permanent: true },
    { source: "/2023-launch", destination: "/blog/launch", statusCode: 301 },
  ];
},

permanent: true sends a 308, permanent: false a 307, and statusCode keeps any other code, such as 301. Check the result page's notices for "A redirect wasn't carried over" and add any missing ones by hand.

Add new redirects to the same list. A common case is a page you rename after launch: redirect the old path to the new one with permanent: true, and update internal links so visitors don't take the extra hop.

3. Check page metadata and canonical URLs

Each page route has its own metadata export, evaluated at conversion time from the published page (real output, shortened):

export const metadata: Metadata = {
  openGraph: { type: "website", title: "…", description: "…", images: ["https://framerusercontent.com/assets/….jpg"], url: "/" },
  twitter: { card: "summary_large_image", title: "…", description: "…", images: ["…"] },
  alternates: { canonical: "/" },
};

CMS detail pages read the same data per item from a metadata.json file beside the route, through generateMetadata. The site-wide title, description and favicon live in the root layout, src/app/layout.tsx.

Open a few pages, view the source, and compare the <title>, meta name="description", canonical link and og: tags with the live Framer pages. If the result page lists "Page metadata that couldn't be computed", fill in those pages' metadata by hand. If you add CMS items, the CMS guide shows where their metadata goes.

4. Set metadataBase to your production domain

Canonical URLs and Open Graph URLs in the route files are relative (/, /blog/…). Next.js resolves them against metadataBase, which the root layout sets to the site's published URL:

export const metadata: Metadata = {
  metadataBase: new URL("https://yoursite.framer.website"),
  // …
};

If your Framer site was published on a custom domain and you're keeping that domain, this is probably already correct. If it was on *.framer.website or *.framer.app and you're moving to your own domain, change it:

metadataBase: new URL("https://www.example.com"),

Get this wrong and every canonical tag points at the old address, which tells search engines the old site is the original. If you converted with "Include assets locally", social images become relative paths too, so metadataBase also decides whether link previews show an image.

5. Update robots.txt and sitemap.xml

public/robots.txt and public/sitemap.xml are copied exactly as the site published them, which means they contain the published domain:

User-agent: *
Allow: /

Sitemap: https://yoursite.framer.website/sitemap.xml

1. Replace the domain in robots.txt with your production domain.
2. Find and replace the domain in every <loc> of sitemap.xml. On a multi-locale site, do the same in each per-locale sitemap.
3. When you add or remove pages later, update the sitemap too; it is a static file and doesn't follow your routes.

If you'd rather generate the sitemap from your routes, Next.js supports an app/sitemap.ts file. Delete public/sitemap.xml first so the two don't conflict, and check the Next.js docs for the current API.

6. Check analytics and verification tags

Site and page custom code from Framer is carried over as real elements in the layout and routes, so analytics snippets and verification meta tags you added there come along. Confirm your analytics records visits on a preview deployment. If you verified Google Search Console with an HTML tag, check that the tag is still in the page source; a DNS-based domain property doesn't depend on your host at all.

The Deframer verification tag is the one exception: the converter strips it from the project, and you can remove it from Framer once you've downloaded the projects you need.

7. Test on a preview URL, then cut over DNS

Deploy to your host's preview or staging URL first. Our deployment guide covers the major hosts. Then:

1. Crawl the old site with an SEO crawler or your sitemap, and request every URL on the preview. Each should return 200 at the same path, or the same redirect the old site gave.
2. Spot-check unknown URLs. A made-up path should return the 404 page with a 404 status, not a 200.
3. Lower your DNS TTL a day or so ahead, so the switch spreads quickly.
4. Point DNS at the new host following your host's instructions, and make sure HTTPS is issued for both the apex and www forms you use.
5. Disconnect the domain from Framer once traffic reaches the new host. Check Framer's documentation for the current steps.

Keep the old site unchanged until the new one is confirmed live, so you have a fallback.

8. Use Search Console after launch

1. Submit the updated sitemap in Search Console.
2. Use URL Inspection on a handful of important pages to confirm Google sees the new canonical and content.
3. Watch the Pages (indexing) report and crawl stats for a few weeks for spikes in 404s or redirect errors.
4. If the domain itself changed, for example from yoursite.framer.website to example.com, and you control both properties in Search Console, Google's Change of Address tool may apply. It requires permanent redirects from old URLs to new ones, so check Google's documentation and whether you can set those redirects on the old address.

A quick checklist

Deframer is an independent tool, not affiliated with Framer. If you're still deciding whether to move at all, the Framer vs. Next.js guide walks through the trade-offs, and the FAQ answers common questions about the conversion itself.