Platform status · September 2026

Static-first SSG, compatibility and delivery status

This page records the storefront hardening and performance phase completed across the React/TypeScript storefront and the WordPress/PHP control plane. It also identifies the work that remains before every managed site should enable static-first delivery.

Architecture delivered

• Portable two-layer architecture: the frontend builds complete static route documents and registers a signed shell; WordPress generates artifacts, tracks revisions and dependencies, and provides a safe React-shell fallback.
• Static-first SSG mode serves generated HTML directly from the static host. Products, posts, pages, authors, post taxonomies and WooCommerce taxonomies receive route-specific hydration data.
• WooCommerce Action Scheduler is the preferred zero-configuration artifact runner, with native WP-Cron fallback. Obsolete-shell jobs are discarded when a new shell activates.
• Valid public artifact misses return HTML instead of JSON. Private, password-protected and invalid requests remain fail-closed and non-cacheable.
• Static CMS markup, CSS, scripts and shortcodes are preserved through hydration. Encoded JavaScript entities are decoded only by the trusted client executor.
• Internal CMS links use the storefront router after hydration and target data is warmed before route replacement, avoiding browser-level document loading and incomplete route states.

Routing and WordPress integration delivered

• Configured special pages are authoritative: WooCommerce shop, privacy policy and terms pages are resolved from WordPress, including translated/custom paths such as /produkty/.
• Login, registration and password recovery preserve safe same-site return references. Public aliases do not fall through to protected-page probes.
• Private admin-only pages and password-protected pages are capability-gated and excluded from public caches, feeds, search, sitemaps and prerendering.
• Opaque storefront media aliases are available while legacy upload URLs remain compatible. SVG product media renders correctly in galleries and lightboxes.
• Headless backend origins can emit noindex directives without changing storefront SEO. Static SEO, feeds, robots, sitemap and AI discovery files remain build controlled.

Presentation and compatibility delivered

• Active hash navigation highlights only the section currently in view.
• The AI Assistant icon and CMS hydration handoff no longer flicker between incompatible server/client states.
• Trusted CMS scripts are contained so one failing script does not stop the page; scripts containing HTML responses are rejected.
• Localized author archives, search, inquiry and interface strings were completed for the supported storefront catalogs.
• Layout Studio includes overlay-search, mobile-menu sizing and global code-control visibility options.

Publishing and freshness

WordPress invalidation and artifact regeneration happen automatically, but static-first public HTML changes only when a storefront build is published. This is intentional: editors can prepare several changes without consuming a deployment. Use Rebuild storefront in the WordPress top admin bar when the changes are ready. The previous known-good deployment remains public until the new build succeeds.

For Netlify, Build status badge ID shows deployment state below the rebuild action. Other static hosts can use the same build webhook without the Netlify badge.

Required static-first settings

STOREFRONT_ARTIFACT_MODE=artifact
STOREFRONT_ARTIFACT_DELIVERY=static-first
STOREFRONT_ARTIFACT_ORIGIN=https://wordpress.example.com
STOREFRONT_ARTIFACT_SITE_KEY=unique-site-key
STOREFRONT_ARTIFACT_SIGNING_SECRET=same-secret-as-wordpress
VITE_ARTIFACT_ROUTE_HYDRATION=true

Use a different site key for every public site. The signing secret must be identical in WordPress and the frontend environment and contain at least 32 characters. Validate shadow mode before switching the site to artifact mode.

What remains

• Enable static-first mode site by site. Validate each site language, configured shop/legal/auth paths, representative products, posts, authors and taxonomies before promotion.
• Confirm each host build hook, signing secret and site key. Cloudflare Pages and Vercel need equivalent static build triggers; the runtime does not require provider-specific functions.
• Monitor build duration as route counts grow. Current builds intentionally generate detailed route hydration; future work may add incremental build partitioning without weakening static correctness.
• Continue reducing the large application chunk and run mobile field monitoring after fleet rollout. The static-first path removes initial content gating, but interactive application code can still be split further.
• Add provider-neutral deploy-status adapters if non-Netlify sites need a toolbar badge.
• Periodically clean historical artifact records. Aggregate stale counts include old shells; current-shell failed/exhausted jobs are the operational signal.
• Complete fleet-specific acceptance testing and rollback drills before making static-first the default for new installations.

Frontend setup · WordPress setup · Security · Free and Pro settings