DEV Community: Intally

I Audited 70 Companies' llms.txt Files. Most Don't Have One.

Intally — Fri, 15 May 2026 17:28:04 +0000

I Audited 70 Companies' llms.txt Files. Most Don't Have One.

The /llms.txt proposal has been around since late 2024. Two years in, every SEO blog has a tutorial on it. Every "GEO" thinkpiece mentions it as a checkbox. WP Engine has published five articles about it in the last month. Mintlify built a feature for it.

What nobody's done is check whether the people who should have one actually do, and whether what they shipped is any good.

So I ran a script over 70 sites — the AI labs, the docs platforms, the dev infrastructure giants, the modern SaaS darlings, the WordPress media — and pulled their /llms.txt. Here's what I found.

TL;DR: 31 of 70 (44%) had a real llms.txt. The other 56% either returned 404, served an HTML fallback (SPA routes catching the path), or 403'd a bot. Of the 31 that exist, 12 (41%) don't follow the format llmstxt.org itself defined. File sizes range from 648 bytes to 280 KB — a 432× spread. The companies you'd expect to lead — OpenAI, Hugging Face, Google AI, Mintlify, GitBook, Readme — don't have one.

What I tested, and how

I picked 70 sites across eight buckets:

AI labs (Anthropic, OpenAI, Mistral, Cohere, Perplexity, Hugging Face, Google AI, Replicate, ElevenLabs)
AI coding tools (Cursor, Codeium, Windsurf, Claude, Aider)
Docs platforms (Mintlify, GitBook, ReadMe, Redocly, Docusaurus)
Dev infra (Vercel, Supabase, Stripe, Cloudflare, Fly, Netlify, Railway, Render, Bun, Deno)
Modern SaaS (Linear, Notion, Retool, Raycast, Framer, Airtable, Segment, Amplitude, Mixpanel, PostHog)
WordPress ecosystem (Kinsta, WP Engine, Yoast, ManageWP, Cloudways, WordPress.com, WP Tavern)
llms.txt origin (llmstxt.org, fast.ai, AnswerAI)
Community / publishing (dev.to, Hacker Noon, Substack, Indie Hackers, GitHub, GitLab)

For each, I fetched https://<domain>/llms.txt with a regular browser User-Agent, no special headers. I parsed the body to check whether it was actual markdown (starts with # heading) or HTML (a SPA fallback catching the route).

Then I measured seven dimensions on each real sample:

File size in bytes
Lines
Number of H2 sections
Total markdown links
Percentage of links pointing to deep internal pages vs. marketing root vs. external
Whether it follows the # Title + > intro blockquote format from the spec
First 200 characters (to spot HTML fallbacks the heuristic missed)

That's it. No login, no API key, no special crawler. Just plain HTTP GET, the same any LLM crawler would do.

Finding 1: More than half of the obvious candidates don't have one

Outcome	Count	%
Real `llms.txt`	31	44%
404	22	31%
HTML fallback (200 but SPA-served)	9	13%
403 / 530 / timeout	8	11%

The 44% headline already sounds bad. But the picture is worse than that, because the "should obviously have one" cohort is the loudest part of the miss list:

OpenAI: 403 on the root, 404 on platform.openai.com. They've built the most-talked-about LLM in the world and don't help it find their own docs.
Hugging Face: 404. The platform whose entire reason for existing is hosting models that read text.
Google AI (ai.google.dev): 302 redirect, no llms.txt at the destination.
Mintlify (the company that sells "llms.txt as a feature" to its customers): 404 on their own marketing site, 530 on their docs site.
GitBook, ReadMe: both 404.
fast.ai: 404. Jeremy Howard's own site. He's the one who proposed llms.txt.
WP Engine, Kinsta, WP Tavern, ManageWP: 404 or HTML fallback. The same WordPress-hosting companies running 5-article-a-month content series about GEO and AI search ranking don't have one.

A reasonable counter-argument: "an llms.txt only helps if your site is what an LLM would link to in an answer; OpenAI doesn't need to optimize for ChatGPT citing OpenAI." Fine. But that doesn't explain Mintlify, whose entire pitch right now is "add llms.txt with one click using our platform." If they don't run their own dogfood, you should ask why.

The HTML fallback group (9 sites returning 200 but with an HTML body) is also revealing. Cohere docs, Cursor docs, Codeium, Windsurf, Claude.ai, Kinsta, Notion, Segment, Deno all fall here. These are companies on Next.js / Vue / similar SPAs where the framework's catch-all route is returning the app shell for /llms.txt. No one noticed. No one's monitoring. An LLM crawler hitting their /llms.txt gets an HTML page that doesn't even mention the word "llms.txt."

This is the most damning category. 404 is a deliberate non-answer. HTML fallback is an unaware non-answer. You ran a tool, you copied a snippet from your CMS, you assumed it worked, and it doesn't.

Finding 2: 41% of the files that exist don't follow the format

The llms.txt spec, as defined by llmstxt.org itself, is dead simple. There are exactly two required structural elements:

