Static Site Exporter, a WordPress plugin that dumps your content into Markdown and YAML

Exporting rendered content, not stored rows

The decision that shapes everything else in this plugin is what gets exported. The documentation states that the exporter runs post content through the `the_content` filter prior to export, which means third-party plugins get a chance to modify the output before it is written. In practice that means shortcodes are expanded, embeds are resolved and the text a reader would see is what lands in the Markdown file, rather than the raw `post_content` value. The same principle applies to metadata: all `post_meta` and the fields inside the `wp_posts` table become YAML front matter, and everything in the `wp_options` table becomes the front matter of a generated `_config.yml`. This is a sensible choice for a migration tool, because the rendered form is the form people want to keep. It also means the output is only as stable as the plugin stack around it, since a third-party filter that behaves differently later will produce a different file.

One zip with _config.yml, pages and _posts

The output is a single zip file, and its layout follows Jekyll conventions: a `_config.yml` at the top, a pages directory, and a `_posts` folder holding one `.md` file per post with the proper Jekyll naming convention. The front matter carries the taxonomies and metadata as YAML, ready for a static site engine to parse. Because the layout is Jekyll shaped, Hugo users get a directory they can adapt rather than a native Hugo structure, and the project describes the target as Jekyll or Hugo or any other Markdown and YAML based site engine. The front matter is verbose by design, since the whole `wp_posts` and `post_meta` content is carried over, which is a point in favour of the export as an archive and a point against it as a hand-edited source. A reader who plans to rewrite the front matter anyway might be better served by a narrower export.

WP-CLI lets you export a slice instead of the whole site

The plugin is not only a one-click button. Selective export is available through WP-CLI, and the documentation lists a dedicated page for exporting by category or tag, another for custom post types, and another for custom fields. That matters for large sites, where a full export of every post type is rarely what a migration needs, and for partial migrations where only a section of a site is moving. The plugin is also published in the WordPress plugin directory under the name jekyll-exporter, and the repository keeps a `jekyll-export-cli.php` entry point and a `jekyll-exporter.php` plugin file at the top level, with the implementation in `lib/` and the test suite in `tests/`. The composer.json, phpstan.neon, phpcs.ruleset.xml and phpunit.xml files at the root show a project with static analysis, a coding standard and unit tests wired in, which is unusual for a plugin of this size.

Installing it: drop the folder in and click the menu item

The documented usage is three steps and no configuration. The plugin folder goes into `/wp-content/plugins/`, it is activated in the WordPress dashboard, and then `Export to Jekyll` is chosen from the `Tools` menu. There are no settings to configure, which is the plugin's stated design. For local development the repository ships a Docker Compose file that brings up WordPress, a WP-CLI container and a MariaDB service, and mounts the working copy into the plugins directory so the code you are editing is the code the site runs. Starting the stack should give you a WordPress site on port 8088 with the exporter already mounted at `/var/www/html/wp-content/plugins/jekyll-exporter`.

services:

  wordpress:
    image: wordpress:latest
    restart: always
    ports:
      - 8088:80
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: exampleuser
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_NAME: exampledb
      WORDPRESS_DEBUG: 1
    volumes:
      - wordpress:/var/www/html
      - ${PWD}/:/var/www/html/wp-content/plugins/jekyll-exporter

The plugin directory in the mounted path is named jekyll-exporter, which is also the slug it uses in the WordPress plugin directory.

The Docker stack also gives you a WP-CLI container

The Compose file is worth reading for a second reason: it defines a separate `wpcli` service built from the `wordpress:cli` image, sharing the same database credentials and the same volume mounts as the WordPress container. That means the selective export commands can be run from a shell against the same site without installing WP-CLI on your machine. The database service uses the `mariadb:lts` image with `MYSQL_RANDOM_ROOT_PASSWORD` set, and the WP-CLI container sets `MYSQL_SSL_MODE: DISABLED` and `MYSQL_CLIENT_FLAGS: --ssl-mode=DISABLED` to work against a local database without TLS. The Compose file also declares named volumes for the WordPress files and the database. A local stack like this is the practical way to check what a full export of your own content looks like before you run it against the live site.

What the export will not do for you

Two limits are visible from the documentation alone. The first is direction. The plugin produces Markdown and YAML from WordPress; nothing in the project describes reading a static site back into WordPress, so this is a one-way move with no sync loop behind it. The second is coverage of structure beyond content. Posts, pages, taxonomies, metadata and settings are converted, and the documentation has separate pages for custom post types and custom fields, which indicates these need attention rather than arriving fully automatic. A second factor sits outside the plugin: the export mirrors whatever the site renders, so a page whose content depends on a shortcode from a plugin you later remove will need editing in the new system. The plugin also does not attempt to reproduce a theme, so the visual layer of the WordPress site does not travel with the export.

A steadily released plugin, versioned to a date

The release history shows a project that ships often and numbers cleanly. v4.4.0 landed on 2026-10-11, v4.3.0 on 2026-09-30 and v4.2.0 on 2026-09-27, and the repository is not archived, with the last push on 2026-10-19. The presence of a Renovate configuration at the root, a GitHub Actions CI badge and a `.devcontainer/` directory suggests a maintained dependency and development environment rather than a one-off script someone left behind. The licence is GPL-3.0, with the text in `LICENSE.txt` and a `readme.txt` in the plugin header format that WordPress expects. The repository also keeps a `docs/` folder with the changelog and the pages linked from the README, including a page on the minimum required PHP version, which is the first thing to check when a plugin fails to activate.

Editorial conclusion

Adopt Static Site Exporter if you are moving a WordPress site to a static engine and want the content in a form you can commit to a repository, and skip it if you need bidirectional sync, because the export is one way and the plugin does not read your site back. Check three things before you start: that the content on the live site, after third-party plugins have run their filters, is what you want in a Git history, since the export reflects rendered output rather than stored rows; that the plugin version you install matches the PHP version your host runs, which the documentation tracks on its own page; and that the selective export path documented for WP-CLI covers the post types you need, since the default export takes everything.

Frequently asked questions

Official sources

1. benbalter/wordpress-static-site-exporter on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases