Edge Rendering: What It Is, Why Use It, and How Schema App Delivers It

Edge Rendering is a variant of server side rendering where a CDN edge worker (e,g Akamai EdgeWorkers) modifies the HTML response before it reaches the browser or crawler. In this approach, JSON-LD from Schema App loads in the page source without client-side JavaScript.

This article explains why organizations deploy Schema App markup at the edge instead of with client-side JavaScript, and how Schema App’s edge integrations work end to end. After reading it, you will understand the indexing gap, how edge rendering differs from client-side rendering, Schema App’s delivery pipeline, and where to find setup instructions for your CDN.

TABLE OF CONTENTS

• Context: The Indexing Gap
• Edge-side rendering vs Client-side rendering
• Server-side Rendering vs Client-side Rendering Comparison Chart
• Schema App Technical Design
  • Authoring and cache population
  • Edge request flow
  • Markup lookup and injection
  • Failure behavior
  • Bot vs human traffic
• Benefits of edge rendering
• When to consider edge rendering
• Migrating from JavaScript to Edge SSR
  • Recommended path: Crawler + edge SSR
  • Can I keep JavaScript deployment with SSR?
  • What happens to Robots-Only?
  • Migration checklist
• CDN setup instructions
• Resources
• Conclusion

Context: The Indexing Gap

Schema App supports multiple deployment methods, including client-side JavaScript (highlight.js) and edge or server-side rendering. 

Client-side deployment is efficient and flexible for many sites—minimal CMS change, fast rollout via tag managers. However, not every crawler or AI system reliably executes JavaScript before consuming a page. Some read only the initial HTML response. That creates an indexing gap: markup visible in the browser after JS runs may not be visible to every crawler or LLM bot. As AI-driven discovery grows, delivering JSON-LD in the first HTML response has become a strategic choice for crawl reliability—not a requirement for every site.

Note: Edge rendering is a strategic option. Client-side rendering remains valid where operational simplicity is the priority. See Large Language Models and JavaScript Consumption for LLM-specific guidance.

Edge-side rendering vs Client-side rendering

Edge side rendering is a specific sub-type of server-side rendering where scripts are executed on a global edge server (rather than a traditional server). In the case of Schema App, the resulting JSON-LD content is included in the HTML file sent to the client's browser, rather than rendered in the client's browser (i.e. client side rendering). This article will use the term Edge-side rendering for specificity.

Client-side rendering (CSR)

During Client-side rendering, the browser loads the page, downloads highlight.js, and Schema App injects JSON-LD after JavaScript runs. This is the most common integration path (direct script, tag manager, or self-hosted JS).

• Minimal CMS changes; works well with SPAs and tag managers
• Highlighter can generate markup dynamically on page load
• Crawlers must execute JavaScript to see the markup

Edge-side rendering (SSR at the CDN)

During Edge-side rendering, the CDN edge worker (e.g. a Cloudflare Worker) modifies the HTML response before it reaches the browser or crawler. JSON-LD appears in the page source without client-side JavaScript.

• Markup is in the initial HTML—no JS execution required for crawlers
• Uses cached markup from Schema App’s data CDN (not live Highlighter execution at the edge)
• Requires CDN configuration and staging validation

Schema App edge integrations do not replace authoring or graph generation. They change how already-generated markup is delivered.

Server-side Rendering vs Client-side Rendering Comparison Chart

For performance metrics across integration methods, see Performance Impact of Integration Methods.

Schema App Technical Design

Schema App edge SSR follows the same delivery network as JavaScript deployment. The edge worker is a delivery adapter at your CDN—not a separate authoring path.

Authoring and cache population

1. Author markup in the Schema App Editor (single URLs) or Highlighter (templates).
2. For Highlighter templates, enable Crawler deployment so Schema App’s crawler visits pages and populates the Schema App CDN cache (data.schemaapp.com) without requiring highlight.js on the live site.
3. Markup is stored in Schema App’s graph and published to the Schema App's Markup Delivery Network

Note: Edge workers inject markup that already exists in the data cache. If a URL has no cached markup, the worker returns the origin HTML unchanged.

Edge request flow

At a high level (CDN-agnostic):

1. A browser or crawler requests a page URL
2. The CDN edge worker intercepts the HTML response
3. The worker determines the page URL for lookup (origin + pathname; query strings and fragments are stripped. This follows the same logic as the JavaScript embed)
4. The worker fetches cached JSON-LD from Schema App’s data CDN for your account ID and that URL
5. On Akamai, the worker also fetches the origin HTML and merges markup into <head>. On Cloudflare, the worker modifies the HTML response returned for the route
6. The worker inserts one or more <script type="application/ld+json"> blocks immediately before </head>.
7. The completed HTML is returned to the client

Data environments: production uses data.schemaapp.com; test and UAT use datatst.schemaapp.com and datauat.schemaapp.com when configured in the worker.

Markup lookup and injection

• Lookup key: Schema App account ID + normalized page URL (origin and path only).
• HTML only: Non-HTML responses are passed through unchanged.
• Highlighter cache: Workers can optionally fetch highlighter cache payloads (aligned with “fetch from highlight JS cache” in the JS embed) when that markup exists on the CDN.
• Canonical URLs: Edge workers use the request URL, not <link rel="canonical"> on the page. Ensure authored URLs match what crawlers request.

Failure behavior

Edge integrations are designed to fail open:

• If Schema App’s data CDN returns no markup for the URL, the original HTML is returned.
• If a CDN or worker error occurs, the page should still render as if the worker did not run.
• Your core page content should never depend on the edge worker succeeding.

Bot vs human traffic

How human visitors are affected depends on your CDN configuration:

