Strapi with Next.js and other front ends

Editors need to see unpublished Strapi content rendered in the same Next.js layout the public will see, while anonymous visitors must never receive a draft. The section's point is that preview is a separate access path with its own secret, its own credentials and its own lifetime, and it has to be designed that way from the start. If the preview route, the draft fetch and the public fetch share the same cache key, the same token or the same unguarded route, drafts can reach the public site even when every editor behaves correctly.

The approach that holds up is a preview route in the Next.js front end that first validates a secret supplied by the CMS or the editor's link. Only after that check passes does the route fetch draft content from Strapi, using a read credential that lives on the server and is never placed in client-side code, a query string or a cookie the browser can read. Once the content is confirmed, the route sets Next.js preview mode with a short lifetime, and a separate exit route clears that state. Confirm the exact preview configuration in Strapi and the preview mode API for your pinned Strapi and Next.js versions, because both have changed across releases and the setup differs by version. Check the official documentation for those versions rather than copying older examples.

The failure modes are predictable, so plan checks for each one. The first is draft content cached by a shared CDN: a preview response, or a public page rendered with draft data, can be stored at the edge and served to everyone. Verify that preview responses send no-store style headers, that preview requests bypass the CDN or use a distinct path, and that a request without the preview cookie never returns draft fields. The second is preview links that work indefinitely: a leaked URL should stop working after a bounded period or after the editor exits. Test expiry and exit explicitly. The third is an editor previewing a draft that is then unpublished or rejected, which leaves a stale view in a browser tab or cache. Agree with the editorial team how long previews may be trusted and how unpublishing is communicated.

Before launch, run a short verification set. Request the public site and confirm no draft-only fields appear. Request the preview route without the secret and confirm it is refused. Request it with a valid secret, confirm drafts render, then exit and confirm the cookie is cleared and drafts disappear. Repeat the test after the preview cookie expires, and from a different network path to confirm the CDN is not caching preview output. Record which Strapi roles and API tokens can read drafts, since a token with broader scope than the preview route needs widens the exposure. Ask the implementation partner to document the secret rotation steps and the owner who performs them.

Stale content in a Strapi and Next.js build usually comes from one of three layers, and each needs its own invalidation plan. The first is the framework's data cache, which stores the results of fetch calls to the Strapi REST or GraphQL API. The second is the CDN or edge cache in front of the front end, which may hold rendered pages or API responses for other visitors. The third is the browser cache, which controls how long a visitor's own client keeps a page or asset. A publish that clears only one of these layers will still show old content somewhere. Before building anything, ask the front-end team to list which of the three layers each route passes through, and which headers or settings control each one.

Strapi can send webhooks when entries are published, updated or unpublished. A webhook receiver in the front-end application, or a small service beside it, can use the event payload to revalidate only the affected paths or cache tags, rather than rebuilding the whole site. The mapping between content type and path is a design decision that belongs to the project: for example, a change to a shared navigation entry may affect every page, while a change to one article affects its detail page and a listing. Confirm the event names, the payload fields and how the content type and entry identifiers appear in each Strapi version you run against the Strapi webhook documentation, and do not rely on field names from older examples. The receiver must reject requests that do not carry the shared secret you configured, and it should compare secrets in constant time. It must also be idempotent. Strapi, the network or a retry policy can deliver the same event more than once, and revalidating the same path twice should be harmless. Log the event identifier or a combination of event name, entry identifier and timestamp so that duplicate and out-of-order deliveries can be seen during testing.

Webhooks are not guaranteed to arrive, so plan fallbacks before launch. Common options are periodic revalidation, where the front end refreshes a set of pages on a fixed schedule; a manual rebuild or revalidation control that an editor or operator can run when content looks wrong; and a monitoring check that requests a short list of known pages and compares their content with the expected source. The right mix depends on how quickly editors need changes to appear and how much traffic reaches the site. Each fallback adds cost in build minutes, API requests or monitoring, so ask for those costs to be written into the scope. Cache lifetime should be decided per content type, not set once for the whole site. Pages that change rarely, such as policy text, can carry long lifetimes with explicit invalidation. Content that editors update often, such as news or product availability, may need short lifetimes or no shared caching at all. Record the decision in a table that lists each content type, the paths it appears on, the cache layers involved, the revalidation trigger and the maximum acceptable staleness. Review that table with the business owner, because the acceptable delay is a business decision, not a technical default.