A single # Title H1 at the top.
A > blockquote line right after the H1, summarizing what this site is.

That's it. The rest is sections, links, optional ## H2 groupings — all free-form.

Of 29 unique samples (after deduping cloudflare.com / www.cloudflare.com and cursor.com / www.cursor.com):

17 (59%) follow the H1 + blockquote pattern.
12 (41%) skip the blockquote. Some skip the H1 too.

The non-compliant list is not who you'd expect:

Site	Sections	Links	What's wrong
docs.anthropic.com	3	1,415	No blockquote intro
docs.stripe.com	26	528	No blockquote intro
render.com	6	295	No blockquote intro
bun.sh	2	317	No blockquote intro
netlify.com	10	83	No blockquote intro
developers.cloudflare.com	9	103	No blockquote intro
docs.mistral.ai	1	75	Single section, no intro
elevenlabs.io	7	49	No blockquote intro
cursor.com	20	0	No blockquote, and has 0 markdown links — just raw URL list
replicate.com	7	1	No blockquote intro, near-zero links
amplitude.com	7	0	No blockquote, 0 links
supabase.com	2	19	No blockquote intro

Anthropic — the company whose docs platform is literally the reference customer for the LLM ecosystem — ships 150 KB of links with no opening blockquote. Stripe ships 90 KB of structured docs index with no intro line. These aren't beginner sites. They have technical writers.

What this looks like in practice: someone on the platform team auto-generated an llms.txt from the docs sitemap, shipped it, and never read the spec. The crawler hitting it gets a sea of links with no context about what the site is.

Cursor's is the strangest. Twenty sections, beautifully nested, zero markdown links — every entry is a raw URL on its own line:

## Get Started
- https://cursor.com/docs.md
- https://cursor.com/docs/get-started/quickstart.md
- https://cursor.com/docs/models-and-pricing.md
  - https://cursor.com/docs/models/claude-4-6-sonnet.md

It also has at least one concatenation bug: https://cursor.comhttps://cursor.com/changelog.md shows up unescaped. If an LLM crawler was strict about markdown link parsing, half of Cursor's file would be invisible to it.

Finding 3: File sizes vary by 432×, and nobody agrees what this file is for

The smallest real llms.txt: 648 bytes. That's llmstxt.org — the site that defined the spec — pointing to three docs.

The largest: 279,743 bytes. That's PostHog, dumping what looks like their entire docs sitemap, with prose annotations, 54 H2 sections, and 2,555 markdown links pointing to .md variants of every doc page.

Between them, eight orders of practical magnitude:

Bucket	Count	Examples
Tiny (<1 KB)	1	llmstxt.org (648 B)
Small (1-5 KB)	8	railway.app (1.4 KB), supabase.com (1.3 KB), amplitude.com (2.8 KB), replicate.com (3.4 KB), mistral.ai (4.9 KB), cohere.com (4.8 KB), hackernoon.com (4.9 KB), answerai.com (1.8 KB)
Medium (5-20 KB)	9	linear.app, cursor.com, framer.com, yoast.com, wordpress.com, cloudflare.com, elevenlabs.io, docs.mistral.ai, developers.cloudflare.com
Large (20-100 KB)	9	docs.perplexity.ai (22 KB), github.com (28 KB), bun.sh (33 KB), render.com (36 KB), netlify.com (20 KB), stripe.com (64 KB), cloudways.com (64 KB), docs.stripe.com (93 KB), redocly.com (98 KB)
Huge (100 KB+)	2	docs.anthropic.com (152 KB), posthog.com (280 KB)

Median: 9.4 KB. Mean: 34.7 KB. The mean is misleadingly high because of the two huge outliers — most sites are actually quite small.

This spread maps directly to two different philosophies of what llms.txt is. The spec text is ambivalent on this, so people just picked:

Philosophy A (the spec example): llms.txt is a tiny pointer file. A few hundred bytes. A title, a one-line summary, and a handful of links to the most important pages. The LLM is supposed to crawl those pages separately. Sites like llmstxt.org (648 B), supabase.com (1.3 KB), railway.app (1.4 KB), answerai.com (1.8 KB) follow this.

Philosophy B (the index dump): llms.txt is a comprehensive sitemap-for-LLMs. Every documented page gets a link. PostHog (280 KB) and Anthropic docs (152 KB) ship more or less their entire docs map this way. Stripe (90 KB) is the same idea slightly trimmed.

There's no consensus on which is right. Mintlify's product (when it works) emits Philosophy B. Hand-written ones tend toward Philosophy A. A 280 KB file is presumably a lot for a model to ingest as context; a 648 B file is presumably too little for a model to actually find anything useful.

The honest answer is nobody knows yet which works better, because nobody has published data on whether either approach causes more LLM citations or traffic.

Finding 4: Link quality is actually fine — but link quantity hides the misses

The good news: when sites do put links in their llms.txt, the links are mostly useful.

Across all 7,557 markdown links in the 29 samples:

