| 开发者 | aouwal |
|---|---|
| 更新时间 | 2026年11月7日 16:51 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
url() and @import references.<picture>, <source>, <track>, <template> and custom-element markup intact.404.html page, plus sitemap.xml and robots.txt._redirects and _headers files, both on by default.srcset and <picture> sources.<picture>, <source>, <video>, <track>, <template> and custom elements survive the export.wp aouwal-static-export run._redirects and _headers files Cloudflare Pages expects, and the Deploy tab walks you through creating a GitHub repository and connecting it to Cloudflare Pages. Once the repository is connected, every push redeploys the site automatically.
Export to GitHub Pages
The same export folder works on GitHub Pages. Commit the exported files to a repository, enable Pages for the branch or folder you pushed, and GitHub serves the static HTML. Relative links work as they are, so no extra configuration is needed.
Netlify, Jamstack and any static host
The output is a plain folder of HTML files and assets, which makes it a good fit for any Jamstack workflow. Upload it to Netlify (which also reads _redirects and _headers), Amazon S3, Vercel, a CDN, or any static hosting account. No WordPress, PHP or database is needed to serve it.
Automate exports with WP-CLI and cron
Aouwal Static Site Export writes a ZIP and a local folder. It does not schedule exports, and it does not push to Netlify, Cloudflare Pages, S3 or any other host by itself. For hands-off deployments, run the export from WP-CLI on a schedule and let cron and your Git host do the rest.
Success: Export complete: prefix:path/index.html), so unzip it as a folder, not as a flat file list. Machine-readable output and a custom output path are planned.
Pause, resume or cancel an export
The Export screen has three controls next to the Start button, so a long crawl no longer has to be left running or killed by closing the tab.
status prints the phase, the processed and pending counts and the last URL, which is handy in a cron log. cancel exits with 1 so a script stops before pushing a partial build.
Changed-only export for large sites
By default every export re-crawls every page and re-downloads every asset. Settings > Export mode adds a second mode for sites where that takes too long.
post_modified time changed, plus every taxonomy, author and date archive that contains it, plus the homepage, the posts page and their pagination.ETag or Last-Modified response header no longer matches the stored value. The plugin sends a conditional request (If-None-Match / If-Modified-Since) and keeps the copied file when the server answers 304 Not Modified._redirects, _headers and 404.html are always rebuilt.{prefix}aouwal_export_state) holding the URL hash, fingerprint, ETag, Last-Modified, size and the last export that confirmed it. The table is removed when the plugin is uninstalled.
Crawl through proxies, staging sites and Basic Auth
The Network settings section controls how the export talks to your server. Defaults reproduce the previous behavior exactly, so nothing changes until you edit them.
http://wordpress:8080) or a reverse-proxied host, while links in the export keep using the site URL. The origin host is trusted like the site host, but link-local and cloud metadata addresses such as 169.254.169.254 are still refused.aouwal-static-site-export folder to /wp-content/plugins/.Install and activate the plugin, open Static Export in the admin menu, choose which post types and archives to include, then run the export. The plugin renders every page, localizes the assets and builds a ZIP file. Download the ZIP, unzip it, and upload the folder to your static host. The Deploy tab has the full walkthrough for GitHub and Cloudflare Pages.
It is a static site generator for WordPress. It converts your WordPress site into a static HTML site. The plugin crawls each public page, saves the rendered HTML, downloads and localizes all assets, and packages the result into a ZIP file. You can then host the site anywhere without WordPress, PHP or a database.
Yes. Every public post type is listed in Settings and you choose which ones to export. Products, portfolio items, documentation pages and other custom post types are exported with the same permalink structure they use on your WordPress site.
Usually yes. Elementor renders its layout to HTML and CSS on the server, so pages export with their design intact. Widgets that need a server, such as forms, popups with dynamic content and logged-in-only sections, cannot work on a static host and should be tested before you publish.
Product and category pages can be exported, so a product catalog works as a static site. The cart, checkout, my-account and product search pages are dynamic, so they cannot work without WordPress. The plugin does not convert WooCommerce into a static shop.
Yes. Images are downloaded and stored in the uploads structure the HTML expects, including srcset and <picture> sources. Images served from a CDN or another domain are localized too when they are reachable. Any single asset larger than the Maximum asset size setting (25 MB by default) is skipped and listed in the log.
Yes. Stylesheets and scripts are downloaded and rewritten to local paths, including CSS url() and @import references, so icons, fonts and background images keep working. Inline styles and inline scripts stay in the page. Files are not minified or combined, so the export matches what your site already serves.
Search and comments are server-side features, so they cannot run on a static host. The plugin removes search forms, comment forms, comment sections and comment feeds from the export by default. Both cleanup steps can be turned off in Settings, for example when you only need a partial static copy. There is no built-in replacement for them.
No, not unless you enable it. In Settings, under Attribution, you can turn on an invisible, source-code-only credit. It is off by default and never appears in the browser or in the exported pages your visitors see.
Yes. The export includes _redirects and _headers files, which Cloudflare Pages reads automatically, and the Deploy tab gives you the GitHub and Cloudflare Pages steps. Connect the repository once and every new export redeploys the site.
Not from the plugin settings. Scheduled exports, deploy targets and cache purging are not built in yet. The supported pattern is a cron job that runs wp aouwal-static-export run --batch=10, unzips the ZIP into a Git repository, then commits and pushes. Cloudflare Pages, Netlify and Vercel deploy the new commit automatically. The "Automate exports with WP-CLI and cron" section has the exact commands.
Yes. The output is plain HTML, CSS, JavaScript and media, so it runs on any static hosting or CDN: Netlify, GitHub Pages, Cloudflare Pages, Amazon S3, Vercel, or a basic web host. No WordPress, PHP or database is required.
No. You run the export from the WordPress admin and download a ZIP file. The Deploy tab gives you copy-and-paste commands for GitHub and Cloudflare Pages, so you can publish the site without writing any code.
No. The plugin only reads your content and writes the export to a files folder inside your own WordPress uploads directory. Your live site, database and settings stay unchanged, and you can delete the export files at any time.
Exports are written to wp-content/uploads/aouwal-static-site-export/, the same area WordPress uses for its own export files. The folder is protected from browsing with an index.php file and, on Apache, a .htaccess deny rule. The ZIP is served only through a signed, expiring admin link, never a permanent public URL, and the file disappears when the job is pruned. Nginx ignores .htaccess, so on Nginx either add a deny rule for wp-content/uploads/aouwal-static-site-export/ or move exports outside the web root. Developers can relocate the directory with the aouwal_export_dir filter.
The plugin requires WordPress 6.0 or later and PHP 7.4 or later. It is tested up to WordPress 7.1. It uses only the WordPress HTTP API and the WordPress filesystem, so it works on standard shared hosting.
Yes. Run a new export to create a fresh ZIP, then push the updated files. On Cloudflare Pages, every push to your connected repository redeploys the site automatically, so updates take only a few minutes.
Yes. Set Settings > Export mode to "Changed-only export", or run wp aouwal-static-export run --changed-only. The export starts from the last one, keeps every file whose page or asset did not change, and re-exports edited posts, the archives that contain them, the homepage, the posts page and any asset whose ETag or Last-Modified changed.
A changed-only run is much faster on a large site because unchanged pages are not requested at all and unchanged assets answer 304 Not Modified. The mode falls back to a full export automatically after a plugin, WordPress or theme update, a permalink or site URL change, or any setting that affects the output. Full export stays the default.
Yes, the ZIP still contains the complete site, because the export is a static snapshot rather than a patch. The saving is in the crawl: only changed URLs are fetched and rewritten, and unchanged files are copied from the previous export. If you deploy with rsync or Git, your sync tool still transfers only the files that differ.
Yes. The crawl runs in batches, and each batch is one request, so a PHP timeout applies to a batch, not to the whole site or to a single page. Batch size is set in Settings and accepts 1 to 50. The default is 5, so a 2,000-page site already exports in 5-page requests. Do not set 50 or 100: 50 is the maximum and 100 is not accepted. Lower it to 2 to 5 on shared hosting, raise it to 10 to 20 on a fast server. WP-CLI uses 10 URLs per batch by default: wp aouwal-static-export run --batch=10 Memory: 256 MB is the practical minimum and 512 MB is comfortable for large media libraries. Any single asset larger than the "Maximum asset size" setting (25 MB by default) is skipped and listed as an error in the log, so one huge video or archive cannot run the export out of memory. Discovery and ZIP packaging each run in a single request on current versions. Sites with tens of thousands of posts can still hit a limit there. If that happens, exclude heavy post types, raise max_execution_time temporarily, or run the export with WP-CLI.
Yes. Enter the username and password in Settings > Network > HTTP Basic Auth, then run the export as usual. The plugin sends the Authorization header only to your site's own hosts, so credentials never reach Google Fonts, a CDN or a Gravatar, and the header is dropped when the origin redirects to another domain.
The password is stored encrypted and is never rendered back into the settings page or written to the export log. Leave the password field blank to keep the saved value; tick "Remove stored credentials" to delete it. Basic Auth only: cookie-based protection and WordPress "site password" plugins are not supported, and without credentials a protected site still logs HTTP 401 for every URL.
Two settings in Settings > Network control it. Raise "Request timeout" (60 seconds by default, up to 120) when a single slow page or a large file is abandoned. Add a "Delay between requests" of 200 to 1000 milliseconds when your host or a security plugin rate-limits the crawl.
If PHP itself runs out of time, lower "Batch size (concurrency)" instead, because each batch is one PHP request. The same values are available for a single run with WP-CLI: wp aouwal-static-site-export run --timeout=90 --delay=250 --batch=5.
Yes. Set "Custom crawl origin" to the URL the server can actually reach, for example http://wordpress:8080 for a container name or http://127.0.0.1:8080 for a local proxy. The crawler requests pages and assets from that origin, while every link, canonical URL and sitemap entry still uses the normal site URL, so the exported site is identical to a direct crawl.
The origin host is trusted like the site host, so it does not have to be publicly routable. Link-local and cloud metadata addresses such as 169.254.169.254 are always refused, and the origin URL cannot contain a username or password. On a proxy that uses a private certificate authority, choose "Verify against a custom CA bundle" and enter the absolute path to the PEM file on the server.
Yes. The export keeps your page URLs, titles and content, generates a sitemap.xml and robots.txt, and strips version tags and staging "noindex" meta. Because the pages are static HTML, they load quickly and are easy for search engines and AI systems to crawl.
Yes, optionally. In Settings > Paths, turn on "Rewrite uploads path" and choose a target folder such as "uploads" or "media". When enabled, every reference and file uses the new folder: /wp-content/uploads/2026/01/photo.jpg becomes /uploads/2026/01/photo.jpg, including HTML attributes, CSS url() and @import references, srcset variants and manifest icons. The setting is off by default, so the export keeps the live /wp-content/uploads/ structure byte for byte when it is disabled. It changes URLs only and does not remove other WordPress fingerprints such as generator meta tags or already-localized script paths. Trade-off: old /wp-content/uploads/ links stop working unless you add redirects. The _headers cache rule follows the configured folder. A path that collides with an existing page is reported as an error and is not overwritten.
Yes. The Export screen shows Pause and Cancel buttons while an export runs. Pause stops at the end of the current batch and keeps every page and asset already written, so Resume can continue from the next pending URL. Cancel stops the export and deletes the partial output folder and any ZIP, so a wrong or failed export leaves nothing on disk. Both actions are recorded in the log. A cancel adds a line naming the last URL that was processed and how many items had been exported, and the same line is still there after a page reload.
Yes, if you paused it first. The state lives in the database, so reopening the Export screen shows the paused export with its Resume and Cancel buttons and the counts it reached. The crawl does not restart on its own, because two open tabs would otherwise drive the same queue at the same time.
An export that was never paused and whose tab was simply closed stays in the "crawling" phase. The screen detects that no batch has touched the output folder for five minutes, marks it as interrupted, and offers Resume or Cancel. From the command line, wp aouwal-static-export status shows the same state.
They are deleted. Cancel removes the job's output folder and its ZIP, plus the remaining queue rows, so a cancelled export cannot be downloaded or resumed by mistake. Other completed exports are untouched and stay downloadable. The last processed URL is kept in the job log, which is the quick way to see where the crawl stopped. If you cancel because the settings were wrong, fix the settings and start a new export; it begins from a clean folder.
The export retries transient failures automatically. A timeout, an HTTP 429 or a 5xx response is tried again up to two times by default, with a short backoff and respect for the Retry-After header. Permanent errors such as 401, 403 or 404 are not retried, because a second attempt would fail the same way. After the run, the Crawl health section on the Export screen lists every failed URL with its HTTP status or error text, the number of attempts, and the page that linked to a failed asset. The final log line lists the failure reasons too.
Yes. When the last export finished with failures, the Export screen shows a "Retry failed" button. It requeues only the errored items, keeps every file that was already written, and rebuilds the ZIP in place, so a single timeout does not force a full re-crawl.
From the command line, run wp aouwal-static-export retry. Add --batch=5 to lower the concurrency. The command exits with 1 if failures remain, so a cron job can stop before deploying a partial build.
post_modified, so an unchanged page is not requested at all and its copied file is kept.If-None-Match / If-Modified-Since). A 304 Not Modified keeps the copied file, so a replaced image with an unchanged URL is still picked up.--changed-only and --full for a single run without changing the saved setting. status now prints the export mode.{prefix}aouwal_export_state storing one fingerprint row per page and asset, with an automatic schema upgrade on update. The table is dropped on uninstall.wp aouwal-static-export retry [--batch=<n>]. status now prints failure reasons and the failed URLs.crawl, paused, done, cancelled), so reloading the screen restores the paused export with its Resume and Cancel buttons. The loop never resumes on its own.wp aouwal-static-export status, cancel and resume --batch=<n>. cancel exits with 1 so a cron script stops before pushing a partial build._redirects, _headers, robots.txt and sitemap.xml files are only written by a completed export, never by a paused or cancelled one.wp aouwal-static-export run accepts --timeout, --delay and --origin for a single run without saving them.<picture> and <source>, <video> and <track>, <template> blocks and custom elements survive the export without being re-nested.sprite.svg#icon icons keep working after asset localization.languages/aouwal-static-site-export.pot./*/feed/ /:splat/feed/index.xml 200.wp_remote_get) exclusively.