Static Porter

Yes! Traditional WordPress pages require the server to process PHP and query a MySQL database every time a visitor arrives. Static Porter converts these into flat HTML files. Your server can then deliver these files instantly, bypassing the "heavy lifting" entirely. This often results in a nearly instant Time to First Byte (TTFB).

No. This is one of the core strengths of Static Porter. The plugin generates a static mirror of your site that follows your existing WordPress permalink structure perfectly. Your visitors (and search engine bots) will continue to see the same clean URLs they always have, but the pages will simply load much faster.

No. Smart Refresh automatically regenerates the post, your homepage, and its category and tag archives when you publish or update it, and removes the old file if you unpublish, trash, or rename it. A full crawl is only needed after changes it can't see, such as menus, widgets, your theme, or permalinks. The Dashboard shows a banner when that happens.

Absolutely. Static Porter is designed to be resource-efficient and includes a built-in "Peak Memory" monitor in the dashboard so you can track its impact. If the crawl is too heavy for your server, you can use the "Stop Crawl" safety button at any time to immediately halt the process.

Yes. In addition to serving static files (which are inherently more secure than dynamic PHP), Static Porter automatically injects security headers into your .htaccess file. This includes protection against clickjacking (X-Frame-Options) and MIME-type sniffing (X-Content-Type-Options).

Speed is a major ranking factor for Google, especially with Core Web Vitals. By serving ultra-fast static HTML and enabling Gzip compression and browser caching automatically, your site will likely see improved performance scores, which can lead to better visibility in search results.

Unlike simple "purge all" plugins, Static Porter gives you a persistent cache table. You can view a list of every cached URL and use individual "Delete" or "Recrawl" buttons for precise control without affecting the rest of your static site.

Yes. The dashboard allows you to toggle the crawling of Posts, Pages, Categories, and Tags independently. You can also use the "Excluded Paths" box to prevent specific directories from ever being turned into static files.

Enable the "HTML Attribution" setting. View your website's source code, and you will see a comment at the top confirming the page is being served as static HTML.

It is recommended to exclude checkout, cart, and account pages using the "Excluded Paths" setting to ensure dynamic functionality remains intact.

Yes. Both are optional, hidden-by-default features. Cloudflare deployment pushes your static files to a Cloudflare Worker, serving your site from Cloudflare's global edge network. AWS S3 + CloudFront deployment uploads directly to your own S3 bucket, with automatic CloudFront cache invalidation on every deploy. Enable whichever fits your infrastructure from the dashboard settings.

By default, yes — only your HTML is deployed, so CSS, JavaScript, images, and fonts still load from your live WordPress site. Turn on Asset Mirroring if you want a fully standalone deployment that doesn't depend on WordPress staying online.

Yes, with the "Also mirror links to images" option under Asset Mirroring. Page builders such as Divi open the large photo from an ordinary link around the thumbnail, and by default that link keeps its original address. With the option on, those links point at local copies, so the lightbox works in a ZIP export or a Cloudflare or S3 deployment. Your canonical URLs, social sharing images, and structured data keep their absolute addresses, so SEO metadata is unaffected.

An optional setting that copies your CSS, JavaScript, images, and fonts locally alongside your static HTML, instead of leaving them to load from your live WordPress site. It's useful before deploying to Cloudflare, S3, or exporting a ZIP, since it makes the result fully self-contained. It's off by default because it increases crawl time and disk usage. Only images, fonts, stylesheets, and scripts are copied, each one is checked before it is saved, and external files are fetched only from public addresses.

No. Static Porter only crawls your posts, pages, categories, tags, and 404 page — it never generates or touches sitemap.xml itself. Since no static copy of your sitemap exists, the .htaccess rule finds nothing to serve for that path and simply passes the request through to WordPress as normal. Your existing sitemap (from Yoast, RankMath, or whichever SEO plugin you use) keeps generating itself dynamically and staying current, completely independent of Static Porter.

No. Asset Mirroring only rewrites the src/href references inside your crawled static HTML pages, pointing them at locally mirrored copies of your CSS, JS, and images. It does not modify your sitemap file, and the live image URLs your sitemap already lists continue to work exactly as before on your WordPress server, whether or not mirroring is enabled.

Static Porter's main SEO benefit is indirect but real: faster page loads improve your Core Web Vitals, which is a direct Google ranking factor, and you get that automatically just from running a crawl — no extra configuration needed. Your URLs, permalinks, and sitemap are unaffected either way. Two things worth checking after your first crawl:

1. Browse your site logged out (or in an incognito window), since that's exactly what Googlebot sees. Confirm nothing looks broken or missing compared to the logged-in, dynamic version.
2. Make sure anything duplicate, private, or irrelevant (like WooCommerce cart or checkout pages) is listed in "Excluded Paths," so it's never accidentally served as a static page to search engine crawlers.

Yes, with one extra step. NGINX ignores .htaccess, so Static Porter detects it and shows an equivalent server rule on the Dashboard, generated for your site's real paths, with a copy button. Add it to your NGINX configuration (or send it to your host's support on managed hosting) and static files are served exactly as they are on Apache. Until then your files are still generated, and the status badge says "Generated" rather than claiming the site is being served statically.

Nothing is silently lost. The crawl report lists every failed page with the reason (a timeout, HTTP 500, HTTP 403, and so on) and a Retry button for each, plus Retry all failed. A page that returns an error is never saved as a static file, and if a refresh fails, the previous good copy is kept.

Static files that your site wouldn't produce any more: a page you deleted, unpublished, or renamed, or a path you excluded after it was cached. Static files are served before WordPress runs, so an orphan keeps showing visitors stale content. The Orphan File Cleanup card lists them with the reason, and can remove them automatically after each crawl. Pages that still exist are never deleted this way.

Open the Compatibility check tab. It tests that your site can crawl itself, checks your permalinks and server type, detects form, shop, and membership plugins, and scans your actual pages for forms and checkout content (including Divi and Elementor forms). It changes nothing unless you click the button to add its suggested exclusions.