by Gareth Bult on WordPress.org
Static site generator using Git for storage. Comes with free integrated Git + Pages solution including Live WebStats.

Dashboard, Profiles
Welcome to the Make Me Static Plugin for WordPress. This plugin is a static site generator and aims to create and maintain a static copy of your WordPress website within a Git repository. This version includes automatic access to a free Git solution and Page provider platform. (so no setup or credentials are necessary)
Alternatively the static site can be generated and stored in a GitLab Git Repository that can be used as a source for a static page platform such as CloudFlare Pages. The plugin provides customised sitemap and change tracking which connects to an external crawling service which does all the heavy lifting.
We have made great efforts in this version to minimise the configuration required to get going, if you have any problems (with anything) please let is know and we’ll do our best to help. Check out this YouTube video for an introduction to static front-ends and a walk-through of converting a pre-existing WordPress site into a WordPress site with a static front-end.
The plugin connects to a directory service on the Internet at one of the directory URL’s listed below. This in turn will point the plugin to a ‘crawler’ that has been allocated to your site.
When you ask the plugin to make a static copy of your site, it will instruct the crawler to visit all the pages on your site to determine which have changed since it’s last visit. Any changed pages will be copied to a Git repository, which in turn can publish pages directly to a page hosting service.
The default option is to use a Git account hosted by MadPenguin, and to publish the site on MadPenguin’s page hosting platform. As a result the default options do not require any specific Git or Page hosting configuration to get going. If on the other hand you choose to use a hosted Git service such as GitLab, you will need to enter some credentials for your online account, and from there configure your GitLab account to publish to a page hosting service.
Once you have successfully published a static copy of your site, all you need to do is point your domain at the address of the page hosting service, and asssuming your domain matches the one you
entered when setting up your profile within the plugin, you should be up and running.
The service retains a metadata database for the site which includes file names, sizes and modification times, together with any credentials that have been added when creating a profile. (Sensitive credentials and other information is encrypted at rest). The external service is responsible for all scanning and processing activities to mitigate strain on the WordPress server.
The only private data transferred to the external service is the information you enter when creating a profile. All other information is obtained via an anonymous external scan, hence publically available. If you have selected the default Git option, then the service will also retain a static copy of the site.
Make me static directory service URL’s;
Other URL’s used to load code;
Note that this in an integrated solution, the 3rd party crawling service is owned and operated by the plugin authors on a combination of cloud hosted and on premesis equipment.
If you opt to use the integrated Pages platform, this also provides a live WebStats option that uses the following URL;
This allows live webstats to be seamlessly delivered into your control panel and updated in real-time via a websocket connection. Do not use this URL directly!
This URL is only referenced once you click on the webstats icon next to your profile.
The WordPress site is scanned by the MMS service under direction from the WordPress plugin. This off-loads the scanning process to specialised software which aims to minimise the loading on the WordPress server while scans are in progress.
There are three types of scan that can be performed;
An “update”, which literally only looks at entries with changed sitemap timestamps
(this is very quick and great for typo’s and any changes that only affect a single page)
A “synchronise”, typically this will scan every asset on the WordPress site and compare a checksum of each asset against it’s database to see if it’s changed since the last scan. Any changes are then transferred to the connected Git repository.
A “Git verification”, this is like a “synchronise”, but also scans the Git repository for assets that are no longer referenced by the site (and removes them).
As the site is scanned “from the outside” there should be no risk of the plugins actions exposing any data that isn’t already public. By the same token the external service has no ability to modify WordPress so the security footprint of the plugin is tiny.