One Adobe Edge Function · any number of EDS sites

Every crawler gets the whole page.

Q: Can I preview edge output before merging?

Yes. Open your production host with ?branch= . loom runs that branch’s hooks uncached and with noindex. Teams can switch this off per site with allowBranch: false.

loom weaves each Edge Delivery site’s own code into its HTML at the edge. Search engines, AI assistants and non-JS clients receive the finished page. Your developers and authors keep working exactly as they do today.

See how it works

Read the proof

x-edge-function: loom@0.19.0
HTML routes only
fail-open by design
no function deploy per site

Reading your raw HTML

Search engines

ChatGPT

Perplexity

Copilot

AI Overviews

Non-JS clients

AI crawlers

The gap

AI answers now sit next to search. Is your page ready?

Edge Delivery Services is built for speed, simplicity and developer freedom. Two things changed around it, and both hide content from the readers that matter next.

Crawlers skip JavaScript

ChatGPT, Perplexity, Copilot and AI Overviews read your pages. Many of their crawlers do not run JavaScript, so they only see the raw HTML.

Browser-built content is invisible

Navigation, footer, accordions and FAQs, product data and JSON-LD are assembled in the browser. In the raw response, they are simply not there.

loom closes the gap at the edge

The first HTML response already contains the finished page: rendered blocks, nav, footer, fragments, lang and one clean JSON-LD graph.

What a crawler sees

Same page. Two very different first responses.

Default EDS publishes lean, semantic content and adds the rest in the browser. loom adds it before the response leaves the edge.

raw EDS response · no JavaScript

<html>
<head>
  <title>Pricing</title>
</head>
<body>
  <header></header>
  <main>
    <div>
      <div class="accordion faq">
        <div>
          <div>Is it safe?</div>
          <div>Yes. Hooks fail open.</div>
        </div>
      </div>
    </div>
  </main>
  <footer></footer>
</body>

Empty header and footer, no lang, no structured data. A crawler indexes a skeleton.

with loom · same URL, same first response

<html lang="en">
<head>
  <title>Pricing</title>
  <script type="application/ld+json">
    {"@type":"FAQPage", "mainEntity":[ … ]}
  </script>
</head>
<body>
  <header><nav data-edge="1"> … links … </nav></header>
  <main>
    <div>
      <details class="accordion-item">
        <summary>Is it safe?</summary>
        <div>Yes. Hooks fail open.</div>
      </details>
    </div>
  </main>
  <footer><div data-edge="1"> … </div></footer>
</body>

Blocks rendered, nav and footer present, lang set, FAQPage JSON-LD from the visible text.

Freedom kept

Everything you love about EDS, unchanged.

loom is designed to leave the way teams build alone. The platform owns the engine. Each site owns its hooks.

What you love about EDS	With loom
Plain HTML, CSS and vanilla JS, no framework	Unchanged. loom adds no framework and no runtime dependency to your site.
Blocks in `blocks/<name>/`	Unchanged. The browser block remains the single implementation.
Authors write in Document Authoring, Word or Sheets	Unchanged. Authors notice nothing.
Git push to publish	Unchanged. Pushing your repo is enough. There is no function deploy.
Branch previews on `aem.page`	Unchanged, plus `?branch=<name>` on your production host to see edge output before merge.
Your repo, your code, your pace	Unchanged. Each site owns its hooks in its own repo.
The 100-ish Lighthouse mindset	Respected. Only HTML routes pass through loom. Assets, media, JSON and `.plain.html` go straight to `aem.live`.

How it works

Between the CDN and `aem.live`. HTML only.

A request-time function transforms the current page, so there is no stored output to keep in sync.

Browser or crawler
Asks for a page.
any client
Adobe CDN
Routes HTML to loom. Assets, media, JSON and .plain.html go straight to EDS.
sites.yaml · cdn.yaml
loom
Fetches the page and runs the site’s own hooks: blocks, nav, footer, fragments, JSON-LD.
one function, many sites
aem.live
Stays the only source of truth. Nothing is stored or copied.
<ref>--<repo>--<org>

blocks/accordion/accordion.edge.js


              # a block hook is one line. The browser and the edge run the same decorate().
export { default as decorate } from './accordion.js';
export const attrs = { 'data-edge': '1' };

Developer flow

One extra command. That is all.

Local development, block code, content model, hosting and CDN stay as they are. Blocks and hooks opt in one by one: a block without an .edge.js is left as authored.

your usual loop


              # edit block / styles / scripts, then as always:
aem up
git commit && git push
# the one extra command, before the commit:
npm run build:edge
# writes two small generated files, committed with your change.
# a pre-push hook and a CI job refuse a stale bundle.

