How I Ditched WordPress and Put Hermes in Charge of My Websites

I used to think maintaining a website meant maintaining WordPress.

The content was only one part of the job. Behind it sat the WordPress core, themes, plugins, PHP, a database, user accounts and an administration panel. All of those pieces had to keep working together, and all of them could become a maintenance or security problem.

I have now moved my websites in a different direction. The public content is delivered as static files. The working copies sit locally on my own computer, with the site structure, images, scripts, tests and publishing instructions kept together. Hermes Agent handles much of the administration around them: inspecting the source, making controlled updates, running validation, publishing reviewed files, checking the live result and scheduling recurring work.

What I actually replaced

WordPress combines several jobs in one online system:

• storing content;
• rendering pages;
• providing an editor;
• managing users;
• extending the site through themes and plugins;
• serving the finished result to visitors.

I separated those jobs.

My editable source now lives locally. Most pages are ordinary HTML, CSS, JavaScript, images and small data files. Some sites also have local Python or JavaScript tools that rebuild repeating sections, collect current information or generate a set of static pages. The web host receives only the files required to serve the finished site.

Hermes works with the local source and the project’s documented rules. The hosting account does not need a public CMS login or a database-backed editor just so I can change a heading, add an article or update a link.

The biggest benefit: less software exposed to the internet

A static site is not automatically secure, but it has a much smaller server-side attack surface than a typical WordPress installation.

There is no WordPress administration panel for an attacker to probe. There are no public WordPress user accounts to brute-force. There is no collection of plugins waiting for an urgent patch, and no theme or plugin update that can unexpectedly break compatibility with something else.

I also no longer have the recurring question: “Can I safely apply these updates, or will one of them break the site?”

The remaining risks are easier to see:

• the hosting account and deployment credentials still need protection;
• third-party scripts can still introduce privacy, security or reliability problems;
• forms and external services still need careful handling;
• domain registration, DNS and the hosting platform remain important;
• unsafe changes can still be published if the workflow is poorly controlled.

Static publishing removes a large class of CMS risk. It does not remove the need for cybersecurity.

I build those cybersecurity requirements into the website’s Markdown instructions so Hermes treats them as part of normal administration rather than an optional final check. The rules specify that credentials stay in an approved local secret file, that only the location—not the secret value—is documented, and that secret files must be excluded from Git, GitHub and deployment. They also define secure transfer requirements, the permitted upload scope, privacy scans for internal paths or personal information, required backups and version-control checks, and a fail-closed rule: if validation, certificate verification or production comparison fails, Hermes must stop and report the problem instead of publishing anyway.

I always have the complete local source

One of the strongest advantages is also one of the simplest: the website exists as normal files on my own machine.

I can open it without logging into a remote dashboard. I can search the whole site, compare versions, back it up, test it locally and move it to another host. The live server is a deployment target, not the only place where the site exists.

That changes the recovery model. If a hosting account fails or a public file is corrupted, I do not need to reconstruct the site from a database export and a collection of plugins. I have a known local source tree that can be checked and published again.

For important projects I can also keep the source in a private Git repository and retain separate backups. Version history makes it possible to inspect what changed and restore a previous known-good state without depending on a CMS revision screen.

Hermes is the operator, not the website

Hermes does not sit between a visitor and the page. Visitors are not waiting for an AI model to answer a request, and the public website does not stop working if an AI provider is unavailable.

The delivered site remains plain static content. Hermes operates on the maintenance side.

Depending on the project, I use Hermes to:

• find the authoritative source files;
• check project instructions before changing anything;
• update a page, catalogue or generated section;
• run local link, content and metadata checks;
• launch a local preview;
• test mobile and desktop rendering in a real browser;
• verify privacy and security constraints;
• publish an explicit set of reviewed files;
• fetch the live result and compare it with the local version;
• update the project documentation;
• schedule recurring audits or publishing runs;
• report a precise success or failure.

That is much closer to having a careful website administrator than having an AI copywriter.

The Markdown files are the operating manual

Hermes can work across several websites because each project includes Markdown documentation explaining how that particular site should be administered. The agent does not have to guess which folder is authoritative, what the brand should sound like or which command is safe to run.

The main files typically include:

• an AGENTS.md or .hermes.md file containing the rules an agent must follow;
• a README.md describing the site structure, local preview, tests and deployment method;
• maintenance or editorial documents for recurring work and protected workflows;
• a changelog or project record showing significant previous decisions.

These files can tell Hermes:

• where the authoritative local source lives;
• which public domain and remote webroot belong to the project;
• which pages are generated and must not be edited by hand;
• the preferred writing style, visual conventions and public identity;
• privacy rules, forbidden content and protected integrations;
• the exact validation commands required before publication;
• which files may be uploaded and which must remain local;
• how to verify that production matches the reviewed source.

This is also where I document the GitHub workflow. Hermes can check the working tree before editing, confirm the correct repository and account, identify uncommitted or unpushed work, and keep the repository current after a validated change. The rules prevent it from casually overwriting unrelated work or pushing the project to the wrong account.

Credentials are handled differently. The Markdown documentation records where the approved local credentials are stored and which deployment method uses them, but never contains the password, token or secret itself. Secret files stay outside the public site, are excluded through .gitignore, and must not be included in a commit, GitHub push or website upload. Before publishing, Hermes can inspect the intended file set and staged changes for accidental exposure without printing the credential values into the conversation.

This turns the Markdown files into an operating contract. They preserve my preferences and safety rules between sessions, make the workflow understandable to another tool or human, and give Hermes a consistent definition of “done.”

