Deploying WordPress as a static website

WordPress is a fantastic website builder. However, after more than 15 years of resolving security incidents, I’ve come to realize that most companies when given the choice would rather use WordPress as a static site generator than the typical wordpress install .

When to Choose the Static Route:

• Only a small number of content editors (often just one)
• Minimal interactivity required (e.g., contact form, basic search)

As an exercise, this website will be deployed statically.

The Lazy Way

This approach leverages wget mirroring feature to crawl and clone the website accessible pages and resources.

#!/usr/bin/env bash
set -e
DEV_URL="http://localhost:8000"
OUTPUT_DIR="./static-site"

echo "Cleaning output directory..."
rm -rf "$OUTPUT_DIR"
mkdir -p "$OUTPUT_DIR"

echo "Generating static site from $DEV_URL ..."
wget \
  --mirror \
  --convert-links \
  --adjust-extension \
  --page-requisites \
  --no-parent \
  --trust-server-names \
  --restrict-file-names=windows \
  --directory-prefix="$OUTPUT_DIR" \
  "$DEV_URL"

mv "$OUTPUT_DIR"/localhost+8000/* "$OUTPUT_DIR"
rm -rf "$OUTPUT_DIR"/localhost+8000

echo "Static site generated in $OUTPUT_DIR"

Caveats

While this method may be sufficient for simple personal blogs, it becomes increasingly difficult to scale as website complexity grows.

Pages that are not directly linked within the site’s content will not be captured. Simply installing a sitemap generator does not resolve this, as most sitemaps return XML files, which do not contain the HTML content wget requires to clone pages.