73.8% are deep internal pages (paths with two or more segments — docs.example.com/api/v2/something)
23.3% are external (mostly references to standards, SDKs, GitHub repos)
2.9% point to marketing roots (the homepage or top-level category pages — /pricing, /about)

That 2.9% marketing-root number is encouraging. The fear with llms.txt was that companies would use it as a marketing-funnel SEO play — link the AI to your homepage and your pricing page. They mostly aren't. The actual links point at useful documentation.

The bad news is that count is heavily skewed by a few big files. PostHog alone contributes 2,555 of those 7,557 links — a third of the total dataset. Anthropic, Redocly, Stripe, Cloudways add another 3,000+. Most sites have between 0 and 100 links.

Four sites have zero markdown links: amplitude.com, cohere.com, cursor.com, hackernoon.com. Cursor and Hackernoon use raw URL strings (technically usable by some crawlers, technically not markdown). Amplitude and Cohere just describe their products in prose, which is arguably useful context but not what the spec is for.

Finding 5: The WordPress ecosystem is almost entirely missing

Out of seven WordPress-ecosystem candidates I tested:

Cloudways, Yoast, WordPress.com: have one. ✅
Kinsta: returns HTML fallback (you'd think they had one — they didn't). ❌
WP Engine, ManageWP, WP Tavern: 404. ❌

This is striking because WP Engine in particular has been publishing aggressively about "GEO" — Generative Engine Optimization. Five separate articles in the last month, including "Technical GEO: Ensuring Sites are Machine Readable." The author of those articles works for a company whose own marketing site doesn't have llms.txt.

Kinsta's HTML fallback is the more interesting case. They publish content telling agencies how to make sites AI-friendly. They probably believe they have an llms.txt because someone enabled a plugin. The plugin doesn't work — the Next.js router catches /llms.txt and serves the React shell. Nobody on their team checked.

Across the WordPress ecosystem, the gap between content about llms.txt and ownership of llms.txt is roughly total.

Finding 6: The "HTML fallback" problem is bigger than it looks

The nine sites returning 200 OK with HTML are worth highlighting separately because, from any monitoring tool's perspective, they look like success.

If you run a curl with -I against kinsta.com/llms.txt, you get a 200 response. Your CDN logs say everyone who hit /llms.txt got data back. Nothing's broken.

But the body is the React app. An LLM that tries to parse the response as markdown gets a 50 KB blob of <div class="..."> and JavaScript bundle URLs. It has no way to know this wasn't deliberate.

This affects:

Cohere docs, Cursor docs (sister sites of two of the most-cited Real samples, but the docs subdomains catch-all)
Codeium, Windsurf, Claude.ai — AI coding tools missing their own llms.txt
Notion (the SaaS most likely to be cited by an LLM)
Segment, Kinsta, Deno

Most of these are running modern JavaScript frameworks where a catch-all route handles unknown paths. The fix is one line of config to make /llms.txt 404 explicitly, or to serve a real file. Nobody's done it.

If your site is built on Next.js / Nuxt / Astro / similar, this is the first thing to check. Hit your own /llms.txt with curl and read the bytes. If you see <!DOCTYPE html>, you have a problem regardless of whether you intended to have an llms.txt.

Finding 7: We have no idea if any of this works

The hardest part of writing this audit was admitting that we don't yet have evidence llms.txt does anything useful.

I looked for it. Specifically:

Is there public data showing that sites with llms.txt get cited more often in Perplexity, ChatGPT, or Claude answers than equivalent sites without?
Are LLM crawlers actually requesting /llms.txt? (Cloudflare publishes some bot traffic data, but not specifically for this path.)
Has any A/B-tested case study been published showing that adding llms.txt changed citation share, referral traffic, or anything measurable?

The answer to all three, as of mid-2026, is "not really." There are anecdotes. There are tutorials. There are case studies that read like vendor marketing. There is no rigorous public evidence that llms.txt moves the needle.

It's possible — likely, even — that big LLM providers are reading it as a hint, the same way some search engines read sitemap.xml. It's also possible they're not, and the entire conversation around this file is the SEO industry filling the silence about how AI answer engines actually rank sources.

The interesting fact is that even the companies whose business model would directly benefit from llms.txt working — the model providers — mostly aren't writing one for their own docs. That's either because they know something the SEO industry doesn't, or because they're as confused as everyone else.

What I think this means

A few cautious takeaways. Not advice — llms.txt advice on the internet is already a glut. Just observations from staring at 31 real files for a day.

1. The standard is winning by default, not by adoption. It's the only proposal in this space with public buy-in. But "I've heard of it" and "I've added it to my site" are not the same conversation. Most sites haven't added it. Most that have, half-added it.

2. The Philosophy A vs B divide is the actual open question, not "should you add llms.txt at all." A 648-byte pointer file and a 280-kilobyte sitemap dump can't both be the correct interpretation of the same spec. Until someone publishes real data on which retrieves better, every "best practices" article is guessing.