The full walkthrough

Proof today

What is measured, and what is not yet.

181
tests in the engine
including browser-versus-edge parity
0.09 s
plain EDS, cache miss
loom: about 0.28 to 0.38 s. A CDN hit is as fast as plain EDS.
2
sites on one function
proven live on 2026-11-13, config only
—
measured SEO and AI uplift
not measured yet. Baseline and after-run are planned.

See the multi-site proof

For your team

One engine, four conversations.

Be the answer, not just a page.

Your content is unchanged, and crawlers and AI assistants can finally read all of it.

Better visibility in AI answers and classic search
Structured data machines can read, and rich-result eligibility for the types Google still supports
No change for authors and no new tools to learn
One platform for many sites instead of one add-on per site

Same repo, same blocks, one extra build step.

Your block’s own decorate() runs at the edge.

Push to ship, with no function deploy and live in about 60 s
Fail-open hooks, a pre-push check and CI guardrails
181 tests in the engine, including browser-versus-edge parity
A block hook is a single line

A thin, auditable layer on Adobe’s own stack.

Adobe Edge Functions, the Cloud Manager config pipeline and CDN originSelectors.

sites.yaml and cdn.yaml are the source of truth
The CDN decides which site a host is, not the client
One function serves many sites, within the limit of three functions per program
Observable through X-Edge-Function and per-step Server-Timing

An EDS-native answer to “what about SEO and AI visibility?”

loom extends EDS through Edge Functions instead of working around the platform.

Keeps the EDS philosophy: no framework, code in the site repo, a fast path for everything that isn’t HTML
A multi-tenant pattern other partners and customers can reuse
Valtech is ready to co-publish a reference with measured before and after results

Roadmap

From pilot to reference case.

Scale the pilot
Multi-site is proven with two sites. Next: give loom-site its own block hooks and onboard a third site with a different block set.
now
Measure
The raw-HTML crawl diff and the Rich Results Test are done (see the proof page). Still to capture: Search Console data and an AI-bot fetch comparison, before and after.
next
Share
Present the results to the Adobe Edge Delivery and Edge Functions teams, and publish a reference case.
then

Questions

Honest answers.

Do authors have to change anything?

No. There are no new fields or templates and no training. Authors keep writing in Document Authoring, Word or Sheets.

Do developers have to rewrite their blocks?

No. A block stays plain EDS. Its hook re-exports the block’s own decorate(), so there is no second implementation, and parity tests check that the browser and the edge produce the same output.

What happens if a hook fails?

loom fails open. A hook that throws is skipped and the authored page ships. A block whose decorate() throws stays exactly as authored.

Will it slow my site down?

Only HTML routes pass through loom. A CDN hit is as fast as plain EDS. On a cache miss we measured about 0.28 to 0.38 s time to first byte against about 0.09 s for plain EDS, on the proof-of-concept site.

Can I preview edge output before merging?

Yes. Open your production host with ?branch=<name>. loom runs that branch’s hooks uncached and with noindex. Teams can switch this off per site with allowBranch: false.

How many sites can one function serve?

Adding a site is configuration only: a sites.yaml entry plus its CDN rules, with no function change and no redeploy. Two sites are proven live today on one function. A program can hold up to three edge functions.

Do you have SEO or AI-visibility numbers?

Not yet. The mechanism is clear (more of the page in the first response), but we have no before and after measurement. It is the next step on the roadmap.

What can loom not fix?

Content that does not exist in the authored page, weak headings or copy, and blocks that import aem.js, which cannot run at the edge. loom makes existing content visible. It does not improve it.

Be the answer, not just a page.

Read the numbers, the limits and the multi-site proof. We would rather show you what is measured than what is hoped for.

Read the proof

See the SEO and GEO gaps

Every crawler gets the whole page.

AI answers now sit next to search. Is your page ready?

Crawlers skip JavaScript

Browser-built content is invisible

loom closes the gap at the edge

Same page. Two very different first responses.

Everything you love about EDS, unchanged.

Between the CDN and aem.live. HTML only.

Browser or crawler

Adobe CDN

loom

aem.live

One extra command. That is all.

What is measured, and what is not yet.

One engine, four conversations.

Be the answer, not just a page.

Same repo, same blocks, one extra build step.

A thin, auditable layer on Adobe’s own stack.

An EDS-native answer to “what about SEO and AI visibility?”

From pilot to reference case.

Scale the pilot

Measure

Share

Honest answers.

Be the answer, not just a page.

Between the CDN and `aem.live`. HTML only.