---
url: /learn/markdown-endpoints-vs-ssr-prerendering-edge-middleware
title: "Markdown endpoints versus SSR, prerendering, and edge middleware — Siere Learn"
description: "Four ways to give an agent a complete, structured response — compared on what they change, what they cost, what they can break, and how you prove each one worked."
type: article
language: en
author: Tomislav Mladenov
canonical: https://www.siere.ai/learn/markdown-endpoints-vs-ssr-prerendering-edge-middleware
last_modified: 2026-08-18
aeo_generated: 2026-08-24T15:04:37.425Z
---

# Markdown endpoints versus SSR, prerendering, and edge middleware

Four ways to give an agent a complete, structured response — compared on what they change, what they cost, what they can break, and how you prove each one worked.

AuthorTomislav Mladenov

Technical reviewerTomislav Mladenov

Last verified2026-08-18

Evidence classDocumented behaviour

Audit dimensionFidelity

Licence[CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)

Scope · HTTP content negotiation per RFC 9110; framework rendering modes as documented; Siere middleware behaviour as implemented in @siere.ai/core and @siere.ai/middleware.

Reading is optional. Running the check is the point.
[See what an AI agent receives from your URL](/tools/agent-response-check)

## Four answers to one question

The question is always the same: *when an agent requests this URL, does it receive the complete content?* Four techniques answer it, and they sit at different places in the stack.

- **Server-side rendering (SSR)** — the application produces complete HTML per request. Changes the origin.

- **Prerendering / static generation** — the application produces complete HTML per route at build time. Changes the build.

- **Markdown endpoints** — the site publishes a Markdown representation of each page, either at a parallel URL (`/pricing.md`), a bundle (`/llms-full.txt`), or through HTTP content negotiation on the same URL (`Accept: text/markdown`). Adds a representation.

- **Edge middleware** — code in front of the origin inspects each request and, for recognized agents or clients that ask for Markdown, returns a complete structured representation of the same page; everyone else passes through. Adds a request-time path.

They compose. A server-rendered site can also negotiate Markdown. A prerendered site can sit behind middleware that adds structure. The comparison is not "which one" but "which part of the problem does each one solve, and how do you prove it".

## Side by side

SSR

Prerendering

Markdown endpoints

Edge middleware

What changes

Origin rendering

Build output

An extra representation

Request handling in front of origin

Who benefits

Every client, documented or not

Every client, documented or not

Clients that request Markdown

Recognized agents and Markdown-requesting clients; humans unaffected

Fixes an empty application shell?

Yes

Yes, for listed routes

No — the HTML is unchanged

Yes, for the agent path; the human HTML is unchanged

Human page changes?

Rendering model changes; visible page should not

No

No

No

Cost

Server compute, caching design, TTFB

Build time, route list upkeep

Authoring or generation pipeline, freshness

An extra hop; needs a fidelity check between representations

Main risk

Regressions in a large app

Stale or missing routes

Drift between Markdown and page

Serving something different from the page; classifying by header only

Proof

Source response contains content

Source response contains content

`Accept: text/markdown` returns Markdown; content matches page

Crawler-header request returns equivalent content; `Vary` set correctly

## Content negotiation, precisely

