Testing locally

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

Be clear about what a local run proves, because it is not everything:

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 routes 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 it reads exactly what your deployed site will read. The direction that matters here — your build fetching Geoffy — has no localhost problem at all.

Set GEOFFY_ORIGIN only if we have given you a specific Geoffy instance to develop against. It accepts a port, so GEOFFY_ORIGIN=http://localhost:3000 is valid if you are running one yourself.

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.

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.

The two previews answer different questions: 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.

Three things that will waste your afternoon

The dev cache will lie to you

These routes cache their fetch of Geoffy for revalidateSeconds — one hour by default — and in Next.js 16 the dev cache is in .next/dev/cache, not .next/cache. Clearing the one you expect changes nothing, which makes the cache look innocent while it serves you an hour-old answer and you go looking for a bug in Geoffy.

rm -rf .next/dev/cache && npm run dev

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.

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

Port 5000 is not free on macOS. AirPlay Receiver listens there and answers 403, so your dev server fails to bind and anything probing the port gets a plausible-looking HTTP error rather than a refused connection. Use another port.

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:5001 -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. Prove it locally with the curl in checking it worked, ship, and let the confirmation follow.