Review a POM Theme site before launch

This is the final production-readiness review for a complete POM Theme site. It is not a build tutorial: every enabled feature should already have an owner, configured content, and a successful staging test.

Run the review on the release candidate that will become production. Record failures by URL, role, device, and exact action so they can be reproduced without guesswork.

Freeze the intended scope

• List the page types, post types, taxonomies, languages, forms, integrations, and WooCommerce journeys included in the launch.
• Identify features deliberately left disabled.
• Confirm who approves content, design, privacy, accessibility, commerce, and technical deployment.
• Stop unrelated configuration changes while final verification is in progress.

A checklist cannot approve an undefined site. If a feature is not in scope, remove its public links and do not leave a half-configured workflow discoverable.

WordPress and theme state

• POM is active on the intended site.
• The production URL, HTTPS configuration, site language, timezone, permalink structure, and search-engine visibility are correct for launch.
• WordPress, POM Theme, required plugins, PHP, and the database environment meet the supported versions for the release.
• Settings → POM Theme → License shows the expected product, domain, plan, expiry, and valid status.
• Dashboard → Updates completes a licensed theme update check without an unresolved warning.
• A current database-and-files backup has been created and its restoration owner is known.

On multisite, confirm the network license on the main site and run the update check from Network Admin → Dashboard → Updates. If the local POM updater is required, POM must be active on the main site; network-enabling it alone does not load the theme there.

Content and information architecture

• Every main navigation, mobile navigation, footer, account, and conditional menu points to the correct destination.
• Draft, private, test, duplicate, and placeholder records are not linked publicly.
• Titles, excerpts, featured media, taxonomy assignments, authors, publication dates, and translated variants are complete where used.
• Search, archives, pagination, empty results, 404, password-protected content, and author pages show intentional output.
• Content-model slugs and relationships are final enough for public URLs and template assignments.
• Long text, missing optional fields, no-results states, and unusually large media do not break the layout.

Design system and layout

• Logos and icons remain legible on every header and background variant.
• Palette, fonts, buttons, links, notices, forms, and focus indicators are consistent.
• Header, mobile navigation, subheader, breadcrumbs, footer, contact dock, and sidebars match the intended configuration.
• Page-level overrides are intentional and documented for the content owner.
• No essential styling depends on an editor's browser cache or a temporary local override.

Review at narrow mobile, large mobile, tablet, laptop, and wide desktop widths. Rotate at least one touch device and test zoom rather than relying only on a desktop responsive preview.

Page Builder and dynamic templates

• Representative Page Builder pages contain valid rows, columns, and components with no empty structural containers affecting spacing.
• Responsive visibility does not hide the only copy of essential content or an action.
• Reusable blocks render in every context where they are selected.
• Archive, feed, single, search, blog, author, and WooCommerce templates use the intended assignments.
• Merge tags produce correct values for normal, empty, and unusual records.
• A missing optional value does not leave raw markup, an unexplained gap, or a misleading label.

Forms and integrations

For every public form:

1. Submit valid data.
2. Trigger each important validation error.
3. Confirm success and error messages.
4. Confirm notifications reach the intended recipients.
5. Confirm stored submissions, uploads, retention, and deletion behavior match the site's policy.
6. Test spam protection and consent controls where configured.
7. Confirm no credential or private field value appears in the public page source or URL.

Also verify each enabled Maps, Analytics, reCAPTCHA, Ads, Drive, social-pixel, Instagram, cookie, or header-meta integration with production-approved credentials and consent behavior. Leave unused integrations disabled.

WooCommerce journeys

When WooCommerce is in scope, test as a customer:

• Shop and product-taxonomy archives
• Simple and variable products
• Stock and out-of-stock states
• Cart and any dropdown or side-cart behavior
• Coupons and shipping choices used by the store
• Checkout success and validation failure
• Payment success, failure, and cancellation paths supported by the gateway
• My Account, addresses, orders, downloads, and password reset
• Enabled POM features such as waitlists, request-information actions, wishlists, vouchers, pre-orders, or delivery tools

Confirm transactional emails and administrative order handling as well as frontend presentation. POM Theme controls supported presentation enhancements; WooCommerce remains the authority for prices, stock, tax, shipping, payments, and orders.

Accessibility and privacy

• The whole primary journey works with a keyboard and has a visible focus indicator.
• Headings form an understandable hierarchy.
• Form controls, icon-only actions, menus, dialogs, carousels, and media have usable accessible names and states.
• Informative images have meaningful alternative text; decorative images do not add noise.
• Text and controls have sufficient contrast in normal, hover, focus, active, error, and disabled states.
• Motion, autoplay, sticky elements, and overlays do not block navigation or obscure content.
• Consent, privacy notices, data collection, third-party requests, and retention match the site's approved policy.

Performance and cache boundary

• Optimized production media is in use.
• Required theme assets load without missing-file or mixed-content errors.
• Generated theme styles and scripts reflect the final saved settings.
• Page, object, progressive-data, server, and CDN caches are refreshed in the correct order after the underlying configuration is final.
• Signed-out and signed-in visitors receive the correct version of personalized or public pages.
• A cold request and a warm request are both acceptable for representative routes.

Do not use a broad cache purge as evidence that the source configuration is correct. Verify the uncached origin first, then each delivery layer.

Browser and role matrix

Test the supported browsers and devices for:

• a signed-out visitor;
• an editor with normal content responsibilities;
• each customer or member state used by the site;
• a shop manager when WooCommerce administration is in scope;
• a network administrator on multisite.

An administrator-only success does not prove that the intended editor or customer can complete the task.

Launch approval

The site is ready when every blocking item has:

• an owner;
• a reproducible verification;
• an accepted result;
• a rollback or containment path;
• no unresolved dependency on placeholder data, temporary credentials, or an undocumented manual fix.

After launch, repeat the primary journeys against the public domain, verify monitoring and email delivery, and record any production-only difference without sharing credentials or customer data.