--- title: "Why I Replaced WordPress with Hugo: An Enterprise Security Engineer's Shift to Static Publishing" date: 2026-10-22 canonical: "https://codeandcypher.com/posts/why-i-moved-from-wordpress-to-hugo/" description: "Why enterprise security engineer Joshua Wortz traded WordPress for Hugo: eliminating attack surface, cutting runtime bloat, and embracing DevSecOps purity." author: "Joshua Wortz" --- # Why I Replaced WordPress with Hugo: An Enterprise Security Engineer's Shift to Static Publishing > Why enterprise security engineer Joshua Wortz traded WordPress for Hugo: eliminating attack surface, cutting runtime bloat, and embracing DevSecOps purity. --- ## 🏛️ The Cognitive Dissonance of a Security Engineer on WordPress For over two decades, I have engineered, hardened, and defended high-stakes enterprise infrastructure—from managing threat detection and clinical telemetry in regulated healthcare environments to architecting Zero Trust access models protecting tens of thousands of personnel and cloud assets across Amazon Web Services (AWS). My entire professional philosophy centers on fundamental security axioms: 1. **Minimize the attack surface** to the absolute bare essentials. 2. **Eliminate ambient authority** and enforce least privilege. 3. **Decouple critical dependencies** and favor deterministic, auditable architectures. 4. **Shift security verification left** into automated CI/CD quality gates. Yet for years, my personal technical writing lived on a standard **WordPress** instance. One evening, after spending a full workday auditing cloud identity perimeters and triaging upstream supply chain vulnerabilities, I logged into my personal site to publish an analysis of Kerberos identity boundaries. As I stared at the `/wp-admin/` login portal, the cognitive dissonance became impossible to ignore: To serve fundamentally read-only technical articles, code blocks, and diagrams, I was operating a dynamic multi-tier application stack. I was running an active Linux server, an Apache/Nginx web server, a live PHP-FPM execution runtime, a stateful MySQL database, and 12 third-party plugins—each executing arbitrary server-side PHP with direct read/write access to the filesystem and database. Every unauthenticated web request from a reader was triggering dynamic database queries, server-side string concatenation, and runtime rendering. Every plugin was an uninspected third-party dependency with the power to compromise the underlying host. I was teaching enterprise defense while running the web's most notorious attack surface in my own backyard. That night, I decided to eliminate the monolith. I migrated everything to **Hugo**, coupled it with a Git-native DevSecOps pipeline, and never looked back. Here is why making that transition was the single best engineering decision I have made for my publication. --- ## 🛡️ 1. Attack Surface: Decoupling the Dynamic Execution Tax The primary flaw of traditional Content Management Systems (CMS) like WordPress, Ghost, or Drupal is architectural over-engineering. They treat every page view as a dynamic transaction requiring a live database connection and an interpreted script runtime. For an e-commerce platform with dynamic shopping carts, user sessions, and inventory tracking, dynamic execution is necessary. For a technical publication, personal engineering journal, or research archive, **99.9% of user interactions are strictly read-only**. When you place a dynamic CMS on the public internet, you inherit the **Dynamic Execution Tax**: ```mermaid graph TD subgraph WP ["Dynamic WordPress Architecture (High Attack Surface)"] A["Internet Visitor"] -->|HTTP GET Request| B["Web Server (Nginx/Apache)"] B -->|Process Request| C["PHP-FPM Runtime"] C -->|Execute Logic| D["WordPress Core + 25 Plugins"] D -->|SQL Queries| E[("MySQL / MariaDB Database")] E -->|Return Data| D D -->|Construct HTML on the Fly| C C -->|Render Stream| B B -->|Deliver Response| A ATTACKER["Adversary / Botnet"] -.->|Credential Stuffing| F["/wp-admin/ & xmlrpc.php"] ATTACKER -.->|SQL Injection / RCE| D end subgraph HG ["Static Hugo Architecture (Zero Server Attack Surface)"] G["Author in Obsidian / Git"] -->|Git Commit & Push| H["CI/CD Gatekeeper"] H -->|Gitleaks & Automated Tests| I["Hugo Compiler (Milliseconds)"] I -->|Static HTML/CSS/SVG Artifacts| J["Global Edge CDN (Cloudflare Pages)"] K["Internet Visitor"] -->|Instant Sub-ms GET| J end ``` ### The Vulnerability Treadmill In the WordPress ecosystem, your security posture is only as strong as your least-maintained plugin. According to security industry reports, over 90% of WordPress vulnerabilities originate not in WordPress core, but in third-party plugins and themes: - Unauthenticated SQL Injections (SQLi) - Arbitrary File Upload and Remote Code Execution (RCE) - Stored Cross-Site Scripting (XSS) - Authentication Bypass and Privilege Escalation Operating a WordPress site means living on a patch treadmill. Every Tuesday morning or Friday afternoon, an automated vulnerability alert fires because a plugin author forgot to sanitize a `$_GET` parameter or validate a REST API nonce. If you don't patch within 24 to 48 hours, automated exploit bots scan your host and inject SEO spam or web shells into your `wp-content/uploads` directory. ### The Zero-Surface Static Guarantee With Hugo, **there is no server-side runtime on the public internet**: - No PHP interpreter that can be coerced into deserializing untrusted payloads. - No MySQL database that can be dumped via SQL injection. - No `/wp-login.php` or `xmlrpc.php` endpoints exposed to brute-force credential stuffing. - No administrative session cookies that can be hijacked. The public-facing artifact deployed to [Cloudflare Pages](https://pages.cloudflare.com/) is pure, immutable, pre-compiled static files: HTML, CSS, client-side SVG, and static assets. If an attacker probes `codeandcypher.com` for vulnerabilities, there is literally nothing to exploit. An edge HTTP server reading an immutable file from disk is impervious to the vast majority of web application CVEs. --- ## ⚡ 2. Universal Design for Learning (UDL) & Edge Performance Beyond cybersecurity, performance is a core accessibility issue. In my work as an educator and NCyTE Fellow, I advocate for **Universal Design for Learning (UDL)**. In education, accessibility is often framed solely around screen readers and alt tags. But true accessibility must also account for **cognitive load, device constraints, and digital equity**. Many students, international researchers, and junior practitioners access technical documentation on modest 8GB laptops, budget mobile devices, or unstable wireless connections. A standard WordPress theme—loaded with Gutenberg block libraries, Google Fonts scripts, jQuery dependencies, analytics widgets, and bloated stylesheet cascades—regularly ships: - **3MB to 6MB** of payload per page load. - **50 to 80** round-trip HTTP requests. - **2.5 to 4.5 seconds** of Time to Interactive (TTI) on mobile devices. - Severe layout shifts that disorient neurodivergent readers and visual processors. When a reader clicks a link to review an incident response blueprint or an architectural diagram, they should not have to wait while a dynamic server processes PHP scripts and fetches database rows across an ocean. ``` Metric Comparison: WordPress Monolith vs Hugo PaperMod ---------------------------------------------------------------------- Metric Dynamic WordPress Static Hugo (Edge) ---------------------------------------------------------------------- HTML Payload Size ~120 KB (Dynamic) ~14 KB (Semantic) Total Page Weight 3.5 MB – 5.2 MB 180 KB – 320 KB Requests per Page 45 – 75 requests 6 – 10 requests Time to First Byte 450 ms – 1,200 ms 12 ms – 35 ms (Global Edge) Lighthouse Performance 55 – 75 98 – 100 External JS Frameworks jQuery, React blocks Zero (Vanilla HTML5/CSS) Monthly Hosting Cost $25 – $80 / month $0 / month ---------------------------------------------------------------------- ``` With Hugo and my stripped-down PaperMod layout: - **Compilation Speed:** Hugo compiles my entire publication—every post, archive, tag, taxonomy, and search index—in **under 200 milliseconds**. - **Global Edge Delivery:** Every compiled page is cached across hundreds of Cloudflare edge data centers globally. A student in London, Tokyo, or Los Angeles experiences Time to First Byte (TTFB) in the low tens of milliseconds. - **Static Purity:** I enforce zero heavy JavaScript frameworks. The site requires no React, Vue, or jQuery runtimes to render prose and code snippets cleanly. Even if client-side JavaScript is completely disabled, 100% of the content remains fully legible, responsive, and structured. --- ## 🔄 3. Git-Backed DevSecOps vs Database Black Boxes One of the most frustrating aspects of maintaining a technical blog on WordPress is how content is treated: **trapped inside relational database blobs**. In WordPress, your articles live inside the `wp_posts` table of a MySQL database. Code snippets, formatting, and markdown are converted into database records mixed with proprietary serialized data and shortcodes. This creates severe operational pain points: 1. **No True Version Control:** Revisions in WordPress are clunky database rows. You cannot diff two versions of an article using standard developer tooling, open an experimental branch, or review edits via a Pull Request. 2. **Environment Drift:** Creating a local development or staging environment for WordPress requires exporting a SQL dump, importing it into a local MySQL instance, and running database search-and-replace scripts to update URLs. It is fragile, error-prone, and slow. 3. **Disaster Recovery Friction:** If a database becomes corrupted or a bad update botches a table, recovery depends on database backups, snapshot restoration, and database downtime. ### The GitOps Paradigm With Hugo, **everything is plain text in Git**. Every article is an authored Markdown file (`.md`) residing in a repository. Content is managed using the exact same DevSecOps workflows that govern modern software engineering: - **Immutable Revision History:** Every typo fix, architectural expansion, and diagram update is a cryptographically signed Git commit. I can `git diff`, `git bisect`, or `git revert` instantly. - **Branching & Staging:** I draft new articles, research papers, and series on the `develop` branch and deploy them automatically to my staging environment (`develop.codeandcypher.pages.dev`). Production promotion to `master` occurs only after thorough verification. - **Automated Security Gates:** Because content is code, I run comprehensive headless test suites before a build is ever allowed to touch production. My automated Python test suite validates: - **Anti-Leakage Scanning:** Gitleaks scans every commit for accidental API keys or credentials. - **WCAG 2.1 AA Compliance:** Automated validators verify semantic HTML landmarks (`
`, `