AI-written text often gives itself away before the end of the first paragraph: a long dash every other sentence, a sentence announcing the plan, three adjectives where one would do. If you publish articles, posts or pages drafted with a model, you have probably wondered whether it shows, and whether you should run your writing through a detector before it goes live.
I write this blog with a content machine I built, and I say so plainly. What I care about is that the articles are good, not hiding where they came from. Here are the signs I watch for, why I don't trust detectors, and the concrete checks my tooling runs before every article is published.
01The signs of AI-written text, and why none is enough on its own
The most familiar signs are about form. The em dash used everywhere. Sentences that announce what comes next instead of saying it. The "it's not X, it's Y" construction. Lists that always come in threes. Emphatic adjectives and essay-style connectives. Bullet lists where every line opens with a bold word and a colon. A very even rhythm, where every sentence is the same length.
The trouble is that none of these signs proves anything on its own. The guide kept by a group of Wikipedia volunteers on signs of AI writing says so in its introduction: models learned from human writing, and many of these turns of phrase turn up in editorials and blogs written by hand. The same guide asks editors not to treat the signs as the problem to fix, because the real faults run deeper.
The linguist Taylor Jones makes a similar point in a video I found useful, How to Detect AI Slop. Groups of three and asides, he says, are classical rhetoric; together they are suggestive, on their own they say nothing. The sign he trusts most is elsewhere: words that sit well together but mean nothing once combined, metaphors that contradict each other in the same sentence. I see it often in the first drafts I review: a sentence that sounds right and falls apart when you read it slowly.
02Why I don't trust detectors
The temptation is understandable: paste the text into a tool, read a percentage, decide. I don't, and the model makers themselves give good reasons to be wary.
In January 2023, OpenAI released a classifier meant to flag AI-written text. On its test set, it identified 26% of generated texts as "likely AI-written", and wrongly labelled 9% of human texts the same way. The page says it was very unreliable below 1,000 characters, much weaker in languages other than English, and that edited text could slip past it. OpenAI withdrew it on 20 July 2023 because of its low accuracy.
Published research points the same way. One team showed that several widely used detectors wrongly flag writing by non-native English speakers as AI-generated, and that a simple prompt is enough to get around them. Another team tested recursive paraphrasing against a wide range of detectors, including watermark-based ones: detection drops sharply while text quality barely suffers.
I take a simple rule from this. A detector can be a warning, never a verdict. And for your own writing, it asks the wrong question: knowing whether a text "passes" tells you nothing about whether it is accurate, useful or sourced.
03What Google looks at: quality, not origin
Many people who ask me about this are really thinking about search. The official answer is clear. In its guidance about AI-generated content, Google Search Central says it focuses on the quality of content rather than how it is produced. What breaks its rules is automation used mainly to manipulate rankings.
The same page recommends author bylines where readers would expect them, and AI disclosures where someone might wonder how the content was made. That is what I do: my articles are signed, and I say how they are written. I go into more detail in my content machine with human review.
So the useful question for your writing is whether it is worth reading. Whether it looks human comes second.
04The checks I run before publishing
Rather than detecting AI after the fact, I chose to block its tics before publication. Every article on this blog goes through a command that rereads the final text and returns a red, amber or green verdict. A single red blocks publication. The rules live in a configuration file the tool reads, not in the prompt: a rule repeated in a prompt gets forgotten, a rule in the config blocks.
A red list and an amber list
The red list holds what never gets through: the em dash, sentences announcing the plan, invitations to "get in touch with any questions", phrases warning that something important is about to be said, a handful of consultant words. A single one of these makes the gate red.
The amber list holds about twenty words to avoid, mostly emphatic adjectives and essay-style connectives. A single amber passes, as long as I justify it in writing. More than two in the whole article turns it red. That threshold matters more than the list itself: it lets the right word through and stops the pile-up, which is what really gives a generated text away.
Voice counters
The same check counts first-person markers: fewer than 4 is red, fewer than 10 is amber. Fewer than 5 uses of "you" is amber. It also looks for a passage grounded in practice. An impersonal text reads like every page already indexed, and that is often the first fault of a generated first draft.
Formatting rules
Paragraphs stay under 110 words, and sentences average no more than 24 words. Three or more bullets in the "bold word, colon, text" format are red. Headings keep a capital on the first word only. Each of these rules matches a fault I have seen come back in production.
Test articles that must stay red
When I change a rule, I can weaken the check without noticing. So I keep test articles that are deliberately bad, packed with every tic of generated writing. A command replays them: if one of them comes out green, the test fails.
05Making AI text sound natural without disguising it
The check removes tics, but it gives the text nothing to say. For that, I rely on two steps, one before drafting and one after.
Before: the brief. I don't let a model write until it has an angle, sources read one by one and questions real readers have asked. The angle can only draw on a closed list of published facts about my work. That is what gives the text something to say. I describe what the model receives in my article-writing prompt, layer by layer, and how I check every source before publishing.
After: a dedicated rewriting pass, with a skill built on the signs listed in the Wikipedia guide. In practice, this is what I look for when I reread:
- A sentence that announces instead of saying: I delete it and keep the next one.
- An "it's not X, it's Y" construction: I just say Y.
- A list of three for no reason: I keep the items that matter, sometimes only one.
- A fancy verb standing in for "is" or "has": I go back to the plain verb.
- A sentence that sounds good: I read it slowly and check that it means something.
- A claim with no example and no source: I add one, or I cut it.
The last two are the ones Taylor Jones points to as the most telling, and they are also the slowest to fix. They require knowing what you are talking about.
06The limits of this method
The Wikipedia guide is right on a point that concerns me directly: treating the signs as the problem can simply make detection harder. A hollow text, cleaned of its tics, is still hollow. My check only makes it less visible. That is why the brief blocks drafting upstream, and why the check alone would not be enough.
The lists are a judgement call too. Some words on the amber list are sometimes the right ones, and I then have to justify them. On the other hand, models produce new tics my lists do not know yet. On an engagement, a proofreader's feedback became written rules in the pipeline; that is the only way I have found to keep the list up to date.
Finally, all of this needs a human review. Every article goes live with a "to review" status, and I read it on the site before marking it "Reviewed". I describe that step in the reviewer's work, pass by pass.
07Where to start with your own writing
On Monday, take the last three pieces you published with a model's help. Read them slowly, sentence by sentence, looking for what means nothing and what has neither an example nor a source. Note the phrasings that keep coming back from one piece to the next.
That list is the start of your own rules. Write it down, give it to the model before it writes, and check afterwards that it was followed. Once you can reread it without thinking, you can automate it.
If you would like to set up this kind of check on your own content, I build it in short engagements, and my services explain how I work. Happy to talk it through.