3. The HTML fallback problem is the single highest-leverage fix. If you run a modern JavaScript framework and you've never checked your own /llms.txt response body, you probably have a silent miss. One curl will tell you. One line of routing config will fix it.

4. Following the spec is almost free, and almost nobody does it. Forty-one percent of the files that exist skip the blockquote intro. The crawler reading these files has to guess what the site is about from the URL list alone. Adding a single sentence in > blockquote form takes ten seconds and probably matters more than the elaborate hierarchy below it. Probably.

5. The gap between "writes about llms.txt" and "has llms.txt" is enormous, especially in the WordPress and hosting ecosystem. This is either an opportunity (everyone else is asleep) or a tell (the people closest to SEO have done the math and skipped it). Take your pick.

The samples

If you want to look at the source data: I'm publishing the 31 real llms.txt files I pulled, plus the probe script and the analysis output, under a public mirror. The format and methodology are simple enough that you can rerun this audit in five minutes against your own list of suspect sites.

Worth doing on your own site, at least. The HTML fallback bug is silent, the spec is short, and the upside — if llms.txt ever does matter — is just a properly-formatted text file away.

If you find your own audit produces wildly different conclusions, I'd genuinely like to see it. Especially if anyone has citation-share data showing this stuff actually works. So far, on this question, the marketplace of opinions is loud and the marketplace of evidence is silent.

About the data: 70 candidate sites probed on 2026-05-16 using vanilla HTTP GET with a desktop browser User-Agent. 31 returned real llms.txt files. After deduping mirror domains (cloudflare.com / www.cloudflare.com, cursor.com / www.cursor.com), 29 unique samples. Probe script, raw responses, and per-site analysis are mirrored.

Method limits: Only the root /llms.txt path was probed. Some sites may host llms.txt at a subdomain or under a versioned path. I didn't check /llms-full.txt (the optional verbose variant from the spec). Sites that block automated requests by IP or User-Agent (Reddit, parts of Indie Hackers) may have real files I couldn't see. The HTML-fallback class is a false-negative risk that probably understates real adoption by 1-3 sites.

Another WordPress AI Writer Plugin? Here Are 4 Honest Reasons We Built One

Intally — Mon, 11 May 2026 22:59:33 +0000

Originally published at intally.hkdfc.net.

Search the WordPress plugin directory for "AI writer" today and you'll find dozens of options. GetGenie, Bertha, AIomatic, ZipWP, CodeWP, ContentBot — big-vendor plugins, indie plugins, subscription plugins, lifetime-deal plugins. All of them exist.

Building one more is a position we have to defend.

We spent months building WP AI Writer, and the reason isn't complicated: the triangle of Chinese-language site owners, bilingual (Simplified + Traditional) publishing, and BYOK pricing is something almost no plugin on the market covers at the same time. Here are the four walls we kept hitting. Decide for yourself whether they're your walls too.

4 walls

Wall 1: OpenAI-only, and the API doesn't reach servers in mainland China

About 95% of the major AI writer plugins default to OpenAI. A few add Claude or Gemini. None of those APIs are reliably reachable from servers inside mainland China — connections time out, or return 403.

The workaround is a proxy. Proxies are unstable, cost money, and get rate-limited. A tool for writing blog posts shouldn't require you to solve a network-routing problem first.

For Chinese-market sites, the more realistic option is to wire in domestic providers directly: DeepSeek, Tongyi Qianwen, Zhipu, Kimi, Wenxin, iFlytek. They're cheap (DeepSeek runs around ¥0.03–¥0.08 per 1500-word article), stable, and compliant inside China.

But almost none of the popular Western AI writer plugins connect to those providers. Their target user isn't you.

Wall 2: Word-count subscriptions, and the markup gets locked in by the plugin

Open any major AI writer plugin's pricing page. The pattern is almost always:

Basic $29/month — 50,000 words
Pro $79/month — 200,000 words
Enterprise $199/month — unlimited

It sounds like a lot, even compared to ChatGPT Plus. The issue is that all those words ultimately go to an OpenAI API call — the plugin is adding a markup on top of the underlying API.

If you have your own OpenAI / Claude / DeepSeek API key, you should in principle pay only the raw API cost. A 1500-word post with GPT-4o-mini costs roughly $0.005. A 1500-word post with DeepSeek costs roughly ¥0.05. Even at 200 posts a month, your raw API spend is $1–$10. The subscription plugin still charges $79.

Where does the rest go? Into the plugin vendor's margin.

Whether that business model is reasonable is a separate question. But if you don't want to pay that markup, what you actually need is BYOK (Bring Your Own Key): a plugin that charges a one-time fee or modest annual license, and lets you pay the API cost directly with no middleman.

Wall 3: Running both a Simplified and a Traditional site means writing every article twice

This wall is specific to the Chinese-language web, and it's invisible to anyone who doesn't operate one. But it's not a language-output problem — it's a workflow problem.

Any plugin can produce Traditional or Simplified Chinese output. You just tell it which one in the prompt. That's not the wall.

