Our facts page was going to teach AI search the wrong numbers. Here's how we made it stay true.

I work on DreamCore, a service where you make browser games by chatting. This post is about one small page on our site and a mistake we almost shipped.

AI search engines (ChatGPT search, Perplexity, Gemini, Copilot) love pages full of quotable facts. So we wrote one: a "DreamCore facts and figures" page with who runs the service, which platforms it supports, and how many games people have published.

| Public games | 6,000+ | | Total plays of public games | 1,100,000+ | Enter fullscreen mode Exit fullscreen mode Our founder spotted the problem within minutes: numbers you write by hand go stale, and an AI will repeat them as if they were current. Worse, even if we keep the page updated, a model may have been trained on last month's copy.

Here is what we changed. It's about 100 lines of code.

The page now has a marker in its Markdown:

## Numbers <!-- live-facts --> Enter fullscreen mode Exit fullscreen mode When the page renders, the server counts public games, total plays and distinct creators, using the same filters as our public game shelf. That means deleted projects are left out, and so are school accounts that are hidden from the public. The first live count came out lower than our hand-written one, because the hand-written query had skipped those filters. That alone was worth the change.

The result is cached for 6 hours per brand. Concurrent requests share one in-flight promise, so a crawler hitting the page 50 times at once triggers one count, not 50.

function floorToTwoSignificant ( n ) { const value = Math. max ( 0, Math. floor ( Number ( n ) || 0 )); if ( value < 100 ) return value; const step = 10 ** ( String ( value ). length - 2 ); return Math. floor ( value / step ) * step; } // 6,092 -> 6,000 1,180,359 -> 1,100,000 1,506 -> 1,500 Enter fullscreen mode Exit fullscreen mode The table says "5,900+" with "As of October 29, 2026" above it.

This is the part that handles the training-data problem. All three numbers are cumulative counters, so they only go up. A statement like "as of date D, at least N" stays true forever. If a model learned it six months ago, the worst case is that it understates. It is never wrong.

A raw number like 6,092 is different. It is wrong the next day, and anyone who quotes it is quoting something false. Two significant digits also keep the figure stable for days at a time, which makes it easier to cite.

If the database call fails, we render no table at all, and we log the error. We don't show a cached old value or a zero. Either one would bring back exactly the problem we were fixing. The heading and the explanation stay, so the page still reads fine.

We cache the failure for 5 minutes, so a database outage doesn't turn every page view into a slow retry.

We kept prices and daily limits off the page on purpose. Those can go down as well as up, so a dated lower bound doesn't protect them. If a fact can change in both directions, it belongs on a page you update alongside the product (our pricing page), not on a page designed to be quoted.

On Wikidata, a search for "DreamCore" returns two other games and a dream-themed internet aesthetic, but not us. We added sameAs to our Organization JSON-LD, listing only accounts we actually run (App Store, X, YouTube, our blogs):

{ "@type": "Organization", "name": "DreamCore", "legalName": "NEIGHBOR CO., LTD.", "sameAs": [ "https://x.com/DreamCore_gg", "https://www.youtube.com/@dreamcoregg" ] } Enter fullscreen mode Exit fullscreen mode We had included a third-party directory listing at first. Our code review removed it, because a listing someone else runs isn't "the same entity".

You can see the page at https://www.dreamcore.gg/dreamcore-facts. If you want to try making a game, it's https://www.dreamcore.gg (free, and players don't need an account).