Trakkr Docs

Installation

Installing AI Pages means putting a small piece of middleware in front of your website. The middleware inspects every incoming request, and for the ones that come from AI crawlers, it fetches the optimized version of the page from Trakkr and serves that instead of your normal HTML. For everything else, including all human traffic, it gets out of the way.

The code is small (under 100 lines for most platforms), the deploy is usually a single file commit or worker upload, and Trakkr generates the snippet for you with your API key already inserted. The setup wizard inside the AI Pages page walks through it step by step. This document is the reference: what's happening under the hood, which platform path fits which site, and how to verify the install worked.

The setup wizard

When you open the AI Pages page for the first time on a brand, you'll land on a five-step wizard:

The first four steps are about telling Trakkr what to generate. The fifth step gives you the actual code, a file path to put it at, and platform-specific install instructions. Most of the install time is in step five.

You can come back to any step from the Settings button on the dashboard. Changing the platform regenerates the code with the new runtime. Changing the crawler list or feature set updates server-side config without requiring a redeploy.

Pick the right platform path

Trakkr generates code for nine paths. The right one depends on where your site is actually hosted, not what the marketing page says.

PathRuntimeUse when
Cloudflare WorkersCloudflare Edge (V8)You use Cloudflare for DNS, regardless of where your origin is.
Vercel Edge MiddlewareVercel Edge RuntimeYour Next.js app is deployed on Vercel.
Netlify Edge FunctionsNetlify Edge (Deno)You're on Netlify.
Next.js MiddlewareNext.js Edge RuntimeYou use Next.js but not Vercel (self-hosted, AWS, Docker, etc.).
AWS CloudFrontLambda@Edge (Node.js)You front your site with CloudFront.
WordPressPHP mu-pluginYou run WordPress with file/FTP access.
Node.js / ExpressNode.jsYou run your own Node server and want a middleware function.
Nginx / OpenRestyOpenResty (Lua)You self-host behind Nginx and have OpenResty installed.
Other (DNS proxy)Cloudflare DNS in frontYou're on Shopify, Squarespace, Webflow, Wix, Notion, or anything that doesn't let you run server code.

The Cloudflare Workers and "Other" paths overlap: both end up with a worker running at Cloudflare's edge. The difference is whether Cloudflare is already in front of your site. If it is, pick "Cloudflare Workers" and skip the DNS step. If it isn't, pick "Other" and the wizard adds the DNS migration to the install guide.

Before you start

Whichever path you pick, you'll want these in hand:

The API key embedded in your generated code is sensitive. Treat it like any other deploy secret. If it leaks (committed to a public repo, posted in a screenshot), regenerate it from the AI Pages settings and redeploy.

What each path actually deploys

This is the part that matters if you want to understand what's running on your infrastructure. All paths follow the same pattern; the differences are syntax and where the code lives.

The middleware does five things, in order:

  1. Check whether the request is for a non-HTML asset (.js, .css, an image, etc.). If yes, pass through.
  2. Read the User-Agent header. Compare it against a hardcoded list of AI crawler signatures.
  3. If no match, pass through to your origin.
  4. If match, POST to https://prism.trakkr.ai with the URL, pathname, and crawler name. Include your API key in the X-API-Key header. Time out after 1-1.5 seconds.
  5. If Trakkr returns optimized HTML, serve that. If anything fails (timeout, error, rate limit), serve the original page.

The Cloudflare Worker version is the canonical reference because it's the simplest. The Vercel and Netlify versions are translations of the same logic into their respective edge runtimes. The WordPress plugin does it in PHP via add_action('send_headers', ...). The Nginx path uses access_by_lua_block and the OpenResty HTTP client.

Cloudflare Workers

