The Geoffy namespace

Geoffy has more surfaces than the three root files: a plain-text twin for every product, a sitemap of them, and your buying-guide pages. They all live under one namespace, and this single endpoint puts the whole of it on your domain.

src/pages/apps/geoffy/[...path].ts

import { createGeoffyProxyEndpoint } from "@geoffy/headless/astro";

export const prerender = false;   // required — see below
export const GET = createGeoffyProxyEndpoint({ siteKey: import.meta.env.GEOFFY_SITE_KEY });

You now serve:

• Directoryapps/

  • Directorygeoffy/

    • Directoryllm/

      • {handle}.md each product, as plain text
    • Directoryguides/

      • {slug} each published buying guide
      • {slug}.md the same guide, as plain text
    • sitemap.xml all of the above, listed

prerender = false is not optional

This is a rest-parameter route, and a prerendered dynamic route with no getStaticPaths() fails astro build outright. Astro prerenders by default, so without that line your deploy stops. An earlier version of this guide called a static build a harmless no-op, which was wrong.

You need on-demand rendering

An adapter and output: "server", or Astro’s default plus prerender = false here. A fully prerendered site cannot serve this route at all — do not add the file, and your content stays reachable at Geoffy’s own domain instead.

That is one of the two reasons how updates arrive recommends thinking about your build mode before you go further: going fully static costs you this route, and this route is what puts your content on your own domain.

Why this is worth a route

Without it, that content is still served — from api.geoffy.ai, not from you.

An AI system that reads your buying guide there records api.geoffy.ai as the source, so the citation your guide earns goes to us instead of to you.

Why a namespace and not three more helpers

It is the last integration change this package will ask you for. Anything Geoffy adds later appears under the namespace you have already mounted — no upgrade, no new file, no re-deploy on your side.

The mount path is fixed at /apps/geoffy

Geoffy probes that exact path to confirm your integration, and publishes twin URLs built from the same literal. A mount somewhere else is probed where you do not serve, and reported as never mounted. If /apps/* is genuinely taken in your app, tell us — the fix is a setting on our side, not a flag in the package.

Two behaviours worth knowing

• If Geoffy is unreachable or erroring, this endpoint answers 503 with a Retry-After — never a fabricated 404, so a crawler retries instead of dropping the page from its index.
• Query strings are not forwarded, because no artifact reads one.

Until you add it

Geoffy notices and simply says less: your llms.txt will not advertise the twins or the sitemap, rather than pointing a crawler at pages that are not there. Confirming the mount is covered in checking it worked.