Testing needs real events. Create a staging environment that uses the same front-end caching configuration as production, then publish, update and unpublish sample entries in each content type and confirm that the expected paths refresh in the CDN and in a fresh browser session. Test a delivery with a wrong secret, a repeated delivery and a delivery that arrives after a later update. Then disable the webhook for a short window and confirm that the fallback check or scheduled revalidation catches the change. Record the results, because they become the runbook for operators and the baseline for later upgrades of Strapi or the front-end framework. For the team deciding between building this internally and engaging a partner, the work splits into design (content-to-path mapping, cache table, fallback choices), build (receiver, secret handling, revalidation logic, monitoring) and verification (staging tests and the runbook). Ongoing costs include monitoring, periodic reviews when content types change, and retesting after framework or Strapi upgrades. Ask any partner to state which of these items are in the fixed scope and which are retainer work.

The test plan for a Strapi connection to Next.js, Nuxt, Astro or a mobile app should have four groups, because each answers a different question. Contract tests ask whether the response shape the front end depends on still exists. Publish-to-visible tests ask whether a change made in the admin panel reaches a rendered page within the freshness window your team agreed with the business. Negative tests ask whether anything that should stay hidden stays hidden. Failure tests ask what visitors see when Strapi is unavailable. Write the plan down before the first build, with one named owner per group, so that a failing test arrives with a clear decision attached to it.

Contract tests should request the exact fields each page component reads: content type names, attribute names, relation populates, pagination metadata and media formats. Run them after every Strapi upgrade and every schema change, including the frequent Strapi 5 minor releases, because a renamed attribute or a changed relation shape can break pages silently at build time or at runtime. If you are on Strapi 5, confirm which response format your fetch layer expects. Strapi 5 changed the API response format from v4, and the Strapi-Response-Format: v4 header exists only as a migration aid. A contract test should state which format it asserts and fail when the other one appears. Keep fixtures small and stored in the repository beside the front-end data code, so the person who changes the schema also sees which pages it affects.

Publish-to-visible tests create or edit a test entry in staging, publish it, and then poll the rendered page or the revalidation path until the change appears or the window expires. Measure the result against the window in your requirements document. Confirm that the Strapi webhook reaches the front end, that the revalidation call succeeds and that the page shows the new text. Negative tests run as an anonymous client with no session. Request draft and unpublished content through every route the front end uses, and confirm that those routes return nothing. Search the built JavaScript bundles and HTML for the API token value and any other secret. Send the webhook endpoint a request with no secret, a wrong secret and a secret from before the last rotation, and confirm that each one is rejected without side effects.

Failure tests stop or block the staging Strapi instance and observe the front end. Confirm which pages still serve from cache, how long stale content remains acceptable to the business, and whether uncached pages show a clear error state with a retry path. Check response bodies and server logs for stack traces, database hostnames, file paths and token fragments. The exact behavior depends on the rendering mode and hosting, so confirm with your front-end engineers which pages are static, which use incremental regeneration and which call Strapi on every request. Record the results in a table that product owners can review, so each degraded state is either accepted or fixed before launch.

Run the groups in CI in this order: contract tests on every pull request that touches the schema, the fetch layer or the front-end data code; negative and failure tests on each merge to the main branch; and publish-to-visible tests on a schedule and before each release. All of them should target a staging Strapi instance on the same Strapi version as production, with the same Node.js LTS line, database engine and plugin set. A pass on a different version proves little about production. Seed staging content from a fixture script, keep the API tokens and webhook secret in the CI secret store, and configure the pipeline to fail closed. Before accepting the plan, ask your partner or internal team to show the pipeline run history and the exact version tags in use.