Static Compatibility Guide

Stelae exports your WordPress site as static HTML, CSS, and JavaScript. Everything that renders on the page at build time is preserved. Anything that requires a server at visit time won’t work — but there are good alternatives for most features.

The rule of thumb

If the feature works by generating HTML when you save or publish, it will survive the export. If it works by running PHP when a visitor loads the page, it won’t.

Quick test: right-click a page in WordPress, choose “View Page Source”. If the content is in the HTML, it will export. If the content only appears after JavaScript runs, it depends on AJAX and won’t export.

Content & Layout

FeatureStatusNotes
Pages and postsWorksAll published content is exported as static HTML.
Custom post typesWorksExported if they have public URLs (archives + singles).
ThemesWorksAll visual output is preserved. Theme PHP logic runs only during export.
Page buildersWorksElementor, Beaver Builder, Bricks, GenerateBlocks, Divi, Gutenberg blocks — all produce HTML/CSS that exports cleanly.
Navigation menusWorksAll internal and external links work.
Images and mediaWorksAll uploaded media is included in the export archive.
Custom CSS / JSWorksEnqueued stylesheets and scripts are captured.
SEO plugins (Yoast, Rank Math)WorksMeta tags, Open Graph, sitemaps, structured data — all generated at build time.
RSS feedsWorksExported as static XML files.
PermalinksWorksPretty permalinks (/%postname%/) set automatically. Query-string URLs (?page_id=2) won’t work on most static hosts.
Responsive layoutsWorksCSS media queries work normally in static HTML.
Google Fonts / custom fontsWorksFont files and CSS @font-face rules are captured in the export.

Interactive & Dynamic Features

FeatureStatusWorkaround
Contact formsWon’t workWordPress form plugins (CF7, WPForms, Gravity Forms) submit to PHP. Replace with Formspree, Basin, or Netlify Forms. These embed via HTML attributes or JavaScript — no server needed.
Site searchWon’t workWordPress search queries the database. Replace with Pagefind (fully static, runs in the browser, indexes your HTML after export) or Lunr.js. Pagefind is the best option for most sites — it’s free, fast, and requires no infrastructure.
CommentsWon’t workWordPress comments require the database. Replace with Giscus (GitHub Discussions-based, free), Cactus Comments (Matrix-based), or Disqus. All embed via JavaScript.
WooCommerce / e-commerceWon’t workCarts, checkout, and payment processing require server-side logic. You can use WooCommerce to build product catalog pages (they export fine as HTML), but the cart and checkout won’t function. For simple buy buttons on static pages, consider Snipcart or Ecwid.
User login / registrationWon’t workRequires server-side sessions. No practical workaround for static hosting.
Membership / paywallWon’t workServer-side access control can’t be replicated in static HTML. All exported content is publicly accessible.
AJAX / REST API callsWon’t workNo WordPress backend on the live site. Any admin-ajax.php or /wp-json/ calls will fail. Themes and plugins that use AJAX to load content will show empty sections.
Dynamic widgets (recent/related posts)PartialIf the widget renders HTML at page-build time (most do), the content is captured. It will show whatever was current at export time — it won’t update dynamically.
Scheduled postsPartialA scheduled post goes live in WordPress at the scheduled time, but won’t appear on your static site until you re-export. Re-export after the scheduled time to include it.
PaginationWorksStandard WordPress pagination (/page/2/, /page/3/) is exported as separate HTML pages. Infinite scroll that loads via AJAX will not work.

Plugins

Plugin typeStatusNotes
Visual / layout (Elementor, Beaver Builder, Bricks, Divi, GenerateBlocks)WorksOutput is HTML/CSS, fully captured.
SEO (Yoast, Rank Math, AIOSEO, SEOPress)WorksMeta tags, sitemaps, structured data are all build-time output.
Image optimization (Smush, ShortPixel, Imagify)WorksOptimized images are what gets exported. The optimization happens during editing.
Custom CSS/JS (Simple Custom CSS, WPCodeBox)WorksCustom code is injected into the HTML at build time.
Analytics (Google Analytics via header script)WorksIf the plugin injects a JS tracking snippet into the HTML, it survives the export. Server-side analytics (e.g. Matomo server mode) won’t work.
Form plugins (CF7, WPForms, Gravity Forms)Won’t workForms render visually but can’t submit. Replace with a third-party form service.
Caching (WP Super Cache, W3 Total Cache)UnnecessaryYour live site is already static. No caching layer needed.
Security (Wordfence, Sucuri)UnnecessaryNo PHP, no database, no wp-admin on the live site. Nothing to attack. Useful inside the editor to limit login attempts.
Multilingual (WPML, Polylang)WorksIf configured to produce separate URLs per language (e.g. /en/, /de/), all language versions are exported as separate pages.
E-commerce (WooCommerce, EDD)Won’t workProduct catalog pages export fine as static HTML. Cart, checkout, payment, and account features require a server.

Hosting & Infrastructure

FeatureStatusNotes
Custom domainsWorksConfigured at your hosting target (Cloudflare, Netlify, etc.), not in Stelae.
HTTPS / SSLWorksProvided free by all major static hosts (Cloudflare, Netlify, Vercel, GitHub Pages).
301/302 redirectsPartialWordPress redirect plugins generate PHP redirects that won’t survive export. Most static hosts support redirect rules via config files (_redirects on Netlify, _routes.json on Cloudflare). You’ll need to configure these at your hosting target.
.htaccess rulesWon’t workStatic hosts don’t run Apache. Use your host’s native redirect/header configuration.
Custom HTTP headers (CORS, CSP, etc.)PartialConfigured at your hosting target. Most static hosts support custom headers via config files or dashboard settings.
404 pagesWorksThe WordPress 404 page is exported. Most static hosts let you configure which file to serve for 404 errors.
Platform support

If the export itself fails, your container won’t start, or auto-deploy breaks — that’s a platform issue and we’ll fix it. If you need help choosing plugins or configuring third-party services, that’s WordPress usage and these docs are your best resource.

Tips for Best Results

Before you build

Choose a theme that renders content as HTML at build time (most modern themes do this). Avoid themes that rely heavily on AJAX to load content after page load. When evaluating a theme, view the page source — if the content is in the HTML, it will export cleanly.

Before you export

Preview every page in WordPress and verify the content looks correct. Check that all posts are set to “Published” status. If you’re using any dynamic features (forms, search), make sure you’ve set up third-party alternatives before going live.

After you export

Test your deployed site. Click through pages, test navigation, check that images load. If you’ve replaced forms with a third-party service, submit a test message. The first export is the one most likely to surface issues — subsequent exports of the same site are usually smooth.