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. Static Porter includes a "Smart Refresh" feature. When you publish or update a post, the plugin automatically regenerates the static version of that specific post and your homepage. It’s a "set-and-forget" solution for active bloggers.

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.

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.