Framer CMS SEO: Slugs, Templates and Internal Links That Rank

Framer CMS SEO comes down to four decisions: which field generates the slug, whether every item gets its own meta description, whether related items are driven by a category field or hand-picked, and whether the heading levels inside rich text actually descend. Get those wrong and a 200-item collection ranks like one page.

TL;DR

• Framer builds the slug from the first string field in the collection, at the moment the item is created. Fix your field order before you enter item one.

• Typing a meta description into the collection page instead of binding it to a field gives every item in that collection the same description. This is the single most common Framer SEO mistake I fix.

• Bind the H1 in the template and start rich text bodies at H2. Framer assigns heading tags from the text preset, not from font size.

• Drive related items from a category field, not a hand-picked reference list. Hand-picked links starve every new item you publish.

• If a collection needs two template layouts or serves two search intents, it is two collections.

Slugs are written once, from the first string field

Framer CMS generates the slug from the first string field in the collection. Not from a field named “Slug”. Not from the field you mentally think of as the title. The first string field in the field order, as that order exists when the item is created.

So if your collection opens with an “Internal name” field, or “Short label”, or “Card heading”, that is what becomes the URL. I have opened sites where every blog URL was derived from a two-word admin label because someone dragged the fields around after the first ten items went in.

The slug is written at creation time. It does not rewrite itself when you later edit the title. That is good for stability — you do not want URLs mutating every time an editor polishes a headline — but it is a trap if the first draft of the title was a placeholder.

The rename trap

The sequence goes like this. Someone creates an item called “Untitled post” or “New service page draft”. The slug becomes /blog/untitled-post. Two weeks later the headline is finished, the page publishes, Google indexes it, and the URL still says untitled-post.

You can edit the slug per item. Two problems with relying on that. At sixty items nobody actually does it. And editing a slug that is already live breaks the old URL the moment you publish. Framer has native redirect settings in site settings — use them, one line per changed slug, and do the whole batch in one session rather than dribbling changes out over a month.

Slug rules that survive a 100-item collection

Move the public-facing title to position one before you enter a single item. Write that first title as though it is the URL, because it is. Keep slugs to roughly three to six words. Strip years unless the page is genuinely dated and you intend to maintain it annually. And do not repeat the folder in the slug — /blog/seo/framer-cms-seo-guide-updated-2026 says “SEO” twice and “guide” for nobody.

The template is the SEO surface, not the item

Everything crawlable on a CMS page comes from the template. The item only supplies values. That means every mistake in the template is multiplied by the item count, and every fix is too. This is the good news: one thirty-minute pass on a template repairs 200 URLs.

Bind the H1, don’t just make it big

Framer assigns heading tags from the text preset applied to a layer, not from how large the text looks. A 64px title layer using a body preset ships as a paragraph. Pick the title layer in the template, set the tag to H1 explicitly, and confirm there is exactly one on the page. Nav and footer text set to heading presets will happily give you a second and third H1 across the whole site.

Lock image aspect ratios or CLS will drift

Framer outputs static pages served from a CDN, so the template itself is usually fast. Content is what breaks it. An editor uploads a 4:3 hero into a slot that was designed around 16:9, the layout reflows on load, and CLS drifts past the 0.1 threshold on exactly the pages you care about. Set a fixed aspect ratio on every CMS-bound image layer in the template. LCP under 2.5s and INP under 200ms are mostly a template problem; CLS on CMS pages is almost always an unconstrained image.

One meta description for a whole collection is the mistake I fix most

On a collection page, Framer’s SEO panel accepts a title and a description. You can type static text into those boxes, or you can bind them to CMS fields. Typing static text is faster, looks fine in the editor, and ships sixty pages with byte-identical metadata.

The title tag is the worse half of this. Sixty pages all called “Blog | Company Name” is not a ranking signal, it is a shrug. The description matters less because search engines rewrite snippets often, but identical descriptions across a set also destroy your ability to diagnose anything in Search Console — every row looks the same.

The fields to add

Three fields, added once, at the collection level:

• SEO Title — plain text, optional. When empty, the item title carries it.

• Meta Description — plain text, written to roughly 150-160 characters.

• OG Image — image, so social cards do not fall back to whatever the template picks.

Which binding to use

The fourth row is what I ship by default. A field that is always filled beats a dedicated field that is blank on half the items.

Excerpts do two jobs at once

The excerpt is card copy and it is your description fallback. Those two jobs want different lengths. Cards look tidy at 90-120 characters. Descriptions want 150-160.

Write to the longer number and constrain the card visually — fixed height, clipped overflow — rather than shortening the text and starving the metadata. If your card design cannot clip cleanly, use two fields and accept the extra editorial step.

Three rules for the copy itself. Front-load the specific noun a searcher would type. Never open with “In this article”. And do not restate the title verbatim, because the title is already sitting directly above it in the result.

Related items: category-driven, not hand-picked

The default instinct is a multi-reference field where an editor picks three related posts. It reads well in a spec. It fails in production for a mechanical reason.

Why hand-picked decays

A hand-picked list is written when the item is created. Every item published afterwards receives zero internal links until somebody goes back and edits the older items. So link equity concentrates on your oldest content and your newest content sits orphaned — which is exactly backwards from what you want.

It is also linear editorial work. Three picks per item, 100 items, and someone re-auditing the whole set every quarter.

The alternative: add a Category field, then build the related list as a collection list filtered to match the current item’s category, sorted by date, limited to three or four, with the current item excluded. Now a new item joins its siblings’ related lists the day it publishes. On a 100-item collection that is 300-400 internal links generated from one component and maintained by nobody.