HTTP has always allowed one URL to have several representations, chosen by request headers. [RFC 9110 §12](https://www.rfc-editor.org/rfc/rfc9110#section-12) covers proactive negotiation: the client lists what it accepts (`Accept: text/markdown, text/html;q=0.8`), the server picks, and — this is the part that gets forgotten — the response carries `Vary: Accept` so caches keep the representations apart.

Whether a Markdown representation is offered at the same URL or a parallel one is a design choice. Same-URL negotiation keeps one canonical address; a parallel URL is easier to link and inspect. Either way, the representation must be generated from the *current* page or the *same source*, or it will drift.

On the verification date of this guide, none of the major AI vendors documented sending `Accept: text/markdown`. Markdown negotiation is therefore for the clients that do — coding assistants, agent frameworks, tools, and your own tests — and is not, by itself, a fix for what a crawler receives when it sends an ordinary request.

## What edge middleware actually does

Middleware runs before the origin answers. A delivery layer of this kind, in front of a client-rendered application, does the following on each request:

- **Skips what it must not touch.** Discovery files (`robots.txt`, `sitemap.xml`), static assets and API routes pass through unchanged.

- **Classifies the request.** By User-Agent against a maintained registry of documented crawlers, or by `Accept` header if the client asks for Markdown. Classification by header is a claim about the request, not a verified identity; the delivery strategy decides how much to trust it — observe only, negotiate Markdown only, serve recognized agents, or serve verified agents only ([more on identity](/learn/recognized-vs-verified-crawler-identity)).

- **Serves a complete representation.** Either a transformation of the page's own content, or a reviewed, structured document for that route. It is sent with `Content-Type: text/markdown` and `Vary` set so caches do not mix it with HTML.

- **Passes everyone else through.** Ordinary visitors get the ordinary page from the origin.

- **Reports what it did.** Response headers state the strategy, the action taken and the reason, so a request in your logs can be explained.

The property that separates a trustworthy version of this from a risky one is a **fidelity check**: the representation served to agents must be equivalent to what the page says. Otherwise the middleware becomes a way to show crawlers a different site, which is both a policy problem on search platforms and a credibility problem with the people who compare the two.

## Proving each one worked

The proof is the same shape for all four — a request, its response, and a comparison — but the numbers to look at differ.

`URL=https://example.com/pricing
UA="Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot"

# SSR / prerendering: content is in the ordinary source response
curl -sL "$URL" | sed 's/<[^>]*>//g' | tr -s ' \n' | wc -w

# Markdown endpoint: negotiation returns Markdown and the cache is told about it
curl -sI -H "Accept: text/markdown" "$URL" | grep -iE "^content-type|^vary"

# Edge middleware: crawler-header request returns equivalent content
curl -sL -A "$UA" "$URL" | head -40
`
Then compare title, canonical, visible words and links between the ordinary response and the agent-path response. The free audit does exactly this under **Fidelity**: it sends documented crawler headers, compares canonical, title, normalized word overlap, missing links and redirect destination against the ordinary response, and marks a material mismatch as a failure. That comparison is what turns "we added middleware" into evidence.

## Recommendation

- Routes you control and can re-render: prefer SSR or prerendering. Every client benefits and there is no second representation to keep honest.

- Routes you cannot re-render, or where a structured representation adds real value beyond HTML: a request-time path with a fidelity check, verified with the same comparison.

- Markdown negotiation: publish it if you have a reliable source for it; do not mistake it for crawler coverage.

- Whatever you choose: run the comparison after each deployment. All four techniques regress quietly.

## What this proves

- The four approaches solve different parts of the problem and can be combined; none of them is a substitute for verifying the actual response.
- A request-time agent path can be checked deterministically: same URL, different documented request, compare the two responses.

## What this does not prove

- That AI vendors send Accept: text/markdown today; a Markdown endpoint helps agents and tools that ask for it and does nothing for those that do not.
- That serving a different representation to a recognized crawler is free of policy risk on every platform; check the platform's guidelines for your case.

## Reproduce it yourself

- curl -sI https://example.com/page — record Content-Type and Vary.
- curl -s -H 'Accept: text/markdown' https://example.com/page — see whether a Markdown representation is negotiated.
- curl -s -A 'GPTBot/1.0' https://example.com/page and compare title, canonical, visible text and links with the ordinary response.
- Run the free audit; Fidelity compares the ordinary and simulated-agent responses on exactly those fields.

## Sources

- [RFC 9110 — HTTP Semantics, §12 Content Negotiation](https://www.rfc-editor.org/rfc/rfc9110#section-12) — IETF, accessed 2026-08-18
- [Google Search Central — Dynamic rendering as a workaround](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering) — Google, accessed 2026-08-18
- [Next.js — Middleware (proxy)](https://nextjs.org/docs/app/api-reference/file-conventions/proxy) — Vercel, accessed 2026-08-18
- [Siere — Documentation: installing the middleware and adapters](https://www.siere.ai/docs) — Siere, accessed 2026-08-18

## Change history

- 2026-08-18First published.

## Related guides

- [React, Vue, Angular: making client-rendered content agent-readable Framework-specific options for giving crawlers a complete response — server rendering, static generation, prerendering and a request-time agent path — with the trade-offs of each and how to verify the result.](/learn/react-vue-angular-agent-readable)
- [Is llms.txt enough? Discovery versus delivery llms.txt tells an agent where to look. It does not change what the agent receives when it gets there. This guide separates the two problems and shows how each is checked.](/learn/is-llms-txt-enough)
- [Recognized crawler versus verified crawler identity A User-Agent string is a claim, not proof. This guide explains the difference between recognizing a crawler and verifying it, which vendors publish verification methods, and why the audit labels every request with an evidence level.](/learn/recognized-vs-verified-crawler-identity)

[← React, Vue, Angular: making client-rendered content agent-readable](/learn/react-vue-angular-agent-readable)[Recognized crawler versus verified crawler identity →](/learn/recognized-vs-verified-crawler-identity)

See what a recognized agent receives from your own URL.
[See what an AI agent receives from your URL](/tools/agent-response-check)

## Structured Data

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.siere.ai/#organization",
  "name": "Siere",
  "url": "https://www.siere.ai/",
  "logo": "https://www.siere.ai/social-square.png",
  "sameAs": [],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer support",
    "email": "contact@siere.ai",
    "url": "https://www.siere.ai/contact"
  }
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://www.siere.ai/#website",
  "name": "Siere",
  "url": "https://www.siere.ai/",
  "description": "Your website is invisible to AI agents. Siere fixes that. We make your site readable, structured, and optimized for the next generation of AI-powered search.",
  "publisher": {
    "@type": "Organization",
    "name": "Siere",
    "@id": "https://www.siere.ai/#organization"
  }
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "@id": "https://www.siere.ai/#software",
  "name": "Agent Experience Optimization",
  "url": "https://www.siere.ai/",
  "description": "Your website is invisible to AI agents. Siere fixes that. We make your site readable, structured, and optimized for the next generation of AI-powered search.",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": [
    {
      "@type": "Offer",
      "price": "0",
      "priceCurrency": "USD",
      "name": "Starter"
    },
    {
      "@type": "Offer",
      "price": "99",
      "priceCurrency": "USD",
      "name": "Pro"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "@id": "https://www.siere.ai/#faq",
  "url": "https://www.siere.ai/",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is Agent Experience Optimization?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "AEO makes your website readable, structured, and reliably citable by AI agents like ChatGPT, Claude, Perplexity, and Gemini. Most modern websites are JavaScript-rendered and look like blank pages to AI crawlers — Siere fixes that without changing your visitor experience."
      }
    },
    {
      "@type": "Question",
      "name": "How does Siere work?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Siere sits between your server and incoming requests. When an AI agent visits, Siere serves an optimized markdown version of your content. When a human visits, your normal page is served unchanged."
      }
    },
    {
      "@type": "Question",
      "name": "Do I need to change my site?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Siere installs as middleware. There are no content changes or rewrites required."
      }
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Markdown endpoints versus SSR, prerendering, and edge middleware",
  "description": "Four ways to give an agent a complete, structured response — compared on what they change, what they cost, what they can break, and how you prove each one worked.",
  "url": "https://www.siere.ai/learn/markdown-endpoints-vs-ssr-prerendering-edge-middleware",
  "mainEntityOfPage": "https://www.siere.ai/learn/markdown-endpoints-vs-ssr-prerendering-edge-middleware",
  "dateModified": "2026-08-18",
  "author": {
    "@type": "Person",
    "name": "Tomislav Mladenov"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Siere",
    "url": "https://www.siere.ai/"
  },
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "isAccessibleForFree": true,
  "keywords": "Markdown endpoint, Accept: text/markdown, SSR, prerendering, edge middleware, content negotiation",
  "citation": [
    "https://www.rfc-editor.org/rfc/rfc9110#section-12",
    "https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering",
    "https://nextjs.org/docs/app/api-reference/file-conventions/proxy",
    "https://www.siere.ai/docs"
  ]
}
```