How to audit a website before migrating it to Next.js

To audit a website before migrating it to Next.js, build a complete URL inventory (crawl, sitemap and Search Console), record a baseline of organic traffic and Core Web Vitals, capture each page's metadata and indexability, list internal links, assets, forms and integrations, then turn all of it into a redirect map and acceptance tests. The audit defines "done" before you write code and gives you numbers to compare after launch. Nothing in it is specific to Next.js until the metadata step: the same audit applies if you convert a Framer site to TanStack Start, Astro, React Router or Vite.

Most of this applies to any platform: WordPress, Webflow, Squarespace, a custom stack or Framer. Steps marked Framer apply only to sites built with Framer; everything else is universal.

Why audit before a migration?

Because you can only preserve what you've measured. Google's guide to site moves with URL changes starts with mapping old URLs to new ones, and its guide to moving hosts without URL changes starts with testing the new infrastructure. Both assume you know what the old site contains. The audit is that knowledge, written down.

It also separates two decisions people often blur: whether URLs change. If every URL stays the same, the move is a hosting change and the redirect map is short. If any URL changes, every changed URL needs a permanent redirect.

Step 1: build the URL inventory

The inventory is one spreadsheet with a row per URL that exists or has existed. Combine at least three sources, because each misses something.

Universal:

• [ ] Download the sitemap: curl -s https://www.example.com/sitemap.xml -o sitemap.xml, and any child sitemaps it lists.
• [ ] Crawl the site with an SEO crawler (Screaming Frog, Sitebulb or similar) and export URL, status code, title, meta description, canonical, robots meta, H1 and inlinks.
• [ ] In Search Console, export the Page indexing report (both indexed and not indexed). Note that example tables there are limited to 1,000 rows, per Google's help page, so large sites need several exports or the API.
• [ ] Export landing pages from your analytics for the last 12 months.
• [ ] Merge everything into one sheet, deduplicate, and add columns: status, canonical, indexable, organic clicks, new URL, action (keep, redirect, remove).
• [ ] Note the URL conventions: trailing slash or not, lowercase, www or apex, query parameters that matter.

Framer:

• [ ] Framer publishes /sitemap.xml (and per-locale sitemaps on multi-locale sites); use it as the page list.
• [ ] Copy the redirects from the site settings into the sheet; they aren't in the sitemap.
• [ ] Check whether the site is also reachable at its *.framer.website or *.framer.app address, and which one is canonical.
• [ ] List CMS collections and their item counts; each item is a URL under a detail page path such as /blog/:slug.

Step 2: record an organic traffic baseline

A baseline lets you tell a normal post-launch wobble from a real loss. Google says visibility may fluctuate temporarily during a move and that for medium-sized sites it can take a few weeks or more for new URLs to show.

• [ ] Export clicks, impressions, CTR and average position per page from the Search Console Performance report for the last 3 and 12 months.
• [ ] Export the top queries for your top 20 pages.
• [ ] Record weekly organic sessions from analytics for the same period, so you know the usual seasonal range.
• [ ] Mark the pages that bring most organic traffic and conversions. They get the strictest acceptance tests.
• [ ] Screenshot or save rich results you appear in (FAQ, product, video), so you can confirm they come back.

Step 3: capture metadata and indexability

Every indexable page's title, description, canonical and robots directives should survive the move unless you change them on purpose.

• [ ] From the crawl, keep title, meta description, canonical, robots meta, X-Robots-Tag header, hreflang and Open Graph tags per URL.
• [ ] Flag pages that are noindex today and decide whether they stay that way.
• [ ] Check robots.txt: curl -s https://www.example.com/robots.txt. Note every Disallow and the Sitemap: line.
• [ ] Find canonicals that point elsewhere (duplicates, paginated lists) and record why.
• [ ] Check structured data (JSON-LD) on key templates with Google's Rich Results Test.
• [ ] Note the favicon, touch icon and default social image.

In Next.js App Router, page metadata lives in each route's metadata export or generateMetadata (see the Next.js docs), so this sheet becomes your source for those values.

Framer: each page's title, description and social image come from its page settings, with site-wide defaults in the site settings. A Framer project converted by Deframer carries these into each route's metadata, but the sheet is how you check them.

Step 4: map internal links

Internal links tell you which pages matter and which links will break if URLs change.