If your build cannot filter against the current item’s field, fall back to a multi-reference field for the category itself and filter on that. The principle holds either way: the link set should be computed, not typed.

The honest limitation is that category-driven lists are topical, not editorial. If a specific page needs a deliberate “read this next” for a funnel, add one optional single-reference field that overrides the automatic list. That is one field and one condition, not an editorial process.

Make Category a collection, not an option

This is the part most builds skip. An Option field can filter a list. It cannot have a page.

The hub page is the point. Ten items on a topic pointing at each other is a flat mesh. Ten items pointing at a hub, and the hub pointing back at all ten, gives you something with an actual head — a URL that can target the broad term while the items target the specific ones. That extra thirty minutes is the highest-return half hour in a CMS build.

Heading structure inside rich text

The template supplies the H1. So every rich text body must start at H2 and never skip a level. H2 then H3. Never H2 then H4.

Two failure modes show up constantly. The first is a second H1 inside the body, usually pasted in from Google Docs or Notion where the writer’s document heading came along for the ride. The second is the opposite — a body with no headings at all, where every section break is a bold paragraph. Bold text is not a heading. It produces no outline, so a 2,000-word page reads to a crawler as one undifferentiated block.

Neither is fixable with a setting, because Framer has no plugin ecosystem for SEO and no editor-side lint. It is fixed with a one-page contributor note and a crawl. Run the site through any crawler, sort by H1 count, and anything showing 0 or 2+ is your list.

When one collection is doing too many jobs

Signs it has outgrown itself: you need two template layouts and are hiding half the layers conditionally; items serve genuinely different search intents; the field count is past fifteen and a third of them are empty on most items; two different groups of people edit it; the URL pattern makes sense for half the items and reads oddly for the rest.

The working rule is one collection, one URL pattern, one template, one intent.

Splitting after launch is survivable but not free. Every moved item changes URL, so you need a redirect per item before you publish, and you should expect a re-crawl and re-evaluation window afterwards. Any hardcoded links in old body copy will break silently — those are inside rich text, so no redirect map catches them at authoring time.

Don’t over-split either

Three collections of five items each is worse than one collection of fifteen. You triplicate the template work, you fragment the design system, and you lose the ability to render one combined feed — Framer collection lists read from a single collection, so a merged “latest across everything” view stops being straightforward. Split on intent and template, not on tidiness.

When Framer CMS is the wrong tool

I would rather say this now than after an invoice.

Thousands of items. Framer CMS has plan-based item limits per collection. Check yours before planning a programmatic build with five-figure URL counts.

Faceted navigation. Framer has no server-side logic. Filter state lives in client-side interaction, so a filtered view does not get its own crawlable URL unless you build a real page or collection for it. If your ranking strategy depends on indexable filter combinations, this is the wrong platform.

Gated or member-only content. No native membership or gating. Do not design an editorial funnel around it.

Large product catalogs. No WooCommerce, no native commerce logic. Third-party embeds such as Shopify buy buttons work fine for a handful of SKUs, but if the catalog *is* the SEO asset — variants, inventory, product schema at scale — use the commerce platform’s own templates and treat Framer as the marketing layer. That is usually the honest answer on a Shopify migration.

Per-item structured data. This is the fiddliest part of Framer CMS SEO and I will not pretend otherwise. There is no SEO plugin; schema goes in custom code in site or page settings. Binding JSON-LD values to individual CMS fields is not a drag-and-drop feature — in practice it means a small code component or embed that reads the item’s fields. It is doable, it is worth doing for Article and FAQ types, and it takes real time.

Everything above is the work I do on a Framer CMS setup, and it is the first thing I look at during a WordPress to Framer migration, where a 300-post archive usually arrives with three of these five problems at once. Ongoing structural work sits under website SEO; build pricing starts at a flat $1,200 base covering the first page plus all shared work — design system, CMS, redirect map, schema, analytics — then $250 per page for pages 2-10, with the full tiers on pricing.

FAQ

Can I change a Framer CMS slug after publishing?

Yes. Each item has an editable slug field. But the old URL breaks the moment you publish the change, so add a redirect in Framer’s site settings first — one line per changed slug. Expect a re-crawl and re-evaluation window afterwards. Change slugs in a single batch rather than trickling them out over several weeks.

Why do all my Framer CMS pages have the same meta description?

Because the description was typed as static text into the collection page’s SEO panel instead of being bound to a CMS field. Every item then ships identical metadata. Add a plain text meta description field to the collection, or bind the description to your existing excerpt field, and each page gets its own unique description.

How many related items should a Framer CMS page link to?

Three to five. Build it as a collection list filtered by the item’s category field, sorted by date, limited, with the current item excluded. On a 100-item collection that generates 300-500 internal links with no ongoing editorial work, and every new item joins its siblings’ related lists on the day it publishes.

Should the item title be an H1 in the template or in the rich text?

In the template. Bind one text layer to the title field and set its tag to H1. The rich text body then starts at H2. Framer assigns heading tags from the text preset rather than the font size, so a large title layer is not automatically an H1 — open the tag setting and confirm it.

When should I split one Framer CMS collection into two?

When it needs two different template layouts, serves two different search intents, or has more than a third of its fields empty on most items. Splitting after launch changes URLs, so map redirects before publishing. Do not over-split either: three collections of five items triples the template work and cannot share one feed.

If you want a second opinion on a live collection, send me the URL through contact and I will come back inside 48 hours with a crawl summary, a redirect risk list and a fixed quote — free, and no follow-up sequence.