About this checklist

Use this before launch, and again before major releases. It covers platform setup, routing, frontend implementation, authoring model, performance, accessibility, localization, personalization, analytics, security, observability, and operational readiness for a site built on Uniform.

Stack assumptions

This checklist applies to any frontend connected to Uniform. Next.js is the most common frontend choice, and Vercel is a common CDN and hosting provider, but neither is required. Items that are framework or host specific are marked. If your stack is different, adapt those items to your equivalent (middleware, edge functions, revalidation, and so on).

1. Platform and environment

Uniform SDK version

• Confirm the project uses a supported and current Uniform SDK version.

• Look for deprecated APIs or patterns copied from older implementations.

• Check that preview, routing, personalization, and revalidation logic match the current SDK approach.

Why it matters: older SDK usage often still works, but tends to break first around preview, routing, middleware, or personalization.

How to check: review package.json, compare implementation patterns against current SDK docs, and check npmjs.com for the latest published version. You can also run npm outdated from the command line to see which Uniform packages are behind.

Preview secret

• Verify UNIFORM_PREVIEW_SECRET (or equivalent) is a secure, non-obvious value.

• Confirm preview endpoints don't rely on guessable strings.

• Confirm secrets differ per environment where appropriate.

Why it matters: a weak preview secret is a quiet security gap.

API keys

• Use the Viewer role, or custom permissions limited to read-only access, for any API key used in production.

• Store API keys as encrypted or sensitive values in your hosting environment, not in plain text config or source control.

Why it matters: a production API key only needs to read content. Broader permissions increase the damage if the key leaks.

Environment parity

• Check staging and production environment variables match expectations.

• Confirm API keys, preview secrets, webhook secrets, and base URLs are correct.

• Verify the site resolves content from the intended Uniform project and environment, not a stale or test one.

2. Routing and project map

Project map structure

• Review the site structure in the project map.

• Confirm parent/child hierarchy reflects the real URL strategy.

• Check naming and path segments for clarity and consistency.

• Verify authors aren't relying on orphan compositions unless that's intentional.

Why it matters: the project map is the routing backbone in Uniform. A messy structure means messy troubleshooting later.

Compositions not attached to a project map node

• Check for compositions that exist but aren't attached to a node.

• Confirm whether that's intentional (shared templates, test pages, preview-only content) or a mistake.

• If a page should be reachable on the live site, attach it to a project map node.

Why it matters: a composition can exist fine in Uniform and still never be reachable on the actual site.

Slugs and layout review

• Confirm frontend route resolution matches project map expectations.

• Check that layout selection is driven consistently, not by scattered hardcoded exceptions.

• Watch for route logic split across multiple places, or route params transformed inconsistently.

Dynamic pages

• Check whether dynamic pages are used, and confirm dynamic project map nodes are implemented correctly.

• Verify resolvers or build logic cover all expected paths.

• Test valid and invalid dynamic URLs.

• Confirm a failed data lookup produces a proper error state, not a broken page.

Why it matters: dynamic routing is where launch bugs like to hide.

404 handling

• Confirm 404 handling exists for both static and dynamic pages.

• Test invalid dynamic routes specifically.

• Verify missing content doesn't render a partially broken page with a 200 status.

• If localization is used, confirm localized routes produce a localized 404.

• Check that the 404 page itself is styled and has real content, not a placeholder.

Good test cases:

• non-existent static path

• non-existent localized path

• valid dynamic route pattern with an invalid entity slug

• missing referenced content on a detail page

Redirects and legacy URL migration

• Confirm 301 redirects exist for every legacy URL that still gets meaningful traffic, not only the obvious top pages.

• Check for redirect chains (a redirects to b redirects to c) and redirect loops.

• Test redirects through the actual CDN and custom domain setup, not only locally. This is a common miss on CMS migrations specifically.

Why it matters: a missed redirect on a migrated site quietly costs SEO rankings and breaks bookmarked or linked URLs.

Single root slug strategy

• Check whether the app uses one root route handler for all incoming requests, or several parallel handlers.

• Prefer a single request path where possible. It's simpler to debug and maintain.

• If multiple route handlers exist, document why.

3. Frontend rendering and implementation

Middleware scope (frameworks with middleware, e.g. Next.js)

• Confirm middleware only runs on HTML/document requests.

• Exclude static assets, image optimization routes, and API routes unless there's a specific reason to include them.

• Review matcher rules for overreach.

Why it matters: over-broad middleware is a common cause of performance drag and unexpected side effects.

Component implementation coverage

• Check that every Uniform component available to authors is actually implemented in the frontend.

• Verify no key component falls back to a "not implemented yet" message.