• [ ] From the crawl, export all internal links (source, target, anchor text).
• [ ] List links to URLs that already redirect or return 404; fix them on the new site instead of carrying them over.
• [ ] Note links in navigation and footer separately: they're on every page.
• [ ] Find hard-coded absolute links to your own domain (https://www.example.com/...) in content; they bypass relative routing.
• [ ] Note anchor links (/about#team) and check the target IDs exist.

Step 5: list images, fonts and other assets

Assets are easy to lose because they often live on a platform CDN rather than your domain.

• [ ] From the crawl, export image URLs and their hosts. Anything on a platform CDN depends on that platform staying available.
• [ ] Note which images have useful alt text and which are ranking in image search (Search Console, search type: Image).
• [ ] List PDFs, videos and downloads that have their own URLs and inbound links.
• [ ] List fonts and where they load from; check the licenses for self-hosting.
• [ ] Note the total page weight of key templates (DevTools Network panel, or the crawl).

Framer: images, fonts and videos load from framerusercontent.com. Decide whether the new site keeps them there or downloads them into the project; see Framer fonts and assets: CDN vs. local.

Step 6: inventory forms and integrations

Forms and third-party scripts are the parts that fail silently, so each one needs an owner and a test.

• [ ] List every form: page, fields, required fields, where submissions go today, who receives them.
• [ ] List every script and tag: analytics, tag manager, chat, cookie banner, pixels, heatmaps, A/B tests.
• [ ] List embeds: videos, maps, calendars, payment buttons.
• [ ] List anything server-side the platform did for you: form storage, spam protection, password-protected pages, search, localization.
• [ ] For each, write the replacement on the new site.

Framer: native forms post to Framer's form service; after a move they need a new destination. Custom code from the site and page settings holds most scripts. Code components and overrides may load third-party packages. See forms after leaving Framer and code components and overrides in Next.js.

Step 7: measure a performance baseline

Record Core Web Vitals before the move so you can show the new site is at least as fast. Google's Core Web Vitals page gives the "good" thresholds: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift below 0.1.

• [ ] Save the Core Web Vitals report from Search Console (mobile and desktop), which uses field data.
• [ ] Run PageSpeed Insights on the home page and each main template, mobile and desktop, and save the reports.
• [ ] Note field data (from real users) separately from lab data (one simulated run); they often differ.
• [ ] Record Time to First Byte for a few pages: curl -s -o /dev/null -w "%{time_starttransfer}\n" https://www.example.com/.
• [ ] Repeat lab runs three times and keep the median; a single run is noisy.

For what typically changes on Framer sites, see Framer PageSpeed before and after conversion.

Step 8: plan the redirect map

The redirect map turns the inventory's new URL and action columns into rules. If no URL changes, it only contains the redirects you already had.

• [ ] For every URL whose path changes, add a row: old path, new path, status.
• [ ] Use permanent redirects. Google recommends server-side permanent redirects such as 301 or 308 (see its redirects guide).
• [ ] Point each redirect at the final URL, with no chains.
• [ ] Don't send many old URLs to one unrelated page such as the home page; Google advises against it. Removed content should return 404 or 410.
• [ ] Carry over existing redirects from the old platform, and update their targets if those moved too.
• [ ] Plan to keep the redirects for at least a year; Google suggests keeping them as long as possible.
• [ ] Decide where the rules live. In Next.js that's usually redirects() in next.config.ts (docs), or your host's redirect rules.

A redirect entry in next.config.ts looks like this:

async redirects() {
  return [{ source: "/old-services", destination: "/services", permanent: true }];
},

Framer: a project converted by Deframer already lists the redirects the published site answers with in next.config.ts, and src/proxy.ts keeps each page's trailing-slash form. Compare both with your sheet. See SEO when moving off Framer.

Step 9: write acceptance tests

Acceptance tests are the audit's output: specific checks that must pass on the new site before DNS changes. Write them as pass or fail.

• [ ] Every URL marked "keep" returns 200 at the same path on the preview deployment.
• [ ] Every URL marked "redirect" returns a 301 or 308 to its new URL in one hop: curl -sI https://preview.example.com/old-path | grep -i "^location".
• [ ] Every URL marked "remove" returns 404 or 410.
• [ ] A made-up URL returns the 404 page with a 404 status.
• [ ] Titles, descriptions and canonicals of the top pages match the sheet.
• [ ] Canonicals and og:url use the production domain.
• [ ] robots.txt and the sitemap reference the production domain, and the sitemap lists only 200 URLs.
• [ ] Each form delivers a test submission to its destination.
• [ ] Analytics records a visit; each listed script loads.
• [ ] Lab Core Web Vitals on key templates are no worse than the baseline.
• [ ] Key pages look right at mobile, tablet and desktop widths.

After launch, rerun the same tests against production, then use the launch-day list in the Framer to Next.js migration checklist.

Universal vs. Framer-specific, at a glance

Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer.