Structural SEO is the practice of making a page’s meaning explicit through hierarchy, internal links, and structured data. In Framer, that means going beyond title tags and meta descriptions by using JSON-LD to describe what a post is, who wrote it, how it fits into the site, and which questions it answers.
Meta tags help Google preview a page. Structured data helps Google understand the page. Those are related jobs, but they are not the same job.
Why JSON-LD matters in a Framer site
Google recommends JSON-LD for structured data when a site setup allows it because it is usually easier to implement and maintain at scale. For Framer sites, that matters because the visual editor can make pages look polished while the underlying content relationships remain thin.
A blog post should not only say “this is an article.” It should identify the author, publication date, modified date, headline, image, canonical URL, and sometimes breadcrumbs or FAQs. That extra layer gives search engines a cleaner map of the content.
The structure Google can understand
For a technical blog post in Framer, these schema types are usually the most useful:
- Article or BlogPosting, for the post itself.
- BreadcrumbList, for the page’s place inside the site.
- FAQPage, when the article includes visible question-and-answer content.
- HowTo, when the article teaches a clear sequence of steps.
- Person, for the author entity behind the site.
Do not add schema just because it exists. Add it when the structured data matches visible content on the page. If the FAQ is not visible to users, it should not be hidden in JSON-LD like a little SEO costume.
A basic Article schema for Framer
A simple Article schema can be added as custom code in the page head or injected through a component pattern, depending on your Framer setup.
<script type="application/ld+json">
{"@context": "https://schema.org","@type": "BlogPosting","headline": "Structural SEO: JSON-LD in Framer Beyond Meta Tags","description": "How to use JSON-LD in Framer to help Google understand your article structure.","author": {"@type": "Person","name": "Josue Somarribas","url": "https://josuesomarribas.com"},"datePublished": "2026-06-08","dateModified": "2026-06-08","mainEntityOfPage": {"@type": "WebPage","@id": "https://josuesomarribas.com/blog/structural-seo-json-ld-framer"}
}
</script>This does not replace good headings, useful content, or internal links. It supports them. Structured data is a label on a well-built shelf, not the shelf itself.
Dynamic structured data for CMS posts
The stronger pattern is to connect schema values to CMS fields: title, description, slug, date, image, category, and author. That keeps your schema aligned with the page as your content library grows.
For a Framer CMS blog, the target model should look like this:
- The post title becomes
headline. - The excerpt or description becomes
description. - The cover image becomes
image. - The author stays consistent as a
Personentity. - The slug builds the canonical
mainEntityOfPageURL. - The category can inform breadcrumbs and internal linking.
If you update the title in the CMS but forget to update JSON-LD manually, you create mismatched signals. Dynamic values reduce that risk.
Breadcrumbs are underrated
Breadcrumb schema is useful because it explains where the article sits inside the site. For a portfolio blog, that might be Home, Blog, SEO, then the article title.
{"@context": "https://schema.org","@type": "BreadcrumbList","itemListElement": [{"@type": "ListItem","position": 1,"name": "Home","item": "https://josuesomarribas.com"},{"@type": "ListItem","position": 2,"name": "Blog","item": "https://josuesomarribas.com/blog"},{"@type": "ListItem","position": 3,"name": "SEO","item": "https://josuesomarribas.com/blog?category=seo"}]
}This is structural SEO in a very literal sense. You are telling the crawler how the content shelf is organized.
JSON-LD for AI search and GEO
Generative search systems still depend heavily on retrievable, well-structured content. JSON-LD alone will not make an article quotable, but it helps define entities and relationships more clearly. For GEO, the bigger win is combining schema with self-contained answers, precise headings, definitions, and internal links.
A sentence like “JSON-LD is a structured data format used to describe page entities in machine-readable form” is easier to extract than a poetic paragraph about visibility. Poetry can stay home for this one.
A practical Framer schema checklist
- Add Article or BlogPosting schema to every serious blog post.
- Use BreadcrumbList for blog hierarchy.
- Use FAQPage only when the questions and answers are visible in the article.
- Keep schema values aligned with CMS fields.
- Validate the output with Google’s Rich Results Test.
- Do not mark up content that users cannot see.
- Update
dateModifiedwhen a post is materially changed.
The practical answer
Framer can look excellent while still being structurally vague. JSON-LD fixes part of that by giving search engines a clearer description of your content hierarchy.
Start with Article schema, add breadcrumbs, connect values to CMS fields where possible, and validate before publishing. That is the difference between decorating a post for SEO and actually explaining what it is.
Where to add JSON-LD in Framer
Framer gives you two practical routes. The visual Structured Data field is convenient when the markup is simple and maps cleanly to CMS values. Custom code in the document head gives you full control when the graph has several entities, locale-specific values, or relationships the visual panel cannot express.
Whichever route you use, inspect the live page rather than trusting Preview. The generated script must contain valid JSON, absolute URLs, the final canonical URL, and values that match what visitors can see. Template syntax, escaping, and trailing commas are the common failure points.
A reusable BlogPosting shape
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Article title",
"description": "Article description",
"datePublished": "2026-06-10",
"dateModified": "2026-06-10",
"mainEntityOfPage": "https://example.com/blog/article",
"author": { "@type": "Person", "name": "Author name" },
"publisher": { "@type": "Organization", "name": "Site name" }
}Treat this as a shape, not something to paste blindly. Add an image only when the URL is public and representative. Use a Person publisher for a personal site when that reflects reality. Schema should describe the page you actually published.
llms.txt is a directory, not a ranking switch
An llms.txt file can offer AI-oriented tools a clean list of important resources and short descriptions. It can be useful documentation, especially for a content-heavy site, but it is neither an access-control standard nor a replacement for crawlable HTML, internal links, sitemaps, or structured data.
Keep it small and intentional: identify the site, list canonical pillar pages, and link to useful machine-readable resources. Do not dump the whole sitemap into a second file. If the main pages are vague or inaccessible, an immaculate llms.txt will not rescue them.
Make the article itself machine-readable
Structured data works best when the visible writing is structured too. Start with one clear question, answer it early, use headings that describe real subproblems, and include concrete examples. Make authorship and update dates obvious. Link related claims to supporting pages.
This is not about flattening every article into robotic FAQ copy. It is about reducing ambiguity. A reader and a retrieval system should both be able to identify the main claim, the evidence behind it, and where the answer changes under different conditions.
Validation before publication
- Open the production URL and inspect the rendered JSON-LD.
- Run it through Google Rich Results Test and Schema.org Validator.
- Confirm the canonical, dates, author, image, and breadcrumbs match the page.
- Check the URL appears once in the sitemap and is internally linked.
- Keep
llms.txtfocused on canonical resources rather than every archive URL.
