ServiceNow Product Documentation is Now on GitHub — Built for AI, Built for You

[mark_moulder]

What we published

Two things went live together:

1. llms.txt — An index file hosted at https://github.com/ServiceNow/ServiceNowDocs/blob/australia/llms.txt. This is a lightweight, AI-readable table of contents that lists every available doc topic with a short description and a direct link. When an AI tool wants to learn about ServiceNow, this is the first file it reads.
2. The GitHub repo — The full documentation set, organized by product area , one Markdown file per topic. An AI tool reads the index, identifies what it needs, fetches the file directly, and uses the content to answer your question — no JavaScript rendering, no web scraping, no guessing.

---

Why this matters for AI tools

Most documentation sites — ours included — are built for human readers in a browser. That means JavaScript-rendered pages, navigation chrome, and dynamic content that AI crawlers often can't reliably parse. The result is that AI tools either skip the content entirely or work from stale, incomplete snapshots.

By publishing clean Markdown on GitHub with a structured llms.txt index, we're giving AI tools a direct, crawl-able path to authoritative ServiceNow content. This means:

• More accurate answers — when you ask an AI assistant about ServiceNow APIs, configurations, or workflows
• Less hallucination — the AI is grounding its response in actual product documentation, not inference
• Faster updates — as we update docs, the GitHub repo updates, and AI tools re-index from source
• Programmatic access — developers can build integrations, internal tools, or RAG pipelines directly on top of the raw Markdown

---

For developers building on ServiceNow

If you're building AI-assisted tools, internal chatbots, or developer workflows on the Now Platform, you now have a stable, structured source to integrate. The Markdown files are clean, consistently formatted, and organized by product area — exactly what you need for RAG (retrieval-augmented generation) pipelines or custom AI grounding.

---

What's next

AI tools take some time to crawl and index new content, so you may not see the full effect immediately — but it's rolling out now.

We'd love to hear how you're using this. Drop a comment below if you've built something on top of it, or if you have feedback on the format and structure.

[xiaix]

Wow... just a simple, amazing wow.  This is bold, awesome, amazing, ... wow.

THANK YOU!

[salma98]

Amazing move. Thanks!

[Ashley Snyder]

I'm still getting blocked despite telling Claude to use llms.txt. Here's what Claude says:

The web_fetch tool in Claude.ai will only fetch a URL if it was either provided directly in the conversation or returned by a prior search result. For ServiceNow's GitHub docs, constructing a URL from the known pattern (raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/{publication}/{file}.md) and fetching it directly doesn't work — Claude rejects it as an unpermitted URL even though the domain itself isn't blocked. The workaround is to paste the raw file content directly from your browser, or share the URL explicitly in the conversation so Claude can fetch it from there.

Does this mean we have to know the exact GitHub URL of the document we want to consume? The issue is, many times, I may know keywords or the product name, but traversing the index of our product documentation to find the exact URL isn't always feasible and it is time consuming due to the complex and hierarchical nature of our product documentation and how we refer to our product names. Are there any plans of ServiceNow allowing the official product document repository to work with MCP clients such as Claude without the additional duplication of content via the GitHub repository?

[Vinod54]

Hello @Ashley Snyder ,
Getting same error when instructed claude to use the github docs of servicenow as source of truth. 

Reason: Given by Claude 

GitHub's robots.txt blocks direct raw fetches unless the URL surfaces through a prior search result. The rendered HTML page (github.com/blob/...) is full of navigation chrome that drowns the actual content. The raw URL (raw.githubusercontent.com/...) is the clean path but hits the robots disallow.

In practice this means: I can land on the right file via search, but I cannot reliably extract its full markdown content in one clean fetch.

I don't think currently we have a workaround for the same, if so please share it here. 

Happy to learn. 

Thanks,

Vinod Kumar