Strapi live preview with Next.js and Nuxt

Live preview works as a chain of four requests, and each link in that chain needs a deliberate setting. An editor opens a document in the Strapi admin panel and selects the preview action, which opens a URL on your front end. That URL carries the document identifier, the content type, and a secret or token that proves the request came from the admin panel. The front end receives the request, validates the secret, and then asks the Strapi API for the draft version of the content instead of the published one. The page renders with that draft data, and the editor sees the unpublished changes. Your team should draw this path on a whiteboard before the build starts, labeling where the secret is created, where it is stored, and which service checks it.

Next.js and Nuxt handle the enabling, disabling and secret checks in different ways, so the design choices differ. In Next.js, draft mode is a framework feature: a preview route validates the secret, turns on draft mode through a cookie, and page code checks that state to decide which content to fetch. Turning draft mode off is handled by a separate exit route that clears the cookie. In Nuxt, the preview experience is typically built as a preview route in your application that reads the query parameters, verifies the secret, and passes a flag into data fetching. Teams should confirm the current draft mode behavior and any preview module they plan to use against the exact framework version in their repository, because the route names, cookie handling and recommended patterns change between releases. The secret should be a long random value stored as an environment variable on both sides, never in client-side code.

The exact steps depend on the front end version and the Strapi version. Strapi 5 replaced the Entity Service API with the Document Service API, and the preview request must read draft and published status from the correct parameters for that version. If the front end still calls v4 style endpoints or relies on a response format that changed, editors may see published content labeled as a draft, or see nothing at all. Before you commit to a design, check the Strapi 5 migration guidance for your version, confirm the response format your queries expect, and test with a document that has a draft and a different published version. The same check matters after any Strapi minor upgrade, since the admin panel preview integration can change alongside the API.

Treat the preview secret and the draft token as access credentials. Anyone who holds a valid preview URL can see unpublished content, so restrict which roles can open the preview action and confirm the front end rejects requests with a missing or expired secret. Plan for the case where a draft contains data that must not appear on a public domain, and decide whether preview runs on a separate host with its own access control. Also decide who owns the secret rotation procedure and how it is changed on both the Strapi and front end environments at once, so preview does not break during a deployment.

Editors get a faster review loop once preview is in place, but the benefit depends on one habit: they must read the preview pane as a view of the draft, and the public site as a separate view of what was last published. Changes saved in the Strapi admin panel appear in the preview once the editor saves or the preview refreshes, and the exact behavior depends on whether the plan provides full-screen preview or side-by-side Live Preview. Publishing is the only step that changes the public site, so editors also need to know that moving an entry through a review stage or adding it to a release does not change what visitors see. Before rollout, write a short guide that walks each editor role through saving, previewing and publishing, using an entry from your own content model.

Developers own the parts that make preview work: the route handler that turns draft mode on and off in Next.js or the equivalent preview endpoint in Nuxt, the secret that protects that route, the data fetches that request draft content, and the rendering components that display it. This code sits outside Strapi, so it needs its own owner and its own upgrade plan. Strapi minor releases ship often, and the Next.js and Nuxt versions change on their own schedules. Pin versions in the front-end project, read the release notes before each upgrade, and rerun preview checks on staging after every change to Strapi, the framework or the rendering code. Confirm in your RACI or on-call plan who answers when preview breaks after an upgrade.

Schema changes affect preview directly because the preview mapping connects each Strapi content type and field to a page or component. Adding a content type without a mapping produces an empty or wrong preview, and renaming a field can break a component silently. Localized fields add a second dimension: preview must request the locale in the preview URL, and each locale needs its own check for missing text, fallback behavior and media. Treat every schema change as a front-end change too. Review the mapping in the same pull request as the schema, and include at least one entry per locale in the preview test list. Multilingual setup details are covered in the internationalization page, so this review should focus on how preview reads the content.

Preview only matches publishing when staging mirrors production closely enough that the two behave the same. That means the same Strapi version, the same schema and plugins, the same front-end build process and comparable environment variables, including the preview secret, the draft endpoint URL, CORS settings and cache configuration. A content copy alone does not guarantee a match, because a difference in caching can make preview look correct while the published page fails, or the reverse. Before each release, publish a test entry on staging and compare the public page with the preview. Ask any partner to state in the quote who maintains the staging environment, how often it is refreshed from production, and who pays for its hosting.