FAQ: Akamai Edge SSR — caching, Cache Tester, request flow, and crawl-for-tagging

Yes — with Akamai Edge SSR, Schema App stores and serves pre-generated JSON-LD from Schema App's own data CDN (data.schemaapp.com, AWS CloudFront). That cache is outside your Akamai property cache behaviors. The EdgeWorker does not generate markup at request time, and it does not send your HTML to Schema App for enhancement. It looks up cached JSON-LD and injects it into the HTML for bot requests.

TABLE OF CONTENTS

• Short answer
• Does Cache Tester still show updated markup with SSR?
• Correct request flow (vs. a common misunderstanding)
• What is cached where
• How markup gets into the Schema App cache
• Does Schema App crawl to discover or tag pages?
• What Akamai should and should not cache
• Architecture diagrams
• Related articles

Short answer

Once Schema App has processed a page (via Crawler deployment, Highlighter JS+Caching, or the Editor), the resulting JSON-LD is published to Schema App's Markup Delivery Network at data.schemaapp.com. On each bot request, the Akamai EdgeWorker fetches that cached payload and injects <script type="application/ld+json"> into <head>.

So: yes, Schema App caching exists independently of Akamai cache behaviors.

Does Cache Tester still show updated markup with SSR?

Yes. Admin Cache Tester reads the same Schema App data CDN objects that the Akamai EdgeWorker injects. SSR does not replace or bypass Cache Tester — it depends on those cached objects.

What you should expect:

• Cache Tester Last Modified updates when Schema App regenerates the CDN object (Editor save, Crawler visit, or Highlighter JS+Caching write) — not merely because SSR went live.
• SSR does not refresh markup by itself. After you remove highlight.js from the site, the __highlighter_js (JSCaching) path usually stops updating. Enable Crawler deployment so Schema App writes the main CDN path (typically shown as HighlightCrawl / Crawler source).
• Use the Highlighter JS tickbox deliberately: unticked = main CDN path (Editor / Crawler); ticked = __highlighter_js path (JSCaching from browser visits). Check both when troubleshooting SSR.
• If Cache Tester looks stale, live SSR markup is usually stale too — confirm with a bot User-Agent and look for data-source="SchemaApp-Akamai:…" (and optional X-SchemaApp-EW-Status).

Common post-SSR symptom: JSCaching objects frozen around the go-live date, empty or Editor-only main path, and no HighlightCrawl source. That means generation stopped writing fresh cache — fix Crawler / cache population first, not the EdgeWorker.

Related how-tos: Switching Customers to Server-Side Rendering, Clear Highlighter template markup from the CDN cache, Automated clearing of cached highlighter template markup.

Correct request flow (vs. a common misunderstanding)

1. Schema App provides the EdgeWorker bundle (the executable you upload in Akamai): https://cdn.schemaapp.com/javascript/schemaapp-edgeworker.tgz

2. Correct bot-path flow:

1. A bot requests a page on your Akamai property.
2. Property Manager matches a bot User-Agent and invokes the Schema App EdgeWorker.
3. In parallel, the EdgeWorker: (a) fetches your origin HTML (via an internal subrequest), and (b) fetches pre-cached JSON-LD from Schema App's CDN (data.schemaapp.com) through your Conditional Origin proxy.
4. The EdgeWorker injects any found JSON-LD into <head> and returns the HTML to the bot.
5. If no cached markup exists (or CDN lookup fails), the worker fails open and returns origin HTML unchanged.

Important correction: The EdgeWorker does not pass page HTML to Schema App for live enhancement, and Schema App does not return a rewritten page body to Akamai as an API response. Delivery is lookup + inject of already-cached JSON-LD at the edge.

Human traffic skips the worker when your Property Manager bot rules are configured correctly (zero TTFB impact for real users).

What is cached where

The EdgeWorker is a delivery adapter. It reads from Schema App's cache; it does not run Highlighter live at the edge.

How markup gets into the Schema App cache

1. Author markup in the Editor or Highlighter.
2. For Highlighter, enable Crawler deployment (recommended for SSR) so Schema App's crawler visits pages and populates the CDN.
3. Published markup is available at data.schemaapp.com/{accountId}/{base64PageUrl} (and optionally under __highlighter_js).
4. If a URL has no cached markup, the worker returns origin HTML unchanged.

Does Schema App crawl to discover or tag pages?

Short answer: Defining tags/templates and assigning them to URLs does not require Schema App to pull a full inventory from your internal CMS. Coverage and cache population use public URL access (and patterns you configure), not an integration to internal systems.

Authoring and assignment (no full-site pull required)

• Your team (with Schema App) defines Highlighter templates and pagesets — URL patterns/globs that say which pages get which markup.
• Editor markup is authored for specific URLs.
• You do not need to give Schema App access to internal CMS or content systems for tagging.

When Schema App does crawl the public site

• Highlighter Crawler deployment (recommended with SSR): SchemaBot visits public URLs that match your pagesets on a schedule to generate/refresh cached JSON-LD on data.schemaapp.com. Typical schedules: whole-site about every 7 days; last-modified-in-sitemap about every 4 hours (see allowlist article).
• Analyzer and scoping crawls: optional on-demand public crawls (started with New Site) to assess coverage and find markup opportunities.
• Monitoring crawls: daily public crawls of a subset of URLs to confirm markup is deploying.

How you know you did not miss pages

• Review Highlighter Overview / pageset URL coverage for each template.
• Use Analyzer coverage reports for site-wide structured-data presence.
• After SSR go-live, validate a sample of URLs with a bot User-Agent and look for data-source="SchemaApp-Akamai:…" in HTML source.
• Ensure Schema App's crawler IP / SchemaBot UA is allowlisted so crawls can reach the public site.

Schema App does not integrate to internal origin systems to enumerate "all site content" for tagging. If a page is not in a pageset (or not crawled / not authored), it will not receive Schema App markup via the EdgeWorker.

What Akamai should and should not cache

• Do not cache responses on the Conditional Origin rule that proxies to data.schemaapp.com (set Caching to NO_STORE). Markup freshness is managed on the Schema App side.
• Do include the X-Subrequest header in the cache key for the page behavior so the worker's origin fetch is not confused with the client-facing (injected) HTML.
• Bot vs human routing is controlled by your Property Manager User-Agent rules — not by Schema App's Robots-Only setting (Robots-Only applies to JavaScript deployment only).

Architecture diagrams

Customer-ready data-flow diagrams (bots, humans, and CDN access) live in the Akamai setup guide:

Server Side Rendering — Akamai Setup Instructions (section Data Flow Diagrams).

For CDN-agnostic architecture context, see Edge Rendering: What It Is, Why Use It, and How Schema App Delivers It.

Related articles

• Server Side Rendering — Akamai Setup Instructions
• Edge Rendering: What It Is, Why Use It, and How Schema App Delivers It
• Switching Customers to Server-Side Rendering (CSM)
• Cache Tester
• How-To: Troubleshoot Akamai Integration
• Allowlist Schema App IP Address & Endpoints (crawler uses)
• Creating a Pageset in the Highlighter Extension