Testing locally

You do not have to deploy to find out whether this worked. Run astro dev and you can see the widget, the structured data, llms.txt, the namespace and your merged robots.txt exactly as a crawler will.

Question	Answer it locally?
Does the widget render, server-side, on my product page?	Yes
Is the structured data in the HTML before JavaScript runs?	Yes
Do my new endpoints return the right bytes and content types?	Yes
Did my robots.txt merge land in the right place in the file?	Yes
Does Geoffy confirm my integration and mark products live?	No — see below

Nothing to configure

Leave GEOFFY_ORIGIN unset. Your local build talks to production Geoffy over https, which works from anywhere, and reads exactly what your deployed site will read.

Set it only if we have given you a specific instance to develop against — and remember it is read from process.env, so under an edge adapter with no process it is ignored silently. Pass origin alongside siteKey instead in that case.

But verify your domain first

Artifacts are served only for a verified site. Until ownership passes, every artifact endpoint returns 404, so a local run would render nothing and tell you nothing. See prove you own your domain — verification goes the other way and needs a public https address.

Check the build mode you will actually deploy

astro dev hides the static/server distinction

astro dev renders every route on demand, including a [...path].ts with no prerender = false. So the namespace endpoint works perfectly in dev and fails the build. Run astro build before you believe the mount works.

npx astro build && npx astro preview

preview serves the real output, which is the only local thing that tells you what your deployment will do.

A local run only shows you published content

Artifact endpoints serve published bundles and nothing else, so localhost is not a way to look at a draft. A product with nothing published renders nothing: that is a normal state, not an error.

Geoffy’s review step shows you the content before you publish; a local run shows you the integration — that published content lands on your page, server-rendered, at the right URLs.

Two things that will waste your afternoon

The caches in front of you. Astro has no fetch cache, so a server-rendered page reads the current content on each request. Two things can still show you an old answer: the list of published products, kept in memory for 30 seconds, and the text files, which answer with Cache-Control: max-age=300, so your browser or CDN can keep them for 5 minutes. Reload without cache, or wait out those windows, before you conclude a fix did not work.

When something looks wrong, read Geoffy directly before you blame it:

Your site’s settings in Geoffy show the direct URL for each of your published surfaces. Fetching one bypasses every cache of yours at once, which is the fastest way to tell whose side a problem is on.

If Geoffy and your local mount disagree, your cache is at fault.

Killing by port takes your tunnel with it. lsof -ti:PORT matches every socket carrying that port, including a tunnel’s established connections to your dev server. Match only the listener:

kill $(lsof -ti:4321 -sTCP:LISTEN)

What local cannot do

Geoffy confirms your integration by fetching your live product page at its canonical URL — the public one, not your machine. So until the integration is deployed, products stay pending with code_not_added no matter how correct everything looks locally.

That is the check working as intended: it reports what your visitors and the crawlers actually get.