What is a Spatial CMS?

The problem with coordinates in a CMS

Every modern headless CMS can store a latitude and a longitude. Contentful has a Location field. Sanity has a Geopoint type. Strapi lets you add a custom JSON field with coordinates. Directus even shows your content on a Leaflet map.

But storing coordinates is not the same as understanding geography.

When you add a Location field to a content type in a conventional CMS, you get a pair of numbers attached to your content item. You can display them on a map widget. You can render them in a frontend. What you cannot do is ask the CMS a simple question: "What content is within 5 kilometres of this point?"

That question requires a spatial query — a database operation that understands distance, containment, proximity, and geometry. No mainstream headless CMS supports this natively. If you need that capability today, you have three options: write raw SQL against your CMS database (bypassing its API entirely), add an external geospatial service like Elasticsearch or Algolia with geo-filtering, or build a custom layer between your CMS and your application.

All three options are workarounds. They exist because the CMS was not designed with geography in mind.

Defining the Spatial CMS

A Spatial CMS is a content management system where geographic location is a first-class architectural concept — not a field type, not a plugin, not an afterthought.

In a Spatial CMS:

• Location is part of the architecture, not a field on a form. Content items don't just have coordinates — they exist at a location in both a content hierarchy and on a geographic map simultaneously.
• Spatial queries are native. You can find content near a point, within a bounding box, along a route, or within a polygon — through the CMS API, not by bypassing it.
• Geography informs content relationships. Two pieces of content that are geographically close can be related by the platform itself, not by manual tagging.
• The admin interface is spatial. You see your content where it lives — on a map — not in a table or a spreadsheet.

This is a fundamentally different design philosophy from adding a map widget to an existing CMS. It is the difference between a word processor that can embed images and a design tool that is built around a canvas.

Who needs a Spatial CMS?

Not everyone. If your content has no geographic dimension — if you are publishing blog posts, documentation, or marketing pages — a conventional headless CMS is the right tool. Do not add geographic complexity where none is needed.

But if your content lives somewhere in the physical world, you have probably felt the friction. Consider these use cases:

• Tourism platforms. A city guide where every restaurant, museum, beach, and walking route has a location. Users expect to search by "near me" or "within this neighbourhood." The CMS should support that query natively.
• Real estate portals. Listings exist at addresses. Buyers search within areas, along transit routes, within school districts. Geography is not a nice-to-have — it is the primary search dimension.
• Local news and city guides. Stories are tagged to streets, districts, landmarks. "What happened near me?" is a question readers ask. The content should be queryable that way.
• Outdoor recreation. Trails, climbing areas, dive sites, ski resorts. Every piece of content has coordinates, elevation, proximity to facilities. A flat content tree cannot model this.
• Retail and hospitality. Multi-location businesses with store locators, menus per location, events per venue. Each location is both a node in the business hierarchy and a point on a map.
• Smart city and civic technology. Municipal data — transit stops, parks, public services — that citizens need to find by proximity. Open data enriched with editorial content.

The common thread: content that has an address. Content that users want to find based on where it is, not just what it is.

The dual role of Location

In a conventional CMS, content structure and geography are separate concerns. You have a content tree (folders, categories, parent-child relationships) and, separately, you might have coordinates attached to some items. These two systems do not talk to each other.

A Spatial CMS unifies them. The Location concept serves two roles simultaneously:

• It is the node in the content tree — defining where content sits in the hierarchy (Site > Section > Page).
• It is the geographic position — defining where content sits on the planet (latitude, longitude, and potentially elevation).

This means you can query your content both ways: "Show me all restaurants under the Helsinki section" (tree query) and "Show me all restaurants within 2 km of the central railway station" (spatial query). Same content, two access patterns, one Location concept.

Spatial queries: what they actually look like

The value of a Spatial CMS becomes concrete when you see the queries it enables. Here are the primary spatial query types:

• Proximity query: Find all content within N kilometres of a point. "What restaurants are within walking distance of this hotel?"
• Bounding box query: Find all content within a rectangular area. "What's visible on this map viewport?"
• Polygon containment: Find all content within an arbitrary shape. "What's inside this neighbourhood boundary?"
• Route-based query: Find all content along a path. "What points of interest are near this walking route?"
• Cluster query: Group nearby content into clusters based on zoom level. "Show me a heat map of content density, not individual pins."

In a GraphQL-first Spatial CMS, a proximity query looks like this:

query NearbyContent {
  contentNear(lat: 60.17, lng: 24.94, radiusKm: 5) {
    item {
      name
      contentType { identifier }
    }
    location {
      latitude
      longitude
    }
    distanceKm
  }
}

This is not a text search filtered by city name. It is a real spatial query that computes geometric distance at the database level, returns results sorted by proximity, and includes the exact distance in the response.

A new generation of content management

The Spatial CMS represents something bigger than adding maps to a CMS. It is a new generation of content management tool built around two priorities: locations first, content second.

This inversion matters. In a conventional CMS, you create content and optionally attach coordinates. In a Spatial CMS, the location already exists — it is the starting point. You enrich it with content. The geography is the skeleton. Your words, photos, reviews, and metadata are the flesh.

This shift adds value to any content that is geographically significant. But where it truly shines is in the hyperlocal — the scale of a neighbourhood, a town, an island.

The hyperlocal example: building an island guide

Imagine you are building a guide for the island of Ibiza. Not a tourism brochure — a living, breathing local guide that knows every beach, every restaurant, every club, every hiking trail, every market, every sunset viewpoint on the island.

