Summarize any webpage with Workers AI

Support teams, research agents, and product features often need the gist of a URL without stuffing full HTML into a context window. A Cloudflare Worker can fetch the page at the edge, extract readable text, and call Workers AI so retrieval and inference stay on Cloudflare’s network - no separate GPU box required.

This post covers pipeline design, product choices (AI Gateway, embeddings, RAG), prompt and extraction quality, and the AI Website Summary experiment as a pasteable reference.

Cloudflare products in this patternCopy Anchor Link

The minimal pipelineCopy Anchor Link

A reliable summarizer is four steps:

1. Validate the URL (http/https only) - same discipline as other catalog APIs
2. Fetch HTML with timeout and size cap (Fetch API)
3. Extract main text (strip nav, scripts, chrome)
4. Infer with a Workers AI text model and return JSON

Client → Worker → fetch(url) → extract text → env.AI.run(model, …) → JSON

Keep the Worker under ~60 seconds end-to-end. Cap extracted characters so prompt size stays predictable and costs do not spike on pathological pages.

Why Workers AI fits this jobCopy Anchor Link

From the Workers AI docs:

• Colocated with fetch - HTML retrieval and inference share the edge
• Binding-based - env.AI avoids shipping long-lived provider keys for core Cloudflare models
• Composable - same binding powers tags, translation, embeddings, speech, and image models elsewhere in the catalog

When you outgrow “one model, one route,” look at:

• Cloud AI Proxy - generic model access patterns
• AI Gateway Dashboard - cache/latency metadata through AI Gateway
• Workers AI model catalog - pick models by task and size

Designing the response contractCopy Anchor Link

Return structured JSON humans and agents can both consume:

{
  "url": "https://example.com/article",
  "title": "Example article",
  "summary": "…",
  "model": "@cf/…"
}

On failure, prefer stable codes aligned with the monorepo convention:

Validate in the route, call lib helpers, return jsonSuccess / jsonError. Do not leak stack traces to clients.

Extraction quality matters more than model choiceCopy Anchor Link

Garbage HTML in → vague summary out. Practical tips:

• Prefer main-content heuristics over dumping body text
• Drop script, style, nav, and footer blocks early (HTMLRewriter is ideal for streaming transforms)
• Normalize whitespace; keep headings as soft section cues
• If the page is JS-only, plain fetch misses the article - use Browser Rendering via Browser Markdown Scrape, then summarize the markdown

For static marketing pages, Metadata Extractor may already give title + description without an LLM. Use Workers AI when you need a true synopsis, not just og:description.

Prompt sketchCopy Anchor Link

Keep prompts explicit and bounded:

Summarize the following webpage text in 5-8 sentences.
Focus on facts; ignore navigation chrome.
If the text is empty or unrelated to an article, say so.

TEXT:
…

Pin the model id in constants so rollouts are deliberate (Workers AI models).

AI Gateway: when to put it in frontCopy Anchor Link

AI Gateway adds:

• Request analytics and error rates
• Caching for identical prompts (great for repeated URLs)
• Rate limiting and provider fallbacks in larger architectures

For a single Workers AI binding on one experiment, Gateway is optional. For a product that fans out across models or teams, put Gateway early. The AI Gateway Dashboard experiment shows metadata you can surface in ops UIs.

From summary to a product surfaceCopy Anchor Link

Once summarization works, nearby experiments extend the same product family:

A common product path: summarize → tag → embed → search. Each step stays a focused Worker you can deploy independently - matching the catalog’s single-responsibility rule.

Cost, latency, and safetyCopy Anchor Link

• Cap input characters and max tokens
• Cache summaries keyed by URL + content hash (Cache API or KV)
• Do not send secrets or private HTML to a model without a data policy
• Rate-limit public endpoints; summarizers get abused as free proxies
• Prefer allowlisted hosts for internal “summarize our docs” tools

Try the referenceCopy Anchor Link

1. Skim Workers AI get started
2. Open AI Website Summary
3. Deploy with the button or wrangler deploy from apps/experiments/ai-website-summary
4. Call the documented endpoint with a public article URL
5. Inspect JSON summary and error paths
6. Add AI Gateway, auth, or caching before production traffic

You should have a working edge summarizer in minutes, then harden it for your traffic profile instead of starting from a blank AI template.

Production checklistCopy Anchor Link

1. Pin a model id from the Workers AI model catalog.
2. Cap extracted characters and max tokens.
3. Cache by URL + content hash (Cache API or KV).
4. Put AI Gateway in front when you need analytics or cross-team controls.
5. Escalate JS-heavy pages through Browser Rendering before summarize.
6. Rate-limit and authenticate public summarizers.
7. Log model, token estimates, and extract length - not raw private HTML.

Prompt and evaluation loopCopy Anchor Link

Ship with a golden set of 10–20 URLs (news, docs, SPA, empty page, paywall). For each, assert:

• Summary is non-empty when extract succeeded
• Refusal / clear message when extract failed
• Latency under your SLO
• No leakage of nav chrome phrases (“Accept cookies”, “Sign in”)

Re-run the set when changing models or extractors.

FAQCopy Anchor Link

Which model should I pick?Copy Anchor Link

Start with a small instruct model for cost, then upgrade only if quality fails your golden set. See Workers AI models.

Is Workers AI enough for RAG?Copy Anchor Link

Summarizing one URL is not RAG. For multi-doc Q&A use Vectorize via RAG Mini Search or AI Search.