I Added Real Playable Demo Maps to RPGMapEditor.com
I’m building RPG Map Editor, a browser-based map editor for tabletop RPGs, D&D sessions, Roll20 maps, and Foundry VTT workflows.
One of the biggest problems with creative SaaS landing pages is that they usually show fake proof.
You get a shiny hero section, some screenshots, a few feature cards, and a call-to-action.
But if you are building a tool for Dungeon Masters, game masters, or worldbuilders, screenshots are not enough.
People want to know:
- Can I open a real map?
- Can I edit it?
- Can I export something useful?
- Is this actually a product, or just a pretty landing page?
- Does it work before I sign up?
So I added real playable demo maps directly to the RPGMapEditor.com homepage.
But there was a catch.
I wanted users and crawlers to see real product proof, but I did not want Google indexing a bunch of thin /demo/* editor shell pages.
So the final architecture became:
Make the homepage indexable. Make the demos playable. Keep the editor utility routes noindex.
This is how I built it.
The product problem
RPGMapEditor.com is meant to be a lightweight browser-based alternative for creating RPG and D&D battle maps without installing a desktop app.
The target user is someone who wants to quickly create a usable session map, export it, and use it in a tabletop workflow.
That means the landing page cannot only say:
“Create beautiful RPG maps.”
It has to prove it.
So instead of only showing static marketing screenshots, I wanted the homepage to show real demo projects:
- A top-down encounter map
- A multi-room map
- An entity playground
- Real
.rpgmap.jsonfiles - Real editor links
- Real preview images
- Real export workflow copy
The homepage needed to become product proof, not just product description.
The SEO problem
The naive version would be simple:
/demo/typical-topdown
/demo/multi-room-world
/demo/entity-playground
Each page would load the editor and let users try a map.
That works for users.
But it is bad for search.
Those pages are mostly utility routes. They are not strong landing pages. They are not meant to rank for searches like:
D&D battle map maker
browser RPG map editor
Roll20 battle map export
Foundry VTT map tool
online tabletop map maker
The homepage and dedicated landing pages should target those searches.
The demo routes should support conversion, not compete in search results.
So the rule became:
/ -> indexable product page
/battle-map-maker -> indexable intent page
/roll20-battle-map-export -> indexable workflow page
/foundry-vtt-battle-map-export -> indexable workflow page
/demo/* -> playable, but noindex
That keeps the site focused.
The architecture
The whole demo system is driven by one manifest file:
`map-editor/public/demo-projects/manifest.json
That manifest is the source of truth for:
Homepage demo cards
Editor boot config
Demo route resolution
Preview images
JSON-LD structured data
Internal validation
Product copy for each demo
The key principle is simple:
If the marketing page says a demo exists, the editor must actually be able to load it.
No fake screenshots.
No stale copy.
No card that says “open in editor” and then breaks.
Example manifest entry
A demo project entry looks roughly like this:
{
"slug": "typical-topdown",
"title": "Top-Down Encounter Sample",
"description": "A small editable battle map designed for a quick tabletop encounter.",
"intent": "Use this to test terrain, props, grid alignment, and PNG export.",
"projectUrl": "/demo-projects/typical-topdown.rpgmap.json",
"previewUrl": "/demo-projects/typical-topdown.webp",
"demoUrl": "/demo/typical-topdown",
"width": 32,
"height": 24,
"grid": "square"
}
This gives the homepage everything it needs:
A readable title
A useful description
A preview image
A real project file
A playable editor URL
Grid metadata
Search-friendly text
Structured data fields
The demo card and the editor both come from the same data.
That matters because marketing drift is real.
It is very easy for a landing page to say one thing while the actual product does another.
Server-side validation
The Rust server validates the demo manifest before rendering the homepage.
The validation checks that:
The manifest version is valid
Slugs are unique
Demo URLs are same-origin
Preview images exist
Project files exist
Project JSON parses correctly
Demo projects do not depend on remote http(s) asset URLs
That last point is important.
A demo map should not silently depend on a remote image or tileset that can disappear later.
For RPGMapEditor.com, demo projects need to be self-contained so they load quickly and reliably.
If validation fails, the homepage does not advertise broken demo cards.
That is better than showing “Open in editor” and sending users into a dead route.
Server-rendered proof cards
The homepage renders demo projects as real HTML.
Not a JavaScript-only carousel.
Not a hidden JSON blob.
Not an empty
that only appears after hydration.
Real server-rendered cards.
Example:
`
Start from a real encounter
src=”/demo-projects/typical-topdown.webp”
alt=”Top-Down Encounter Sample editable demo battle map preview”
width=”1200″
height=”800″
loading=”lazy”
decoding=”async”
>
<h3>Top-Down Encounter Sample</h3>
<p>A small editable battle map designed for a quick tabletop encounter.</p>
<p>32 × 24 square grid</p>
<a href="/demo/typical-topdown">Open in editor</a>
`
This gives both users and search engines actual proof:
RPGMapEditor.com has real demo maps
The maps are editable
The links are visible
The previews have descriptive alt text
The product is not just a mockup
That matters for a new SaaS.
A new product has no trust by default.
The fastest way to earn trust is to let people try something real.
The demo routes are playable, but noindex
Each demo link opens the real editor.
For example:
https://www.rpgmapeditor.com/demo/typical-topdown
The server resolves the slug against the manifest and injects a boot config:
window.RPGME_EDITOR_BOOT = {
mode: "demo",
projectUrl: "/demo-projects/typical-topdown.rpgmap.json",
copyApiUrl: "/api/demo-projects/typical-topdown/copy",
signupNextUrl: "/signup?next=/demo/typical-topdown"
};
But the demo route also includes:
<meta name="robots" content="noindex, nofollow">
That is intentional.
The demo route exists for product experience.
The homepage exists for search.
The journey is:
Google / Dev.to / social post
↓
RPGMapEditor.com homepage
↓
Demo card
↓
Open real editor
↓
Try map
↓
Export / sign up / copy project
The demo page helps conversion.
It does not need to rank.
Structured data mirrors the visible page
The homepage also outputs JSON-LD structured data.
The important part is that the structured data is generated from the same manifest as the visible demo cards.
Example:
{
“@context“: “https://schema.org“,
“@type”: “ItemList”,
“itemListElement”: [
{
“@type”: “ListItem”,
“position”: 1,
“name”: “Top-Down Encounter Sample”,
“url”: “https://www.rpgmapeditor.com/demo/typical-topdown“
}
]
}
There is also FAQ schema generated from visible FAQ content on the page.
The rule is:
Structured data should describe what users can actually see.
If the manifest fails and demo cards are not rendered, the ItemList schema is not rendered either.
No fake schema.
No invisible SEO content.
No pretending the page contains things it does not.
Performance choices
The homepage also has a visual hero section, but I did not want it to destroy performance.
The hero uses:
A static WebP poster
fetchpriority=”high”
Preload for important visual assets
Optional Three.js overlay
Motion preference checks
Desktop viewport checks
IntersectionObserver before loading heavy JavaScript
The demo preview images are lazy-loaded below the fold.
Heavy animation is deferred.
The homepage should still make sense before JavaScript loads.
This matters because technical SEO is not only meta tags.
If the page is slow, unstable, or blank until JavaScript runs, the implementation is weak.
Why this matters for RPGMapEditor.com
For a new map editor, the hard part is not only building tools.
The hard part is proving that the product deserves attention in a crowded space.
There are already established tools for tabletop maps.
So RPGMapEditor.com needs to show its positioning clearly:
Browser-based
No desktop install required
Real editable demo maps
Fast try-before-signup flow
Useful for D&D and tabletop sessions
PNG workflow for Roll20 and Foundry VTT
Honest about what is shipped and what is not
The demo maps are not just a nice visual section.
They are part of the product strategy.
They reduce the gap between:
“This looks interesting.”
And:
“I opened a real map and tested it.”
That gap is where most SaaS landing pages lose users.
The reusable pattern
This architecture is not only useful for website.
You can use the same pattern for any creative SaaS product:
Browser editors
Diagram tools
Design tools
Code playgrounds
Game tools
Image tools
Website builders
Workflow builders
The pattern is:
- Create real example projects
- Store metadata in one manifest
- Validate the manifest server-side
- Render example cards as HTML
- Link examples to real playable routes
- Mark utility routes noindex
- Generate structured data from the same manifest
- Track opens, exports, signups, and conversion
The principle:
Index the proof. Noindex the playground.
What I am watching next
This is still an experiment.
The implementation is technically cleaner, but the business question is whether it converts.
The metrics that matter are:
Homepage click-through rate to demos
Demo open rate
Demo-to-signup conversion
Export attempts
Returning users
Search impressions for map editor queries
Queries mentioning Roll20, Foundry, D&D, and battle maps
Whether users understand what is shipped today
If people open the demo but do not sign up, the problem may be onboarding.
If people never open the demo, the homepage copy or card placement is weak.
If people sign up but do not export, the editor workflow needs work.
That is the point of building it this way.
The demos are not only SEO content.
They are a product validation loop.
Final thought
I do not think a new creative SaaS product should hide behind polished screenshots.
If the product is real, the landing page should prove it.
For RPGMapEditor.com, that meant putting real demo maps on the homepage, rendering them as crawlable HTML, validating them through a manifest, linking them into the real editor, and keeping the utility editor pages out of the search index.
It is a simple split:
The homepage ranks.
The demo routes convert.
The manifest keeps everything honest.
That is the architecture I would use again.
If you are building a browser-based creative tool, do not just say what it can do.
Let people open something real.
