What actually got our articles cited by ChatGPT (and what didn't)

adif sgaid — Thu, 23 Jul 2026 16:01:30 +0000

A few weeks ago I found out our site had a table of contents that rendered for absolutely nobody.

The code was there. The CSS was there. It had been shipping to production for months. It just never appeared, because the partial looked for h2[id] and our markdown renderer only ever emitted <a name="..."> — a legacy anchor, no id on the heading itself. So the selector matched zero elements, every time, on every article. Nobody noticed because nobody was looking at it.

I only found it because I was hunting for something else: why our content wasn't getting picked up by AI search — ChatGPT, Perplexity, Google's AI Overviews. We've got ~1,600 published articles. Plenty of traffic historically. And almost nothing showing up as a citation in any of the answer engines.

That hunt turned into a couple of weeks of work. Here's what actually mattered, what didn't, and the stuff I got wrong on the way.

The thing nobody tells you: access comes first

I spent a day reading AEO checklists (that's "answer engine optimization" — SEO for the machines that answer instead of link). Every one of them opens with schema markup. None of them start with the question that actually gates everything: can the AI crawlers even fetch your pages?

Go look at your robots.txt right now. The bots that feed the answer engines are GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot. If any of those are disallowed, everything downstream is theater.

There's a genuinely nasty gotcha here I didn't know. In the robots protocol, a named user-agent group replaces the * group for that bot — it doesn't merge. So if you did the "nice" thing and added User-agent: GPTBot / Allow: / blocks, congratulations: those bots now ignore all your * disallows and happily crawl /reactions, /admin, whatever. We had GPTBot burning crawl budget on tracking endpoints for exactly this reason. The fix was to delete all the per-bot groups and keep one User-agent: * that allows content and blocks only the junk. Everyone, bots included, follows it.

Then add an llms.txt — a plain-text, hand-curated list of your best URLs with a one-line description each. It's the "here's what's worth reading" file for models. Cheap to write, and it's becoming a real convention.

Make your paragraphs quotable

This is the part that clicked for me. Answer engines don't cite pages. They cite passages. And a passage a model can grab cleanly is one that:

lives under a heading that answers a real question ("How much VRAM do I need for a 70B model?" not "Requirements"),
states its answer in the first two sentences, no "as we discussed above,"
and is small enough to be a chunk on its own (the rough unit is ~500 tokens).

Comparison content punches above its weight here, and I think I finally understand why. The rerankers these systems use are good at contrast and negation — "X does this, Y does not." So a section literally titled "Cursor vs Copilot" with a table underneath is basically pre-chewed for them.

And — back to my dead table of contents — put ids on your headings:

<!-- legacy, not enough -->
<h2><a name="vram">VRAM</a></h2>

<!-- what you want -->
<h2 id="vram">VRAM</h2>

Fragment-addressable sections (/post#vram) are easier for a model to isolate and quote. Fixing our renderer was one line. Fixing the existing 1,600 articles meant re-rendering all of them, because the HTML was stored, not generated on the fly. Don't forget that step — I almost did.

Schema: useful, but not for the reason you think

Yes, emit JSON-LD. But Google killed FAQ rich results for most sites back in 2023, so if you're doing FAQ schema for the little dropdown in search results, stop — you won't get it. Do it because the answer engines parse it.

One bug I'd bet money you have if you generate FAQ schema from markdown: your answer text is full of markdown. A [link](url) or **bold** sitting inside acceptedAnswer.text looks broken to a parser. We were doing exactly this. Strip the syntax before you store it — plain text only.

The one that I think matters most, though, is the site-level entity graph. An Organization + WebSite block, emitted on every page, with a sameAs array pointing at your real social/profile URLs. It's how you tell these systems "this domain is a coherent entity you can trust as a source." If you do one schema thing, do this one.

The honest part

Here's what I can't tell you: whether any of it worked yet.

Our Google traffic is still down about 24% over the last month. The AEO changes are days old. Crawlers re-fetch on their own clock, and the answer engines update slowly, so the earliest I'd expect to see movement is a few weeks out. Anyone promising you a before/after in 48 hours is selling something.

What I can tell you is the metric to watch, and it's not Google clicks. It's cited pages — how many of your URLs show up as sources inside ChatGPT / Perplexity / AI Overviews. Some tools report this now. That number is the one that responds to this work. Track it every couple of weeks, ignore the daily noise.

So that's the playbook: let the crawlers in, make your paragraphs stand on their own, describe your entity consistently, and measure the right thing. Most of it is unglamorous. The table of contents that rendered for nobody is a decent metaphor for the whole exercise — half of AEO is just fixing the quiet stuff you assumed already worked.

I run PromptZone, a community for prompt engineering and AI builders. Everything above came out of doing this to our own corpus.

Deploying Forem on Render.com PromptZone.com

adif sgaid — Tue, 30 Apr 2024 08:31:03 +0000

The journey of deploying an open-source software platform like forem can be complex and daunting, but with the right tools and services, it can also be remarkably rewarding. This article details my experience deploying Forem, the software behind the Dev.to, on Render.com, deploying Promptzone.com.

Understanding Forem

Forem is an open-source platform designed to empower community builders to create their own spaces for discussion and connection. It's built using a robust tech stack including Ruby on Rails, JavaScript, and PostgreSQL, making it a solid choice for developers looking to customize or scale their community platforms.

Choosing Render.com for Deployment

Render.com emerged as an excellent choice for deploying Forem due to its simplicity and powerful features, think of it like Heroku when it was still cheap and good. Render offers straightforward configurations, automatic scaling, and a suite of services that support web applications, background workers, cron jobs, and databases—all crucial for a Forem deployment.

Step-by-Step Deployment Process

Setting Up the Forem Repository: The first step involved forking the Forem repository on GitHub. This allowed me to manage customizations and updates with ease.
Configuring Render.com Services:
- Web Service: I configured a web service on Render for the Forem web application. This involved setting environment variables such as the database URL and Redis instances, I then deployed a Docker image to the Docker hub registry and deployed in a web service.
- Background Workers: Forem utilizes Sidekiq for background jobs. I set up a worker service on Render to handle these jobs, ensuring that email notifications, feed updates, and other background tasks run smoothly, same thing here I deployed the same docker image.
Database and Redis Setup: I used Render’s managed PostgreSQL and Redis services, which provided hassle-free maintenance and scalability for the database needs of Forem.
Environment and Secrets Management: Render’s environment groups feature was invaluable for managing the application’s environment variables and secrets securely, make sure to add all the necessary ENV secrets otherwise it won't work (I will dive in detail in another post on everything you need.).

Going Live with PromptZone.com

After configuring and testing the Forem instance on Render.com, the final step was to go live. I also used Fastly.com as CDN like Forem suggested.

Conclusion

This is not the suggested way of deployment by the forem team, nevertheless I found it easier and smother than using the deployment selfhost, however I think it's good to know different approaches and use the one suits you the most, if you don't have time to manage a server I think using a pass like Render does the job, and it's cheaper then Heroku at the time of this post.

DEV Community: adif sgaid