“Hermes validates everything” needs one qualification

Hermes cannot validate a site by intuition alone. I have to define what “correct” means for each project.

The useful pattern is to put those rules beside the website. A project might require checks such as:

• every internal link resolves to a real file;
• required navigation appears on every page;
• no private email address or local filesystem path is exposed;
• affiliate disclosures are present where required;
• structured data and sitemap files are valid;
• images exist and fit within the mobile viewport;
• a protected page remains suitable for embedding in another system;
• generated pages are reproducible;
• the live file matches the reviewed local file byte for byte.

Hermes reads those requirements, runs the project’s checks and verifies the served output. If the tests fail, publication should stop.

This is more reliable than telling an agent to “have a look and make sure it seems okay.” The validation is inspectable, repeatable and specific to the site.

Cybersecurity becomes part of the publishing contract

With WordPress, security work often arrives as a stream of update notices. In my static workflow, security is designed into the publishing rules.

Examples include:

• secrets stay in ignored local files rather than in the repository or website;
• deployment uses encrypted FTPS with certificate verification;
• only the intended files are uploaded;
• public pages are scanned for credentials, private addresses and internal notes;
• external scripts and embeds are treated as explicit dependencies;
• scheduled publishers fail closed when validation or secure transport fails;
• the live site is checked after upload rather than assuming that a successful transfer means a successful release.

The important distinction is that Hermes follows a security contract written for the project. It is not granted unlimited authority and trusted to improvise.

Scheduled work without a permanently open CMS

Hermes includes scheduled jobs, so recurring website administration does not require me to remember every check manually.

I can schedule work such as:

• a weekly website maintenance audit;
• a regular article release with defined research and validation gates;
• a content refresh from approved data sources;
• a check that a dynamic feed, booking link or public page is still current;
• a concise completion email or failure alert.

Some of my sites combine static publishing with locally generated current information. A local process collects the data, validates it, rebuilds the public files and uploads the result. The public server still serves simple files; the complexity remains on the controlled maintenance side.

Scheduled agents also have an important limitation: they cannot stop mid-run and ask me what I meant. Their instructions therefore need clear boundaries, a defined working directory, exact checks and an unambiguous rule for when to publish or report a blocker.

It is easier to keep different websites separate

My sites do not all work the same way.

A business site may have evergreen course links and a curated article library. A local information site may rebuild weather, news and event data on a schedule. Another site may publish regular editorial pages from a catalogue and renderer. BillBaud itself combines a portfolio, practical guides and a product section.

Each project has its own source folder, instructions, tests, publishing method and protected constraints. Hermes can move between them because the operating knowledge is stored with the projects and in my durable documentation.

That matters on shared hosting. Several domains may use the same hosting account, but they must not be treated as one website. A controlled publishing workflow identifies the exact project, remote path and public URL before changing anything.

The workflow I now prefer

This is the part Hermes now performs for me. I define the project rules and decide what the website should say; Hermes carries out or coordinates the administration and publishing sequence:

1. Start from the local source. Confirm the correct project and check its current version-control state.
2. Read the project rules. Identify protected pages, privacy constraints, generated files and the approved deployment method.
3. Make the smallest required change. Avoid unrelated rewrites or broad uploads.
4. Run deterministic checks. Validate links, content, metadata, data files and project-specific invariants.
5. Serve the site locally. Check the actual HTTP output, not only the files on disk.
6. Inspect real rendering where it matters. Test representative mobile and desktop viewports.
7. Publish only the intended files. Keep credentials and development artefacts out of the upload.
8. Verify production. Fetch the exact live routes, check expected content and compare them with the reviewed local files.
9. Record the outcome. Update the project documentation and report the live link or a precise failure.

Hermes executes that sequence consistently rather than treating a file edit as the end of the job. It checks the project before changing it, runs the documented gates, stops when validation fails, verifies the public result and records the outcome. More importantly, the sequence remains understandable to me and portable to another tool or human operator.

What I gave up

WordPress has real advantages. It provides a polished browser editor, user roles, a huge plugin ecosystem and familiar workflows for teams. Someone who publishes frequently from several devices, needs non-technical editors or relies on complex server-side features may be better served by WordPress or another managed CMS.

The main constraint of my approach is that a static site does not automatically provide the interactive features available through WordPress plugins. Membership systems, customer accounts, complex forms, onsite search, comments, shopping carts and frequently changing database-driven content need additional services or custom development. A plugin may provide one of those features much faster than building and maintaining it independently.

That is not a serious limitation when a site is mostly static: articles, business information, project pages, images and links do not need a database-backed CMS simply to exist. Where richer interaction, multiple browser-based editors or an established plugin workflow is central to the site, WordPress still has an important place.

My approach moves more responsibility into the local project. I need disciplined backups, clear source ownership, tested publishing scripts and care around deployment credentials. A static site can also become messy if pages are copied by hand without catalogues, templates or validation.

The point is not that WordPress is bad. It is that I was carrying far more online machinery than my websites needed.

Why this has worked for me

I now have websites that are mostly boring from a server’s point of view. They are collections of files served over HTTPS.

The interesting part happens before publication: local source control, project instructions, automated checks, browser validation, secure deployment, live comparison, scheduling and documentation. Hermes coordinates that work and gives me one place to ask for an update without turning the public site into an AI service.

I no longer spend time maintaining WordPress simply because the content once lived there. I maintain the content and the publishing system I actually need.

That has given me fewer moving parts online, a smaller attack surface, complete local ownership, repeatable validation and a clearer recovery path. For my sites, that is a much better trade.