The wall is: if you operate both a Simplified site (mainland China / Malaysia / Singapore readers) and a Traditional site (Taiwan / Hong Kong readers), every article goes through publishing twice.

In theory, a glyph-conversion tool could solve this. But glyph conversion doesn't fix regional vocabulary: 软件 ↔ 軟體, 视频 ↔ 影片, 网络 ↔ 網路, 项目 ↔ 專案, 奶酪 ↔ 起司. If you ship an s2t-converted Traditional article, Taiwan and Hong Kong readers can tell at a glance that the author wrote in Simplified.

Our fix is to pair WP AI Writer with our other plugin, wp-zhconvert. Write the article once in Simplified (or Traditional); at publish time, the plugin generates the other variant using an OpenCC dictionary that does region-aware vocabulary substitution, not just glyph conversion. So 视频 becomes 影片 in the Taiwan edition, not just 視頻.

One write, two regional editions.

If you only run a single-variant site, you don't need this feature — the free-tier prompt lets you specify "output in Simplified" or "output in Traditional" and that's enough.

Wall 4: Every Chinese article means tuning a prompt from scratch

This wall isn't technical. It's a time wall.

Getting an AI to produce a Chinese article that's actually publishable means a long prompt. You have to specify: scenario (blog post, product overview, news release, tutorial, comparison review, case study, FAQ, industry commentary), target reader profile, word-count range, SEO keyword distribution, whether to use subheadings, whether to cite data, whether to include an FAQ section, what tone to hit. Writing a prompt template that produces stable output usually takes 5–10 revisions.

Writing one is fine. Writing 12 will take you a week.

What we did is unglamorous: we pre-tuned 12 prompt templates for common Chinese scenarios so you don't have to. Install the plugin and you can pick "blog post + tutorial-leaning + SEO keyword density," or "product overview + decision-comparison + with FAQ section." Each template exposes its parameters in the UI so you can fine-tune.

If 12 isn't enough, Pro supports custom prompt templates — create, edit, delete. Templates can be written in Chinese, English, or a mix; the language isn't locked.

The wall we're solving here isn't "competitors can't do this." It's "save you the time of tuning templates yourself."

Run the numbers

We think BYOK is the better deal for Chinese site owners. Here's the actual math:

Scenario: a content site publishing 60 articles a month, about 1500 words each.

Setup	Monthly	Yearly
Western subscription AI plugin (mid-tier)	$79	$948
WP AI Writer Pro (annual) + DeepSeek API	$79/yr + ~¥3/month ≈ ¥575/yr	~¥575 ($80)
WP AI Writer Pro (lifetime) + DeepSeek API	$279 one-time + ~¥3/month	~¥36/yr from year 2

Roughly one year to break even on the lifetime tier; from year two onward, you're paying API cost at face value.

If you'd rather use GPT-4o, the API runs a bit more ($0.01–$0.05 per article), but you're still an order of magnitude cheaper than a subscription plugin.

Pricing and features, in plain text

We don't hide pricing, and we're explicit about what the free tier actually does:

Free (no purchase, install and use):

All 13 AI providers (BYOK)
12 Chinese prompt templates
Gutenberg sidebar generation
SEO meta auto-fill (Yoast / Rank Math)
5 generations per day

Pro — $79/year or $279 lifetime (5-domain license):

Unlimited generations
AI image generation (DALL-E / Gemini — featured + inline)
AI refine (select text, rewrite with an instruction)
CSV batch generation (up to 50 articles + scheduled publishing)
wp-zhconvert bilingual auto-publishing
Brand voice profiles (AI extracts your style from existing posts)
Real-time SEO feedback
Custom prompt templates

Max — $199/year or $699 lifetime (unlimited domains):

Everything in Pro
REST API (/wp-json/wp-ai-writer/v1/generate)
Team collaboration (multi-author workflow, role-based permissions)
White-label (custom plugin name, logo, colors)

The free tier is genuinely usable on its own — not a 7-day trial, not a feature-stripped demo. What Pro unlocks is scale and automation, not basic functionality.

Who this plugin isn't for

We make a tool, not a miracle. So we'll be direct about who shouldn't buy it:

You write only English for Western readers. Stick with GetGenie or Bertha. Their OpenAI integrations are mature and their English prompt libraries are more ready-made out of the box.
You're happy with your current subscription plugin and the monthly fee doesn't sting. BYOK savings aren't a priority for you, and the cost of migrating may exceed what you'd save.
You only run one variant of Chinese — Simplified only or Traditional only — with no bilingual workflow. Wall 3 doesn't apply to you. The other three (domestic providers, BYOK, pre-tuned templates) still might — judge on your own value.
You want one button that ranks #1 on SEO automatically. That doesn't exist, and anyone selling it is selling air. We can help you cut "blank page → 60% done" significantly. The remaining 40% — editing, fact-checking, voice — is still your work.

Who this plugin is for