With a Spatial CMS, you start by importing anchor data — the geographic skeleton of the island. A trusted source like OpenStreetMap or a government geodata portal gives you every named location on Ibiza as GeoJSON: beaches, villages, roads, landmarks, points of interest. Each one arrives with coordinates, a name, and basic metadata. This is your foundation — hundreds or thousands of locations, already correctly positioned on the map, ready to go.

Now the enrichment begins. Local business owners add their venues: a beach bar at Cala Conta, a boutique hotel in Dalt Vila, a dive school at Portinatx. They upload photos, write descriptions, add opening hours. A club promoter posts event teasers for the weekend. A food blogger writes reviews. Visitors share their own photos and tips. Each contribution attaches to an existing anchor location — no one needs to type coordinates or place a pin. The geography was there before the content.

The result: a guide where you can ask "What's happening near Sant Antoni this Saturday night?" and get a real answer — clubs, beach parties, restaurants with live music — all within walking distance, all current, all contributed by the people who know.

Don't duplicate. Aggregate and enrich.

Here is where a Spatial CMS differs from a traditional all-in-one platform. The philosophy is not to store everything in one place. It is to store only what you need to in the Spatial CMS — the geographic layer, the editorial enrichments, the metadata that makes your content discoverable — and let your core data live in your main systems.

A restaurant's menu and reservation system stays in their own software. An event calendar stays in the event management platform. Opening times stay in Google Business Profile or wherever they are already maintained. The Spatial CMS does not duplicate this data. It aggregates and enriches it.

What the Spatial CMS adds is the connective tissue: the geographic context, the proximity relationships, the topical metadata, and the rich structured data that makes all of this discoverable. It is the layer that says "this beach bar is 200 metres from Cala Conta, it is open for sunset drinks, and three clubs are within a 10-minute walk."

This is a fundamentally different approach from building yet another database of business listings. You are not competing with Google Maps. You are adding a layer of local knowledge, editorial quality, and topical richness that no automated system can produce.

Discoverable by chatbots, LLMs, and advanced search

Content that exists only on a website is invisible to half the internet. Today, people find information through chatbots, AI assistants, voice search, and large language models as much as through traditional search engines. If your content is not structured for these systems, it does not exist for a growing share of your potential audience.

A Spatial CMS produces content that is natively discoverable by these systems. Every content item carries rich metadata: geographic coordinates, content type, relationships to nearby locations, topical tags, structured descriptions. This metadata is served as JSON-LD, through GraphQL, via llms.txt, and through AI-friendly content formatting.

When someone asks a chatbot "Where should I go for sunset drinks in Ibiza?", the answer should come from your content — because your content is the most structured, the most geographically precise, and the most topically rich source available. The Spatial CMS ensures this by making every piece of content machine-readable by default, not as an afterthought.

Help your users be discoverable with minimum effort

The real value of a Spatial CMS is what it does for the people who contribute content. A bar owner in San Antonio should not need to understand SEO, structured data, or AI discoverability. They should add their venue, upload a photo, write a sentence about what makes them special, and the platform handles the rest.

The Spatial CMS automatically generates the structured data that makes that venue discoverable. It attaches geographic context — nearby beaches, nearby clubs, nearby hotels. It adds topical metadata — "sunset bar", "cocktails", "live DJ on weekends." It ensures that when a potential customer asks an AI assistant "What's the best sunset bar near Cala Conta?", this venue appears in the answer — with accurate information, up-to-date details, and suggestions about what else is nearby.

For club seekers: "Three clubs within 500 metres, all open tonight." For families: "This beach is shallow, there's a restaurant with a kids' menu 100 metres away." For hikers: "This trail starts at the car park behind the church, and there's a café at the endpoint." The proximity is not manually curated — it is computed from the geography. The content is enriched by locals. The discoverability is automatic.

The role of embeddings and vector search

Location is one dimension of similarity. But content can also be similar in meaning — two articles about street food in different towns, or two dive sites with similar marine life and difficulty level.

A Spatial CMS enhanced with vector search can combine geographic proximity with semantic similarity. "Find content that is near this point AND semantically related to this topic." A club seeker near Playa d'en Bossa gets nightlife recommendations. A foodie in Santa Eulalia gets restaurant suggestions. Same query mechanism, different content — because the embeddings understand what each piece of content is about, not just where it is.

Vector embeddings also unearth hidden connections in your content repository — relationships between content items that no one explicitly tagged, but that exist in the semantic space of the content itself. A quiet beach cove and a yoga retreat three kilometres apart, connected not by a road but by the kind of visitor who seeks both.

Why now?

Three things have changed that make the Spatial CMS category viable — and necessary — today:

• Spatial databases matured. PostgreSQL with spatial extensions handles geographic queries at production scale. You no longer need a specialised GIS stack.
• Vector search became native. Embedding search runs inside your database. Semantic similarity no longer requires a separate vector database service.
• AI needs structured, locatable content. Chatbots, AI assistants, and advanced search algorithms need content that is machine-readable, geographically addressable, and semantically indexed. A Spatial CMS produces exactly this — and makes your users' businesses discoverable to the systems that increasingly drive real-world decisions.

The category is emerging because the infrastructure caught up with the need. The question is no longer "can we build a CMS with spatial queries?" but "why haven't we?"

What's next

We are building Islets — the first purpose-built Spatial CMS. Geography is not a plugin we added. It is the reason the project exists.

If your content lives somewhere — whether that's an island, a city, a national park, or a chain of restaurants across a continent — we'd like to hear from you. Join the waitlist for early access.