YouTube Comment Bot Detector: The Nine Fields It Reads, and the One It Never Sees
- A detector extension sees roughly nine public fields per comment plus a handful from the author channel: display name, channel id, avatar URL, text, like count, published and updated timestamps, and t
- The one field carrying YouTube own spam verdict is moderationStatus, and Google documentation says it is only returned when the request is authorized by the owner of the channel or the video. Your own
- The classic academic method needs the list of every comment an author wrote. The v3 commentThreads endpoint filters by video or channel, never by author, so cross-video repetition is the feature most
- Judge a detector by which field it is reading, not by its confidence score. Half the tells people repeat online are also true of every brand new real viewer.
Your video is eleven hours old and the top of the comment section reads like a rota: "Great content, keep it up", "who else watching in 2026", and one account offering a Telegram channel that will teach you to trade. You install a bot detector extension, it starts painting little badges next to names, and within a minute you are trusting a number you cannot see the inside of.
So here is the inside of it. We build AI commenting tools ourselves, which means we spend our working hours on exactly one question: which fields does a machine get to see about a comment and the account behind it? The honest answer is short, public, and much narrower than the marketing on any detector page.
Nine fields per comment. That is the entire evidence pile.
Checked on 2026-09-20 against Google own documentation at developers.google.com/youtube/v3/docs/comments, the comment resource hands an application these snippet properties: authorDisplayName, authorChannelId, authorProfileImageUrl, textDisplay, textOriginal, likeCount, publishedAt, updatedAt, canRate and moderationStatus.
From there a detector can take that authorChannelId and ask for the channel resource (developers.google.com/youtube/v3/docs/channels, same day). That adds snippet.publishedAt, which is the date the channel was created, plus customUrl, country, and the statistics block: subscriberCount, hiddenSubscriberCount, videoCount, viewCount. Google notes in that page that the subscriber number "is rounded down to three significant figures", so a channel with 1,234 subscribers is reported as 1,230 to everybody, including the extension.
That is the pile. No email, no IP, no device, no signup method, no watch history, no phone verification status. Everything a browser extension shows you is a rearrangement of the list above.
The only field with YouTube verdict on it is the one strangers cannot read
Look again at that list and one property is doing something different from the rest. moderationStatus is not a raw fact about the comment, it is YouTube own classification, and its documented values are published, heldForReview, likelySpam and rejected.
Then read the sentence next to it, quoted from the same page: "The moderationStatus property is only returned if the API request was authorized by the owner of the channel or the video."
A bot detector in your browser is a stranger reading a stranger profile. The only account on YouTube that can ask YouTube what it already thinks of a comment is you, on your own channel.
This single clause reorders the whole product category. An extension inspecting someone else comment section is permanently locked out of the platform own verdict and has to rebuild one from name, avatar, timestamps and text. Meanwhile the creator complaining about spam already owns a queue that is populated by that field: the held-for-review and likely-spam buckets in YouTube Studio. The commentThreads endpoint even exposes a moderationStatus filter so an owner can pull those threads directly.
Practical consequence: if the goal is cleaning your own comments, the authoritative tool is your own moderation queue, and a third-party detector is a second opinion. If the goal is judging a comment on somebody else video, nobody has the verdict field and everyone is inferring.
The method that still works, and the two features your extension cannot compute
There is a real literature under all this. The cleanest early example is Mining User Comment Activity for Detecting Forum Spammers in YouTube by Ashish Sureka of IIIT-Delhi, published March 2011, readable at ar5iv.arxiv.org/html/1103.5044 and checked on 2026-09-20. Its sample was 240 users and roughly 13,000 comments pulled from top-rated videos, of which 119 users had more than five comments.
It scored four behaviours: ATDC, the average time gap between a user comments; PCHF, the share of that user comments the platform itself had flagged with a spam hint; CRAV, the same comment appearing across several different videos; and CRR, repetition and redundancy within the set. The paper flagged a user with more than five comments when PCHF exceeded 70 percent, or the average gap fell under 150 seconds, or comment overlap or video overlap passed 0.60.
Those thresholds belong to that study and that 2011 dataset. Do not carry them into 2026 as rules, and be suspicious of any blog that does. What matters more is which of those four features a browser extension can still calculate at all:
- PCHF is gone. It depended on a per-comment spam hint the old API exposed to anyone. The v3 equivalent is moderationStatus, and we just read the sentence restricting it to the owner.
- ATDC and CRAV both need one thing: every comment that author wrote. The v3 commentThreads.list filters, checked on 2026-09-20, are allThreadsRelatedToChannelId, id and videoId. There is no author filter. You can ask for a video threads or a channel threads, never for a person threads.
- CRR survives, but only inside what is already loaded. Duplicate text on the same video is easy. Duplicate text across the forty videos that account also hit today requires crawling those forty videos first, one API call at a time, with maxResults capped at 100 per page.
And every one of those calls is metered. The quota page states that "All API requests, including invalid requests, incur a quota cost of at least one point". We are deliberately not publishing a comments-per-day figure here: when we read that page on 2026-09-20 its own numbers were internally inconsistent, and a made-up division would be worse than no number at all.
What each field honestly supports, and where the guessing starts
| Field the tool reads | What it can honestly support | How it goes wrong |
|---|---|---|
| channel snippet.publishedAt | Account age in days | Every real new viewer is also days old |
| statistics.subscriberCount | Rough audience size | Rounded to three significant figures; may be hidden entirely |
| hiddenSubscriberCount | The owner chose privacy | Read as concealment by tools that should know better |
| statistics.videoCount | Whether the account ever posts | Most real commenters never upload anything |
| authorProfileImageUrl | Default avatar or not | A default avatar is the cheapest thing in the world to change |
| comment publishedAt vs updatedAt | The comment was edited | Editing a typo is not automation |
| likeCount | Whether anyone engaged | Zero likes is the normal state of a normal comment |
| textOriginal | Repetition within this video | Cross-video repetition needs data the API will not filter for |
| moderationStatus | YouTube own likelySpam call | Not returned unless you own the channel or video |
The takeaway you can carry into any tool page: ask which field produced the badge. If the answer is account age plus default avatar plus zero uploads, you are looking at a description of a new real person as much as a bot. If the answer is repetition across videos, ask how it got the author comment history, because the public API does not sell that lookup.
Why the people building comment automation are the ones telling you this
We are not a neutral party and it would be strange to pretend otherwise. NoobClaw writes comments with AI, on accounts that its users log into themselves in a local browser, one fingerprint per account, without ever handing over passwords. That puts us on the other side of the glass from the detector, which is precisely why we know how thin the glass is.
What we see from inside is that the fields above cannot read intent. They read spacing and sameness. An account that posts four identical sentences in ninety seconds looks automated whether a human or a script typed it. An account whose comments are spaced like a person reading, and which says a different thing in each place because each account has its own persona and subject matter, does not hand a detector anything to grab. That is the entire difference, and it is also the argument for keeping a human in the review loop rather than firing and forgetting.
For the writing-style side of this question, which is a different skill from field inspection, we wrote it up separately in how to spot AI comment bots. For what the commercial comment tools actually do, see AI comment bots: what they actually do, and for the rate-and-variation side, AI comment automation without getting flagged. The follower-side version of the same problem is in are my TikTok followers bots. Membership pricing for our own tool is on the website and in the app, and there is a free tier to test with.
Questions creators actually ask about this
Can a Chrome extension really tell whether a YouTube comment is a bot?
It can tell you the account is four days old, has no uploads, uses a default avatar and posted text that repeats on this video. That is a reasonable suspicion signal. It cannot see YouTube own likelySpam flag on someone else video, cannot see the author comments on other videos without crawling them, and cannot see anything about signup or device. Treat the output as a sorted list to review, not a verdict.
Why does YouTube catch spam my detector missed, or the reverse?
Because you are comparing two different evidence sets. YouTube classifier sees signup patterns, device and account-level history that no public API exposes, and writes the result into moderationStatus, a field documented as returned only to the owner of the channel or video. Your extension sees the public fields listed above. Disagreement between them is expected, not a bug.
Does running a detector burn my own API quota?
If the extension uses your API key, yes. Google documentation states every request, including invalid ones, costs at least one quota point, and scanning a busy comment section means many paged requests. When we read the quota page on 2026-09-20 its own figures were inconsistent between sections, so verify your current allowance in your Cloud console rather than trusting any blog arithmetic, including ours.