WordPress operators in mainland China: native provider support, controllable cost, no proxy required
Cross-border e-commerce and bilingual brand sites: Simplified + Traditional auto-publishing, plus both English and Chinese prompt templates
Overseas Chinese bloggers: you write Chinese, you want BYOK pricing, you don't want to be locked into a subscription
Small content agencies / SEO shops: CSV batch + scheduled publishing + multi-domain licensing (5 on Pro, unlimited on Max) fit a multi-site portfolio
Developers: the Max REST API lets you call generation from your own workflow

Try it

WP AI Writer is live on Intally, and the free tier installs and works without a purchase. Pro and Max are available as either lifetime or annual.

If you install and find a provider we don't support, or a Chinese prompt template that doesn't match your use case, email us or drop a note in our Telegram group. We'll add it. We didn't build this plugin to ship-and-vanish; we built it because the gap was real.

WHMCS Alert Email Spam? 4 Solutions Compared for 2026

Intally — Fri, 08 May 2026 16:08:58 +0000

Originally published at intally.hkdfc.net.

WHMCS alert spam at 3 AM: 4 paths out, with the actual math (2026)

3 AM, phone buzzes 50 times. Not a traffic spike. It's WHMCS, faithfully emailing every invoice paid notification because the default alerting has no dedup, no cooldown, no quiet hours. Every invoice state change is one email. If you run WHMCS, you've been there.

Worse: built-in alerts only do email. No Slack, no Telegram, no Discord, no SMS. Maintenance window? Every customer alert still pings the on-call phone, no built-in silence. On-call rotation for a small team is basically not a thing. Either every admin gets every email, or one person eats it 24/7.

Quick disclosure: I run Intally (a small WHMCS / WordPress plugin shop) and one of the four options below is something we built. So this isn't neutral, but I tried to write it honestly, which means flagging the cases where you should not pick option 4.

The four real paths

There are basically four ways to fix this in 2026:

Patch WHMCS default emails and write your own hooks
Pipe WHMCS into an external SaaS monitoring tool (PagerDuty, Opsgenie, Datadog)
Buy a WHMCS Marketplace alert module from ModulesGarden or CodeCanyon
Install a dedicated WHMCS alert plugin (Smart Alerting Hub style)

Below is what each one actually costs in money and time, for a solo or small hosting shop.

Option 1: roll your own with WHMCS hooks

Best fit: teams with at least one backend dev who already knows WHMCS hooks.

Cost: 0 dollars, free as in beer
Effort: high. You need to know WHMCS hooks (InvoicePaid, TicketOpen, OrderAdd, dozens of them), write PHP for dedup (Redis or a custom table), Slack webhook forwarding, Telegram bot calls
Channels: as many as you write. Theoretically unlimited
Maintenance: hook names shift between WHMCS 8.x and 9.x. Every new channel is a new adapter. Realistically 1 to 2 engineer weeks per year
Catches:
- Maintenance silencing ends up as one-off hacks scattered across hooks.php
- On-call rotation, you design the schedule logic yourself
- Alert history, replay, retry on failure, all built from zero

If you have a dev who's done WHMCS hooks before and your needs are weird enough that no plugin fits, fine. Otherwise year-one math looks free and year-three math doesn't.

Option 2: external SaaS monitoring

Best fit: shops already running PagerDuty or Opsgenie for infra.

Pricing: PagerDuty starts at $19/user/month. Opsgenie $9 to $29/user/month. Datadog by event volume
Effort: medium. WHMCS side, write hooks that fire webhooks into the SaaS. SaaS side, configure routing, channels, on-call schedules
Channels: very wide. SaaS providers ship 30+ integrations out of the box. On-call, dedup, silence, all mature
Catches:
- Per-user pricing scales painfully. 10 admins on PagerDuty standard is $190/month, $2,280/year
- SaaS doesn't read WHMCS events natively. You middleware through webhooks, so "invoice paid" arrives as a generic incident, stripped of business context
- For most small shops, paging via PagerDuty for invoice notifications is like calling the SRE team because someone's coffee is cold

If you're already paying for PagerDuty for infra, adding WHMCS is cheap. If not, overkill.

Option 3: WHMCS Marketplace alert modules

ModulesGarden, CodeCanyon. Search "WHMCS notification" or "WHMCS alert."

Price: $179 to $499/year, ModulesGarden tier
Effort: medium. Install, configure, plug in Slack or Telegram credentials
Channels: depends on the plugin. Most cover email plus 2 to 3 channels
Catches:
- Most older plugins do "email plus Slack" and stop there. No dedup, no cooldown, no on-call rotation
- Maintenance is uneven. If the latest release is from 2024, skip it. WHMCS 8.6 and 9.0 already shifted hook semantics
- 5-year cost runs $900 to $2,500, and you may still end up writing hooks to cover the gaps

Two things to check before you buy: does it actually do dedup or just forwarding, and was it updated in the last 90 days.

Option 4: a dedicated WHMCS alert plugin

Smart Alerting Hub style plugins do the full loop: WHMCS events, multi-channel routing, dedup, on-call rotation, all in one module.