• Compare what's usable in Uniform against the component registry in code.

Watch for:

• components present in Uniform but not registered in code

• empty placeholder patterns masking a missing implementation

• slots defined in Uniform but ignored by the frontend

Navigation and header rendering

• Confirm header and navigation slots defined in Uniform are actually rendered by the frontend.

• Check that page templates don't bypass Uniform with hardcoded components unless that's intentional.

• Verify mobile and desktop navigation both reflect the current route and locale.

Breadcrumbs

• Confirm breadcrumb content comes from the intended source (project map, page content, or derived route labels).

• Check localized breadcrumb behavior.

• Confirm breadcrumbs work correctly on dynamic detail pages.

Footer links

• Review footer links for accuracy and completeness.

• Confirm links are author-controlled where content editors are expected to maintain them.

• Test external links, legal links, and locale-specific links.

Locale-aware UI behavior

• If locale is part of the URL, confirm frontend components respect it.

• Check language switcher behavior, including whether it preserves the current page.

• Verify RTL/LTR behavior where relevant.

• Confirm menus, nav alignment, and route generation all use the active locale, not a default.

Third-party scripts

• Load third-party scripts, such as analytics, tag managers, and chat widgets, async or deferred where possible.

• Set a performance budget so one added tag doesn't quietly tank Core Web Vitals after launch.

• Review what's actually loaded through a tag manager specifically. It's easy to lose track of what's running.

4. Authoring model and content architecture

Component patterns for shared content

• Review whether component patterns are used for repeated shared content.

• Use plain components when reuse of structure is needed but not shared values.

• Watch for authors repeatedly rebuilding the same content instead of using a pattern.

• Use component patterns for global components like header and footer, so there's one source of truth for their content.

• Use pattern overrides to lock down parameters authors aren't expected to edit.

Rule of thumb: a component is reusable schema, a component pattern is reusable content and configuration.

Composition patterns

• Use composition patterns to give authors page templates to start from, so building a new page is more "on rails" than starting from a blank composition.

• Review whether high-traffic or repeated page types, like landing pages or detail pages, have a composition pattern available.

Slot restrictions

• Review slot component restrictions.

• Confirm each slot allows the components authors actually need, and nothing riskier.

• Use allowed-components restrictions on every slot. Without them, authors see every component in the project, including ones that don't belong there.

• Check min/max slot constraints where useful.

Why it matters: slots that are too open create author chaos. Slots that are too closed create tickets.

Component discoverability

• Add categories to component definitions so authors can find them quickly in a growing list.

• Add screenshots to components and component patterns so authors can recognize them visually instead of guessing from a name.

Preview

• Confirm preview works on compositions.

• Confirm preview also works on component patterns and composition patterns, not just compositions.

Why it matters: authors need to see what they're building before they publish, at every level they can edit.

Layout governance

• Confirm page-building flexibility is intentional, not accidental.

• Confirm authors can't easily create invalid layouts.

• Use slot restrictions and patterns to guide good outcomes.

Unused data resources

• Check compositions and patterns for data resources that aren't used anywhere.

• Remove resources no longer referenced by components or tokens.

• Pay attention to pages with many external fetches.

Why it matters: Uniform loads configured resources on a cache miss even if nothing renders them, so unused resources still cost performance.

5. Content quality and SEO

SEO metadata

• Check for pages with empty or missing SEO metadata.

• Confirm sensible defaults exist where appropriate.

• Verify title, description, canonical logic, and social metadata are wired correctly.

• Manually review the highest-value landing and detail pages.

Watch for: empty metadata fields, duplicate titles, wrong canonical URLs, fallback metadata that doesn't match the locale.

Sitemap and robots.txt

• Confirm an XML sitemap is generated and stays up to date as content changes.

• Submit the sitemap in Google Search Console, and Bing Webmaster Tools if relevant.

• Confirm robots.txt blocks staging and any non-production environment, but doesn't accidentally block production.

Structured data

• Add structured data (schema.org / JSON-LD) for page types where it helps, like articles, products, events, or FAQs.

• Validate the markup with a structured data testing tool before launch.

Open Graph and social sharing

• Confirm OG title, description, and image are populated for key pages.

• Verify social preview images are sized correctly and not stretched or cropped badly.

Content completeness

• Check critical pages for placeholder content, lorem ipsum, broken references, or empty sections.

• Review reusable patterns for a mistake that would repeat across every page that uses them.

6. Images and performance

Asset delivery

• Don't focus on source asset file size as the main lever. Uniform resizes and optimizes images on delivery, so upload size isn't the performance concern it would be on a traditional CMS.

