Framer is a design tool first and a website platform second, and that order shapes its score on this rubric. The checks that matter most for a Framer site are the two that look at the document itself rather than at settings: A7, how much of the visible text is in the raw HTML before any script runs, and B5, how much of that HTML is text rather than wrapper markup. Neither can be answered from a dashboard. Both can be measured in a few minutes, and this post is about how to measure them rather than what to assume.
That is a deliberate choice. Framer's rendering pipeline is the platform's business and the developer documentation is the place to read how it works today. This post will not tell you that Framer sites are, or are not, server-rendered. The two-fetch comparison below tells you that for your site, on the day you run it, with evidence.
What Framer does by default
Framer publishes to its own hosting and, by default, handles the things a hosting layer normally handles: TLS, a generated sitemap, and a robots.txt. Its page settings carry a title, a description and a social image per page, which is most of what check B4 wants, and its text elements let you pick the HTML tag, so a page can carry one h1 and a sensible outline for check B3 if the designer chooses to. Check the current documentation for which landmark and heading tags are available on which element types; that list has grown over time.
The rest of the rubric treats a Framer site like any other, and the questions about custom code, redirects and root files are the same ones covered in the Webflow guide. What is specific to a design-first tool is the shape of the HTML it exports, and that is where the two checks below come in.
The question that decides the score
An agent that reads your site with a plain HTTP fetch gets the raw HTML and nothing else. It does not run your scripts. If the words on the page are present in that document, the agent can read them; if they are inserted by a script after load, the agent sees whatever placeholder the script left behind. The two fetches explains why this is the gap most serious findings live in.
Check A7 measures it directly. The scanner fetches the homepage raw, extracts the visible text with script, style and template contents removed, and compares its length to the visible text of the same page after a headless browser has rendered it. A ratio at or above 0.8 scores five points; between 0.5 and 0.8 scores three; below 0.5 scores zero. The report's A7 evidence carries the three numbers it used, rawTextLength, renderedTextLength and ratio, so the finding is not an opinion about the platform. It is two character counts.
A design tool can land anywhere on that scale. A page whose text is written into the HTML at publish time scores five however much animation runs on top of it, because the scanner counts characters rather than watching motion. A page whose sections are assembled by a script scores zero regardless of the design. Components matter too: a code component that fetches its content, or a carousel populated at runtime, moves text from the raw column to the rendered column.
How to measure it yourself
Run the comparison measuring server-rendered parity sets out. The short version is two fetches and a rough count.
First, the raw fetch. Pull the homepage as a bot would and strip it to visible text:
curl -sA "Mozilla/5.0 (compatible; GPTBot/1.1; +https://openai.com/gptbot)" https://example.com/ \
| sed -e 's/<script[^>]*>[^<]*<\/script>//g' -e 's/<style[^>]*>[^<]*<\/style>//g' -e 's/<[^>]*>/ /g' \
| tr -s ' \n' ' ' \
| wc -c
Then open the same page in a browser and read document.body.innerText.length from the console. That is a rough stand-in for the rendered count; the scanner's own headless render is more careful, but the ratio will be in the same region.
Then read the words, not just the count. Search the raw response for your headline, your pricing figures and the first sentence of your longest paragraph. If they are there, the content is in the document. If the raw response is a short shell with a script tag and a root element, it is not. Repeat this after any structural change and after any platform update that mentions rendering; it takes two minutes.
What B5 sees in a designed page
Check B5 is the clean text ratio: visible text as a proportion of HTML bytes, with the contents of script and style elements excluded from both sides since rubric version 1.0.1. At or above 0.10 scores three points, between 0.05 and 0.10 scores two, and below 0.05 scores one.
Because styles are excluded, the inline CSS a design tool emits does not count against you. What does count is the markup around the text. A layout built as nested containers, each with a long class attribute and a handful of data attributes, produces a page where a short paragraph is wrapped in hundreds of bytes of tags. That is not a Framer problem in particular; it is the natural output of any tool that represents a design as a tree of frames. But it is the reason a visually simple page can carry a low ratio.
The evidence field is averageRatio, with perPage values beside it. If the average is below 0.10, the fixes are in the design rather than in a setting: fewer wrapper frames around text, copy in text elements rather than in images, and sections built from the tool's semantic containers rather than a stack inside a stack inside a stack. Removing a layer of nesting from a component removes it from every page that uses the component, which is the same template-level logic that applies to structured data. Clean text ratio goes through the measure in detail.
Fixes in order of effort
Low effort. Confirm robots.txt and the sitemap in the site settings, fill the title and description on every page, and add alt text to content images. None of these is specific to Framer; all of them are points.
Medium effort. Add Organization JSON-LD in the site-wide custom code with a sameAs array, set the semantic tags on your header, navigation, main content and footer containers, and thin the wrapper structure on the templates with the lowest perPage ratio. B5 is rated Medium on the rubric and it is design work rather than engineering.
High effort. A7 is rated High because when it fails, the fix is architectural. On Framer, first find out whether it fails: run the two fetches. If the ratio is at or above 0.8, there is nothing to do here and the High-effort item on your report is already closed. If it is below 0.5, look at which components are responsible, because a single code component that renders its text client-side can drag the homepage down on its own, and replacing that one component may be the whole fix. Check the current documentation for how code components are rendered at publish time before you rebuild anything.
What is not fixable without leaving the platform
If the two-fetch comparison shows a raw document that is essentially empty, and the current documentation confirms that pages are built in the browser, the platform is the cause and no setting inside it changes the result. That is the case where the design is exported to a static site generator or a framework with server rendering, and the design tool becomes the source of the design rather than the host of the site.
Make that decision from the A7 evidence on a dated scan of your own site, not from a guess. If the numbers are fine, the platform is fine, and the effort belongs on the Medium-effort list above.
Check your own site
Run the free scan and read the A7 evidence before anything else; the three numbers there settle the question this post refuses to answer for you. The definitions for A7 are under discovery and access and for B5 under understanding on the methodology page, and our own report shows what the two fields look like on a site where the raw and rendered counts agree.