Price: free tier works, Pro is $69/year or $249 lifetime
Effort: low. Install, configure channels (paste a Slack webhook, a Telegram bot token), pick which events to subscribe
Channels: 8 standard (Email, Slack, Telegram, Discord, WhatsApp, SMS, PagerDuty, custom Webhook), no adapter writing
WHMCS events: 26 (invoice, ticket, order, service, client, network, admin)
Pro features:
- Alert dedup with cooldown windows (same event N minutes, only one push)
- Maintenance silence windows (toggle on, alerts paused, no losses)
- Custom message templates ({{variable}} placeholders, override per channel or per event)
- On-call rotation (weekly cycles plus event filtering)
- Alert digest (hourly or daily batched summary)
- Unlimited alerts plus configurable history retention
Catches:
- Free tier caps at 100 alerts/day, which a mid-size shop blows through in one busy day. Free also limits you to email plus one extra channel
- No cross-platform incident escalation in the PagerDuty sense (Slack to phone call to manager-on-call)
- Less customizable than raw hooks, though templates cover ~90% of real cases

Best fit: small to mid WHMCS hosting shops (under 50 admins) needing multi-channel alerts plus on-call plus dedup, without the per-seat SaaS bill.

Side by side

Option	Effort	Monthly / yearly cost	Channels	Dedup / on-call / silence	5-year cost
Roll your own hooks	High	0	As many as you write	Build it yourself	1-2 engineer weeks/yr
External SaaS	Medium	$19+/user/month	30+	Full	10 users ~ $11k
Marketplace module	Medium	$179-499/yr	2-3	Usually missing	$900-2,500
Dedicated plugin (Smart Alerting Hub style)	Low	Free or $69-249 once	8	Full (Pro)	$69-249

Pick by team size

1 to 3 people, under $5k/month: option 4 free tier. 100 alerts/day plus email plus one Slack channel covers it
3 to 15 people, $5k to $30k/month: option 4 Pro. $69/year unlocks dedup, on-call, silence
10 to 50 people already on PagerDuty or Opsgenie for infra: option 2. Unify incident management, eat the per-seat cost
50+ people with dedicated backend: option 1 plus option 4 or 2 mixed. Big shops have enough custom logic that off-the-shelf doesn't quite fit

A shortcut if you go with option 4

The Smart Alerting Hub plugin is the one we built, free tier installs in a few minutes. Out of the box:

Dashboard for channel health and alert stats
Configure Slack, Telegram, Discord webhooks from the WHMCS admin UI, no code
Alert history, replayable, retryable, filterable

Pro ($69/year or $249 lifetime) unlocks the things you only need once the team grows: cooldown windows, on-call rotation, maintenance silence, custom templates. If you're under 3 people and under 100 alerts/day, free is enough.

If you end up picking option 1, 2, or 3, that's fine. The reason I wrote this is so you don't pick the cheapest-looking thing and six months later realize you needed dedup and on-call all along, stacking three tools to do what one would've done. The most common WHMCS alert budget overrun I see is "just add Slack" turning into "actually we need dedup, on-call, silence" later. The rebuild costs 5 to 10x the up-front difference.

WHMCS alerting in 2026 is still underrated. Most shops treat "alert equals email" as a law of physics. Written against actual May 2026 data.

If your setup or pricing differs, I'd like to know. Drop a note at @intally_channel and I'll update the article.

Accepting Alipay in WHMCS: 4 Options for 2026, with the Actual Math

Intally — Fri, 08 May 2026 14:12:33 +0000

Originally published at intally.hkdfc.net.

Accepting Alipay in WHMCS: 4 options for 2026, with the actual math

WHMCS ships with PayPal, Stripe, and credit card gateways out of the box. If you want to take Alipay (mainland China), or HKD/USD paid via an Alipay+ wallet from a customer in HK / Taiwan / Singapore / Malaysia, WHMCS gives you nothing.

If you sell hosting and any meaningful slice of your buyers is Chinese-speaking, missing this rail probably costs you 30 to 50 percent of would-be conversions. tbh I underestimated this for years.

Quick disclosure before the math: I run Intally (a small WHMCS / WordPress plugin shop) and one of our plugins is in option 4 below. So this isn't neutral. I tried to write it the way I'd want someone else to write it for me when I was comparing, which means showing the cases where you should not pick option 4.

The four real paths

There are basically four ways to do this in 2026:

