I built this plugin while doing client work, not as a product idea.
The client wanted WordPress because they were comfortable with it and the operational risk was low. That part was fine. The friction appeared when they needed a small set of Markdown documentation files to exist on the backend of the site.
The catch: they were on managed hosting and had no FTP access.
At that point, their realistic options were:
Create and maintain a GitHub repository just to manage a few text files
Convert documentation into WordPress pages and treat them as content
Neither option felt appropriate for what were essentially infrastructure-level documents.
That raised a broader question for me:
Would someone who needs to routinely update documentation for audits, transparency, or compliance really want to manage it via FTP or GitHub if they don’t otherwise need those tools?
Probably not.
The idea: documentation as a first-class CMS concern
The solution I landed on was to treat documentation files as managed artifacts inside the CMS, but still respect how the web expects those files to exist.
The core requirements were:
Edit Markdown files directly in WordPress
Write files to the filesystem where possible
Degrade gracefully when filesystem permissions are limited
Keep the files usable outside of WordPress
File placement strategy
The plugin checks whether the WordPress root is writable:
If root is writable:
Markdown files are placed where they normally live (e.g. /README.md, /llms.txt).
If root is not writable (common on managed hosting):
Files are stored in a central, predictable location that can still be referenced and served.
This avoids hard failures and removes the need for FTP entirely.
From the site administrator’s perspective, they’re just editing documents in the admin panel. Where the file ends up is an implementation detail handled by the plugin.
**
Why Markdown works well here**
Markdown is a good fit for documentation because it’s:
Human-readable
Diff-friendly
Easy to audit
Portable outside WordPress
But raw .md files aren’t ideal for public consumption.
So every Markdown file managed by the plugin automatically generates a corresponding HTML document.
This serves two purposes:
Readability – legal documents and policies are much easier to consume as HTML
Indexability – HTML documents are easier to surface via search engines and internal linking
The Markdown file remains the source of truth. The HTML is a generated artifact.
*Curated document pages
Many sites don’t just have one document. They have several:
Privacy Policy
Terms of Service
Cookie Policy
*
Compliance or disclosure documents
Instead of forcing each document to be a standalone page, the plugin allows site owners to curate a documentation page.
The workflow looks like this:
Create a blank WordPress page (e.g. /docs or /legal)
Point the plugin to that page
Select which Markdown documents to display
Add a short description for each document
The result is a clean, generated page that lists documents with:
Title
Description
Link to the .md file
Link to the HTML-rendered version
This can be done via shortcode or by designating a page in the plugin settings.
Print and PDF support
One thing that comes up more often than people expect: printing documentation.
W
hether for internal audits or external compliance requests, users sometimes need a physical or archived copy. The plugin supports printing and saving rendered documents as PDFs from the front end.
It’s not flashy, but it’s practical.
Expanding beyond Markdown: raw text files that still matter
Toward the end of development, I
started thinking about other plain-text files that are still relevant but often scattered across plugins or manual edits.
robots.txt
Despite its age, robots.txt is still
a meaningful signal source.
It can:
Control crawler inclusion/exclusion
Help remove content from archive sites
Express intent even when it isn’t strictly enforced
The plugin provides clean access to edit and manage robots.txt without needing an SEO plugin.
Sitemaps
Sitemaps are another classic requirement.
Rather than bundling SEO features,
the plugin focuses on sitemap generation as a pure infrastructure concern:
Generate a single sitemap
Or split it into multiple sections for large sites
No keyword tooling, no analytics — just accurate content signaling.
llms.txt
Finally, I added support for llms.txt.
This file isn’t widely adopted yet, but awareness is growing. Conceptually, it’s similar to robots.txt, except it communicates intent to LLMs / AI systems.
Depending on the site owner’s goals, it can be used to:
Request exclusion from training datasets
Or signal that a site should be visited more frequently for accurate representation
It’s not enforceable, but neither was robots.txt at the beginning. Intent signaling still matters.
Why bundle all of this together?
Individually, these features already exist across multiple plugins.
The point wasn’t to replace them — it was to offer a clean, centralized way to manage documentation and signaling files without:
FTP access
GitHub dependencies
Bloated SEO tooling
The plugin treats these files as infrastructure, not marketing assets.
Open source by design
The plugin is fully open source and designed to work within WordPress constraints rather than around them.
It respects:
*Managed hosting limitations
WordPress admin workflows
Filesystem realities
*
If you’re interested, the code is available on GitHub, and feedback or contributions are welcome.
Closing thoughts
This started as a small solution to a repeating client problem, but it reflects a broader pattern:
WordPress sites increasingly need to expose machine-readable documentation, not just human-facing pages.
Markdown, plain-text files, and clear signaling are still part of the web’s foundation — even as platforms evolve.
Sometimes the best tools aren’t flashy. They just remove friction.
Top comments (0)