• Akamai: The Schema App Edge Worker is intended to run only for bot User-Agents (Property Manager rules). Normal users receive unchanged responses with zero TTFB impact from the worker.
• Cloudflare: The Worker runs on whatever routes you attach (often all HTML paths). Human visitors receive injected markup when cache data exists unless you add your own bot-only routing.

For recommended bot User-Agent lists on Akamai, see What Custom Bots should I add to my Robots-only deployment? Include SchemaBot so Schema App can validate deployed markup.

When to Consider Edge-rendering

Edge-rendering is not required for every site or situation. Consider it when:

• AI visibility and crawl reliability are strategic priorities
• You already use a supported CDN (e.g. Akamai or Cloudflare) and can deploy an edge worker
• Client-side JS is blocked, restricted, or undesirable for regulated industries
• Complex front-end architectures make JS-dependent markup harder to trust for all crawlers

Client-side rendering is not “bad for SEO.” Googlebot and Bingbot render JavaScript reliably. Edge rendering improves breadth (more crawlers and systems) and determinism (markup in the first response).

Note: If you are using a CDN that is not currently supported, raise it with your CSM. We may be working on a solution already and your input will help us prioritize accordingly.

Migrating from JavaScript to Edge SSR

Edge SSR changes how markup is delivered—not how it is authored. If you currently deploy with highlight.js, plan the migration so cached markup exists on Schema App's data CDN before you rely on the edge worker.

Recommended path: Crawler + edge SSR

For Highlighter templates, enable Crawler deployment so Schema App's crawler visits your pages and populates the Schema App CDN cache (data.schemaapp.com) without requiring highlight.js on the live site. The edge worker then injects that cached markup into the HTML response.

This is the recommended approach for edge SSR. It keeps delivery predictable, avoids loading Schema App JavaScript on production pages, and aligns with how edge workers are designed to work.

Can I keep JavaScript deployment with SSR?

Schema App does not recommend combining client-side JavaScript deployment with edge SSR for production sites. Edge SSR is intended to deliver markup in the initial HTML response from cached data on Schema App's CDN—not to run highlight.js in the browser at the same time.

Keeping JavaScript deployment alongside edge SSR is not advised because:

• Robots-Only does not apply to edge SSR. Bot filtering for JavaScript is handled at Schema App's CDN; edge delivery is controlled by your CDN configuration instead.
• Redundant delivery paths can make validation and troubleshooting harder.

If you are moving to edge SSR, plan to remove highlight.js (and any tag-manager tags that load it) from production pages once the edge worker is validated.

What happens to Robots-Only?

Robots-Only Deployment applies to JavaScript deployments only. It filters which user agents receive the full highlight.js script from Schema App's CDN.

With crawler + edge SSR:

• You do not need highlight.js or window.schema_highlighter on production pages.
• Robots-Only in Schema App project settings is not required and should not be relied on for edge delivery.
• Bot vs human traffic is handled by your CDN configuration (see Bot vs human traffic above).

Migration checklist

1. Author markup in the Editor or Highlighter as usual.
2. Enable Crawler deployment on Highlighter templates and confirm crawls complete.
3. Confirm cached markup exists for target URLs on Schema App's data CDN before go-live.
4. Deploy and testthe edge worker on staging using your CDN setup guide:
   • Akamai Setup Instructions
   • Cloudflare Setup Instructions
5. Validate markup in page source (or with a permitted bot user agent on Akamai) before production cutover.
6. Remove highlight.js and related tag-manager tags from production pages.
7. Disable Robots-Only in Deployment Management if it was previously enabled for JavaScript deployment.
8. Activate to production and re-validate a sample of URLs.

For step-by-step CDN configuration, use the setup article for your provider. For issues after migration, see How To: Troubleshooting Edge SSR.

Note: Akamai and Cloudflare will appear as deployment options in Schema App project settings as that in-app experience is released. Until then, follow the CDN setup articles linked above.

Benefits of Edge-side Rendering

• Crawl reliability — JSON-LD in the first HTML response; no dependency on JS rendering queues.
• LLM and AI crawlers — Many bots consume raw HTML without executing JavaScript.
• No browser scripts — When configured for bots only, human visitors do not download Schema App JavaScript.
• Simpler validation — View source or curl the HTML to confirm markup without running JS in DevTools.

CDN setup instructions

Schema App publishes edge worker packages and step-by-step guides for the CDN you already use:

• Akamai EdgeWorkers: Server Side Rendering — Akamai Setup Instructions
• Cloudflare Workers: Server Side Rendering — Cloudflare Setup Instructions

Those articles cover download URLs, environment variables, staging tests, and troubleshooting. Use this article for architecture context; use the CDN guide for installation.

Other SSR paths: CMS plugins (WordPress, Drupal, AEM) and webhooks also deliver server-side markup without a CDN worker. Edge rendering is for sites that already terminate traffic at Akamai or Cloudflare.

Resources

• Schema App Integrations: Overview of all integration methods
• Schema App JavaScript Deployment Overview: Standard CSR overview
• Large Language Models and JavaScript Consumption: A primer on how different bots render and consume JavaScript and JSON-LD
• Performance Impact of Integration Methods: Integration methods and their respective impact on load-time
• How To: Troubleshooting Edge SSR: Starting point for CDN-agnostic checks and provider guides

Conclusion

Edge rendering puts Schema App JSON-LD in the initial HTML response so crawlers and AI systems do not depend on JavaScript. Schema App still authors and caches markup centrally; the CDN worker fetches from data.schemaapp.com and injects scripts before </head>. Choose client-side or edge based on crawl requirements, CDN capabilities, and operational complexity—then follow the setup guide for your CDN.