Usage Guide
Use this site as a publishing system for EmDash docs, migration content, plugins, templates, and product updates.
What this website should do
emdashcmseverything.com should not behave like a generic landing page. It should work as a public knowledge and distribution layer for the EmDash ecosystem.
That means combining several content jobs in one coherent system:
- explain what EmDash is
- teach people how it works
- show where it fits
- publish plugins and templates
- guide WordPress migrations
- announce product progress and releases
Recommended information architecture
The current structure is designed to support that model:
docs/docsfor evergreen documentationdocs/use-casesfor scenario-driven adoption contentdocs/pluginsfor plugin directory entriesdocs/templatesfor template directory entriesdocs/blogfor updates, tutorials, and editorial content
This is a better fit than stuffing everything into a single marketing homepage or hiding product information inside framework components.
How to use each section
Docs
Use this section for durable, high-intent content:
- getting started
- feature explanations
- deployment notes
- architecture overviews
- FAQ
These pages should answer the questions people ask before and during evaluation.
Use Cases
Use this section to translate product capabilities into buyer context. EmDash is easier to understand when it is framed as a fit for:
- editorial publishing
- docs and knowledge bases
- plugin ecosystems
- template businesses
This section should connect product shape to real outcomes.
Plugins
Plugin pages should feel like small product pages, not just release notes. Each one should explain:
- what the plugin does
- who it is for
- current status
- pricing or availability
- download path
- setup and compatibility
Templates
Template pages should make it easy to compare packaged site starters. Good entries include:
- target audience
- screenshots
- stack details
- version and release date
- demo link
- download or repository link
Blog and Updates
This section should capture motion:
- release notes
- migration guides
- product commentary
- tutorials
- case studies
That is what keeps the site feeling active and compounding.
Publishing workflow
For this project, the simplest healthy workflow is:
- Add or revise content in
docs/ - Review the Git diff
- Preview locally
- Deploy the built static site to Cloudflare Pages
This workflow is especially effective when AI is helping with drafting, editing, restructuring, and consistency.
Why this structure works well with AI
AI editing is much more reliable when the site is built around:
- small MDX files
- explicit frontmatter
- reusable page components
- stable route patterns
- content separated from UI code
That is why the current site shape is intentionally content-first.
How this relates to EmDash itself
Official EmDash materials emphasize runtime collections, admin editing, plugins, media storage, and cloud portability. Those are product strengths. But a public-facing ecosystem site does not need all of them immediately.
The static site is the public presentation layer.
The full EmDash runtime is the next layer once you need:
- non-technical editors working in a browser
- authenticated contributor flows
- runtime-managed media
- richer automation or plugin submission workflows
Editorial rule of thumb
Every page should answer one of these questions clearly:
- What is EmDash?
- Why not WordPress?
- What does this plugin or template do?
- How do I migrate?
- How do I deploy?
- Why is this worth adopting now?
If a page does not answer one of those well, it probably needs tighter scope.