Build it yourself against the Alipay Open Platform SDK
Use a third-party payment aggregator (LianLian, cross-border acquirers, Stripe-Alipay, etc.)
Buy a ready-made WHMCS module from ModulesGarden or CodeCanyon
Integrate Antom directly (Ant International's official API, the thing Alipay+ runs on)

Below is what each one actually costs in money and time, if you're a solo or small hosting shop.

Option 1: roll your own against Alipay Open Platform

Best fit: teams with a dedicated backend dev and high volume.

Fee rate: 0 percent platform cut. Bank settlement charges 0.1 to 0.2 percent on top
Monthly fee: free
Integration effort: high. RSA2 signing, callback verification, WHMCS gateway hooks (gatewayCallback, refundCallback), plus a reconciliation script
Settlement: T+1 to your merchant bank
Maintenance: Alipay's API changes every 1 to 2 years. Signing, async callbacks, refund reconciliation, each has sharp edges. Realistically 2 to 3 weeks of engineer time per year, ongoing
Docs: all in Chinese, and not great. Noticeably rougher than what you'd expect from a Stripe-tier SaaS

If you're under $20k/month in volume and don't already have a backend dev who reads Chinese docs comfortably, this is not where I'd start.

Option 2: third-party aggregators

Best fit: low volume, no dev appetite.

Fee rate: 2 to 4 percent. LianLian around 2.5 percent, Stripe-Alipay around 3.5 percent, others vary
Monthly fee: usually free, some charge $30 to $50/mo
Integration effort: low. There are existing WHMCS modules, you fill in 3 to 5 fields
Settlement: T+1 to T+3
Catches:
- Stripe-Alipay is restricted in mainland China. Some IP ranges get blocked outright
- Many aggregators don't actually support ALIPAY_CN. They support the Alipay+ wallets used in HK / TW / SEA, which is a different rail
- KYC requirements are not lighter than going direct. You still need the same paperwork

Quick math. If you do $5,000/mo and pay 2.5 percent, that's $125/mo, $1,500/yr, $7,500 over 5 years. For a lot of shops that's more than the one-time KYC pain of going direct.

Option 3: WHMCS Marketplace modules

ModulesGarden, CodeCanyon, etc. Search "WHMCS Alipay" and you'll find them.

Fee rate: the plugin itself is 0 percent. The underlying rail might not be
Price: $179 to $499/yr typical, ModulesGarden pricing
Integration effort: medium. Install, configure, test against your merchant account
Catches:
- A lot of these plugins are wrappers around an aggregator. So you're paying both the aggregator's 2 to 4 percent cut and the plugin's annual license fee. Double dipping yourself
- Maintenance varies wildly. If the latest release is from 2024, skip it. Alipay's API has shifted at least once since then
- Most of them ship encrypted source. When something breaks you're filing a vendor ticket and waiting

Two things to check before you buy: does it call the official API directly, and has it been updated in the last 90 days.

Option 4: integrate Antom directly

Antom is Ant International's unified payment API for overseas merchants. The consumer-facing brand is Alipay+. It covers ALIPAY_CN (mainland) plus the HK / TW / Japan / Korea / SEA wallets in one integration.

Fee rate: 0 percent platform cut. Your real rate lives in the Antom merchant contract, typically 1.5 to 3 percent. Lower than the aggregators
Monthly fee: free
Integration effort: medium. RSA256 signing, callback handling, plus KYC (about 1 week)
Settlement: T+1 to your merchant bank
Catches:
- KYC needs a HK / Singapore / Malaysia (or similar) entity. A pure mainland entity goes through domestic Alipay, which is a different rulebook
- Docs are in English and genuinely good. Better than the Open Platform docs imo
- Get the timestamp or signature wrong by one byte and the whole flow fails. Sandbox debugging usually takes 2 to 5 days the first time

Side by side

Option	Cut	Fixed cost	Effort	Settlement	Long-term cost
Build your own	0%	0	High	T+1	2 to 3 weeks/yr maintenance
Aggregator	2-4%	0 to $50/mo	Low	T+1 to T+3	Compounding cut forever
Marketplace plugin	0-2% (depends on rail)	$179-499/yr	Medium	T+1	Annual license + possible double cut
Antom direct	1.5-3%	0	Medium	T+1	One-time KYC

Pick by monthly volume

Under $500/mo: aggregator. The total cut is small in absolute dollars and you save the engineering hours
$500 to $5,000/mo: Antom direct. 1.5 to 3 percent beats aggregator 2.5 to 4 percent over time, and your rate gets negotiable as volume grows
$5,000 to $30,000/mo: Antom direct. The savings here pay for half an engineer
$30,000+/mo: build it yourself or stay on Antom direct. Depends on team bandwidth

A shortcut if you go with option 4

The bottleneck for option 4 is the integration. If you don't want to write the RSA256 signing, the callback dispatcher, and the WHMCS gateway glue from scratch, there are pre-built plugins that do it for you.

Mine is one of them. antom-gateway, free tier:

ALIPAY_CN QR code in the invoice page, no off-site redirect
RSA256 signing plus platform public key verification
Multi-region API (Asia / North America / Europe) switchable via dropdown
11 currencies with correct decimal handling
One-click refunds
Sandbox / production toggle

Once you have your Antom credentials, integration goes from "3 weeks of dev time" to "fill 7 fields and save."

If you end up picking option 1, 2, or 3 instead, that's fine. The reason I wrote this is so you don't pick X and six months later realize Y was the better fit.

WHMCS-plus-Alipay is still a niche topic. Most English teutorials are 2020-era. This is written with May 2026 data.

If your setup differs, ping @intally_channel.