• Focus on framework-sanctioned image primitives instead, like next/image in Next.js. Rendering a plain <img> tag bypasses the resizing, format negotiation, and lazy loading the framework already provides.

• Confirm rendered image dimensions match how the image actually displays, so the layout isn't requesting a much larger image than it needs.

Lazy loading and priority

• Confirm below-the-fold images use lazy loading by default.

• Identify each page's LCP (largest contentful paint) image, usually a hero or above-the-fold image, and confirm it loads with high priority instead of being lazy loaded. Lazy loading the LCP image is a common and costly mistake.

• Check that priority loading isn't applied everywhere. If every image is "high priority," none of them are.

Why it matters: on a site backed by Uniform, image performance is mostly a frontend rendering decision, not an authoring or asset-size problem.

Public-folder media vs. managed assets

• Review any media stored directly in the frontend's public/static folder instead of Uniform or another managed system.

• Decide whether those files should move to a managed system so editors can update them without a deploy.

• Keep public-folder assets only when that tradeoff is intentional.

Asset labels

• Set up asset labels so authors can filter and find the right image or file quickly, instead of scrolling a flat, unsorted asset library.

• Reference: Asset labels

7. Accessibility

Manual accessibility pass

• Do a real manual pass, not only an automated Lighthouse score: keyboard navigation, a screen reader pass, color contrast, and visible focus states.

• Confirm a target WCAG conformance level with the client up front if there's a compliance requirement. Many enterprise contracts require this.

Why it matters: automated tools catch a fraction of real accessibility issues.

8. Localization

Default locale

• Confirm at least one default locale is configured in the project, even on a single-locale site.

• A single-locale site doesn't need that locale added to the project map, but the locale still needs to exist in the project itself.

• Skipping this can leave content in a "locale-less" state, which causes problems later.

Localized project map paths

• If localization is used, verify the expected project map nodes are localized in all required languages.

• Check path segment translations and locale-specific route behavior.

• Confirm fallback behavior is intentional, not accidental.

Localized 404 and routing behavior

• Verify the 404 page works correctly in every supported locale.

• Confirm dynamic pages resolve correctly under localized paths.

• Check that language switcher links preserve page context where possible.

hreflang for localized pages

• Confirm hreflang tags are present and correct on localized pages, pointing to the equivalent page in each language or region.

• Verify the default/x-default variant is set correctly.

Localized content completeness

• Confirm important compositions, entries, and patterns have the expected locales enabled.

• Check for mixed-language experiences caused by missing localized values.

9. Personalization

Configuration is published

• Review personalization setup if Uniform Context is used.

• Confirm the intended signals, audiences, or intents are configured and available.

• Check that personalization used on the live site isn't left in a draft state.

• Verify frontend tracking and integration are actually active.

Why it matters: personalization can look fully configured in Uniform while not actually running on the site.

Control and fallback behavior

• Confirm default variations exist for every personalized experience.

• Check what anonymous or unmatched visitors see.

• Verify personalization never produces blank output when criteria fail to match.

10. Analytics, tagging, and consent

Analytics and tag manager

• Confirm analytics and tag manager scripts actually fire on live, published pages, not only in Uniform preview.

• Spot-check key events, like page views, form submits, and key CTAs, actually land in the analytics tool.

Consent

• Confirm a cookie consent banner and consent handling are in place if the audience requires GDPR, CCPA, or similar.

• Confirm personalization tracking respects consent state where required, instead of firing regardless.

11. Revalidation and publishing operations

Publish webhook and revalidation (if using ISR, on-demand revalidation, or a CDN cache such as Vercel)

• Verify publish webhooks trigger revalidation correctly.

• Confirm the right environment endpoint is called.

• Test with a real content update before launch, not just in theory.

• Make sure failed webhook calls are visible somewhere, not silent.

Cache clearing scope

• Set up cache clearing for composition publish and delete events, entry publish and delete events, and manifest publish events.

• Include redirects and project map events too. Both can change what a page resolves to or renders.

• For Next.js, this means the cache clearer needs to instruct Next.js to clear its cache, for example through on-demand revalidation, whenever any of these entities change in Uniform, not only on composition publish.

Why it matters: if only composition publish triggers a cache clear, changes to entries, redirects, the project map, or the manifest can go live in Uniform but stay stale on the site.

Content and code promotion

• Set up a DEV -> Stage -> Prod process that automates content and code promotion, using the Uniform Sync CLI or an equivalent tool, rather than recreating changes by hand in each environment.

• Confirm the promotion path is repeatable and doesn't depend on one person's local setup.

Cache invalidation expectations

• Confirm the team understands what updates immediately, what revalidates on a delay, and what needs a rebuild or redeploy.

• Document the expected propagation time after publish, so no one is surprised on launch day.