You'll deploy a single worker and bind it to a route matching your domain. Two clicks in the Cloudflare dashboard and a paste from the wizard, that's the whole job. The route pattern is *yourdomain.com/*, which catches every request on the domain and runs the worker before forwarding to your origin.

The free Workers tier handles 100k requests/day, which is plenty for most sites. Workers Paid ($5/month) lifts that to 10M/day if you have very high traffic.

Vercel / Next.js middleware

Save the generated code as middleware.ts at the root of your project (next to package.json), commit, push. Vercel detects the file automatically and runs the middleware on every request on the next deploy. If you already have a middleware file, merge the AI Pages logic into your existing function rather than overwriting it.

Netlify Edge Functions

Save the file as netlify/edge-functions/prism.ts, add a [[edge_functions]] block to your netlify.toml, push. Netlify wires it up on the next deploy. Edge functions run on Deno, not Node, which is why the file uses Deno-style imports.

AWS Lambda@Edge

This one has more steps. Create a Node.js 20.x Lambda function in us-east-1 (Lambda@Edge has a region requirement), paste the code, publish a version (not $LATEST), then attach the version to your CloudFront distribution as a Viewer Request trigger. The IAM execution role needs edgelambda.amazonaws.com as a trusted entity.

The 40KB response body limit on viewer-request responses is real. The wizard's generated code checks for it and falls through to your origin if the optimized HTML exceeds the limit.

WordPress mu-plugin

Save the generated PHP file as wp-content/mu-plugins/trakkr-prism.php. Must-use plugins load automatically with no activation step. Verify in WP Admin > Plugins > Must-Use that "Trakkr Prism" shows up. The plugin hooks send_headers at priority 1 to intercept before any theme or other plugin output starts.

WordPress hosts that don't allow file uploads to mu-plugins/ (some managed hosts) need either a regular plugin (let support know if you need that variant) or the DNS proxy approach.

Node.js / Express

Save the file as prism-middleware.js, register it before your routes:

const prism = require('./prism-middleware')
app.use(prism)

It needs to be app.use'd ahead of your route handlers so it can intercept crawler requests before they reach your business logic.

Nginx / OpenResty

Requires OpenResty (an Nginx distribution with LuaJIT) and the lua-resty-http library:

opm get ledgetech/lua-resty-http

Then drop the generated access_by_lua_block into your server {} configuration and reload Nginx. This is the most involved path and only worth it if you're already running OpenResty for other reasons.

Other (DNS proxy via Cloudflare)

The path for platforms that don't let you run server code (Webflow, Shopify, HubSpot, Squarespace, Wix, Framer, Ghost, Carrd, Notion sites, hosted CMSes). You're not modifying your site; you're putting Cloudflare in front of it and running the worker there.

The steps:

  1. Sign up for Cloudflare's free plan and add your domain.
  2. Cloudflare imports your existing DNS records. Make sure your main A or CNAME record has the orange-cloud proxy enabled.
  3. Update your nameservers at your domain registrar to point at Cloudflare. DNS propagation takes anywhere from 5 minutes to a few hours.
  4. Deploy the Cloudflare Worker from the wizard.
  5. Add a Worker Route matching yourdomain.com/*.

The end-state is identical to native Cloudflare Workers; you've just added Cloudflare as a layer in front of your hosted platform.

Verifying the install

After deploy, you need to confirm three things: the middleware is reachable, it's correctly detecting crawlers, and Trakkr is returning optimized HTML.

The test tool on the AI Pages dashboard does all three at once. Click Test connection in settings, give it a URL, and it sends a probe request from a fake GPTBot user agent. Within a few seconds it tells you whether the request hit the middleware, whether the API key was accepted, and what came back.

You can also test manually from a terminal:

curl -A "GPTBot/1.0" -I https://yourdomain.com/

Look for these response headers:

X-Prism-Optimized: true
X-Prism-Cache: HIT

Cache: HIT is the steady state. Cache: MISS means it just optimized for the first time, which is normal on a fresh URL. Missing both headers means the middleware isn't running or didn't recognize the user agent.

If you want to see the actual optimized HTML, drop the -I from the curl command and you'll get the body back. Compare it to a normal request (without -A "GPTBot") and the difference should be immediate: cleaner structure, JSON-LD schema in the head, no JavaScript.

When things go wrong

Most install issues fall into a small number of buckets.

The middleware isn't intercepting

Either it didn't deploy, or it deployed but isn't running on the routes you expected. The fix depends on the platform: verify the worker route on Cloudflare, confirm middleware.ts is at the project root for Vercel, check wp-content/mu-plugins/ for WordPress, run nginx -t for Nginx. Most often it's that the deploy succeeded but to the wrong path or wrong scope.

The middleware runs but Trakkr returns 401

Your API key is wrong. Either you regenerated it in Trakkr and didn't update the code, or the wizard's code wasn't copied cleanly. Open the AI Pages settings, copy the current key, paste it into your deploy, redeploy.

Optimized HTML looks incomplete or wrong

The page probably relies on JavaScript that didn't render correctly in our headless browser, or it has anti-bot protection that's blocking us. Open the test tool, paste the URL, and look at the diff. Common culprits: content loaded after a user scroll, content gated behind a cookie banner that auto-dismisses for humans but not bots, lazy-loaded sections that need an explicit trigger.

The site is down after install

Roll back. Remove the worker, delete the middleware.ts, disable the WordPress plugin. The site returns to normal immediately. Then debug in a non-production environment. The middleware is designed to fail open (any error serves the original page) but a syntax error in the file itself can break the whole deploy.

Usage is climbing faster than expected

Open the Pages tab and sort by visits. You'll usually find one or two URLs (a sitemap, a feed, an unintentionally crawlable internal page) accounting for most of the volume. Add those paths to the exclude list in settings.