12. Security and roles

Author roles

• Confirm authors are added as Editor, or a custom role with minimum permissions, not Developer or Team Admin.

• Review the full list of users and roles periodically, not only at launch.

SSO

• Work with Uniform Support to configure SSO for the project.

Why it matters: over-privileged author accounts are a common source of accidental production changes.

Security headers and hardening

• Set security headers such as CSP, HSTS, and X-Frame-Options, and confirm they aren't just framework defaults left unreviewed.

• Run a general header audit against current best practice.

Rate limiting and bot protection

• Add rate limiting or bot protection on public API routes and forms.

• Confirm this doesn't accidentally block legitimate traffic, like Uniform preview requests or webhook calls.

13. Observability and monitoring

Error monitoring

• Wire up frontend error monitoring, for example Sentry, so production errors are visible instead of silent.

Uptime and alerting

• Set up uptime monitoring and alerting for the live site.

Degraded mode

• Document a fallback behavior for when the Uniform API is slow or unavailable, so the site degrades gracefully instead of breaking entirely.

14. Forms and lead capture

Spam protection and validation

• Add spam protection, such as a captcha, and server-side validation on public forms.

End-to-end delivery

• Confirm form submissions actually land in the CRM or inbox end to end. A form that submits successfully in the UI isn't the same as a lead that actually arrives.

15. Backup, rollback, and content governance

Backup

• Confirm there's a way to export or back up Uniform content.

Rollback

• Confirm a rollback plan exists for a bad deploy or a bad content publish.

Approval workflow

• If Uniform's approval workflow is meant to be used, confirm it's actually configured and enforced, not just available and ignored.

16. Developer tooling

TypeScript

• Use TypeScript across the project.

• Confirm the site compiles with no TypeScript errors, not just no build failures.

Linting

• Run the linting tool as part of the dev process.

• Confirm code is formatted consistently before merging.

Dependency and supply chain security

• Enable a vulnerability and supply chain scanning tool such as Snyk or Socket, and review findings before launch.

• Confirm Next.js and other open source packages are on their latest stable versions, not just free of known vulnerabilities.

• Run the scanning tool continuously, for example on every pull request or on a schedule, not only once before launch.

Why it matters: type errors, formatting drift, and outdated or vulnerable dependencies are all cheap to catch early and expensive to untangle after launch.

17. Testing and QA automation

Lighthouse

• Run Lighthouse early, and add it to your dev process rather than running it once before launch.

• Confirm scores are strong across Core Web Vitals, accessibility, SEO, and best practices.

End-to-end tests

• Add end-to-end tests with a tool like Playwright, especially for business-critical flows.

• Run them continuously with a service like Checkly.

• Consider snapshot testing with a tool like Chromatic for UI regressions.

18. Practical final review

Core page QA

• Homepage

• Top-level landing pages

• Key detail pages

• Search or listing pages

• 404 page

• Legal and footer-linked pages

Device and browser sanity check

• Mobile navigation

• Tablet layout

• Desktop layout

• Key browsers used by the audience

Authoring sanity check

• Authors can create a new page using the expected composition and slot model.

• Authors can update nav, footer, hero, and SEO content without developer help.

• Reusable patterns behave as expected and don't cause a surprise global change.

Launch basics

• Favicon, apple-touch-icon, and web manifest are in place.

• SSL certificate renewal is automated, not something someone has to remember to do manually.

• The domain is verified in Google Search Console, and Bing Webmaster Tools if relevant, before launch.

Red flags 🚩

Stop and dig deeper if any of these show up during a launch review:

• middleware runs on every request, not just page requests

• dynamic routes return a broken page instead of a proper 404

• important compositions aren't attached to project map nodes

• redirects are missing, chained, or untested through the actual CDN and domain

• localized routes don't respect locale in navigation or the language switcher

• components used in Uniform are missing a frontend implementation

• slots exist in Uniform but the code ignores them

• SEO metadata is empty on important pages

• the LCP image is lazy loaded, or every image is marked high priority

• authors are rebuilding the same sections instead of using a pattern

• publishing doesn't reliably trigger revalidation

• cache clearing only fires on composition publish, not on entry, manifest, redirect, or project map events

• API keys use write or admin permissions in production instead of read-only

• Next.js or other open source packages are outdated, or vulnerability scanning isn't in place

• authors have Developer or Team Admin access instead of Editor or a minimal custom role

• no manual accessibility pass has been done, only an automated score

• analytics or the tag manager fires in preview but not on live pages

• there's no error monitoring or uptime alerting in place

• there's no rollback plan for a bad deploy or a bad publish

• security headers are left at framework defaults, unreviewed.