Your AI-assisted article passed spell-check, the style linter and the SEO plugin’s traffic lights. A reader who knows the subject still finds it wrong in ways none of those tools could see.
Table of Contents
What automated checks see, and what they miss
A typical publishing workflow for AI-assisted content has a few automated steps. A linter reads the text for spelling, filler words, dead links and phrases you already overuse. A preview or dry run confirms the structure is right and every image loads. An SEO plugin or a final check confirms the featured image has its sizes and alt text. Reading the rendered page catches another class of fault, because some render bugs pass every check.
In the review this article draws on, all fifteen articles had already cleared steps like these and were live. The corrections were about something no automated step inspects: whether each article was true, first-hand, and easy to follow.
Spelling, filler words, dead links, corpus sameness.
Structure is right, every image resolves.
Featured image has its sizes and alt text.
True for this site? Checked on the site? Would a reader get it?
All fifteen articles were already live: every one had passed stages 1 to 3.
A linter can tell you an article is well formed. Only someone who knows the site can tell you it’s true.
1. Describe what you actually run
An article on FAQ schema read as if a particular SEO plugin were required. In practice that plugin’s route had stopped working after an update, and the site had switched to a small code snippet that needs no plugin. The article described the plan, not the setup that ended up running. Another article explained generating image sizes on demand, and the reviewer asked a simple question: have we done this ourselves? Nobody had.
An AI assistant fills gaps with the typical case, and the typical case is usually the documented route, not the one you took. Before writing or refreshing, look at what is live: active plugins, code snippets and settings. Present a tool as one option and say why you’d pick it. If you don’t do what the article describes, say so plainly. Product tiers need the same care: a table-plugin article listed a feature as free that only ships in the paid version.
2. Check the advice on your own site
Four articles came back with one note: check this on the site itself. All four failed:
- ads.txt: a request for the missing file didn’t return a 404. WordPress guessed the closest-looking page and redirected the crawler to the article about ads.txt.
- Missing pages: made-up page numbers returned the homepage with a 200 status, a soft 404.
- Maintenance mode: the pre-launch maintenance page returned 200 instead of 503, because the plugin’s “send 503” setting never saved.
- Art direction: the site’s own article heroes were the center-cropped background image the article warned against.
Three of those were fixed on the site before the articles went back up, and each fix became the strongest section of its article. A speed article got the same treatment and now quotes a measured baseline instead of generic figures.
When the site breaks its own advice, readers notice before you do.
3. Show the real screens
Three plugin articles came back with “this needs screenshots”: a table plugin, ad-blocker allowlisting, and turning off WordPress’s default widgets. A fourth, on database indexes, needed the ready-made plugin named and tested, not just the theory.
Install each plugin on a disposable test copy of WordPress, capture the WordPress default next to the plugin’s result, and measure where you can. For the index plugin, a lookup that had read 60,000 rows to find one now read a single row, shown in the database indexing article. Use made-up data on the test copy, reset it afterwards, and never try a plugin on the live site first.
4. Use each image once, and never show the hero twice
Four image problems surfaced together:
- One illustration appeared in four different articles.
- One article repeated its own hero image in the body, which “would look ugly”.
- One article had five overlapping figures, which became one comparison grid.
- An article about a visual mistake needed the original images that showed the mistake, not tidy replacements.
Of the six patterns, this is the only one a script can check once you name it: count how many posts use each image file and flag any that appear in more than one. Allow a narrow exception for shared evidence, such as a screenshot of a test result, when both articles say they share it.
5. Take facts from the record
One article described a bake-off against “a diffusion model”. The notes from the work showed it was Gemini writing SVG code, which changes what the comparison means. The article was corrected, and its FAQ now says an earlier version got this wrong.
An assistant reconstructing a week-old event from a summary will smooth it into the most likely story. Your notes, commit history or tickets aren’t smoothed, so check a claim about what happened against them before you publish it. When a published claim was wrong, fix it and say so on the page.
6. Pick examples a reader recognizes
An article on display names and stored values was built on hospital booking labels, from the project where the lesson was learned. The verdict was that a reader could never relate to it. The rewrite uses a website form feeding a CRM, opens with a phone’s contact list, and became show people clean names, send the exact values. A date-ambiguity article used a birth date as its example; it now uses an invoice dated 03/04/2026, which could be March 4 or April 3.
Choose the example most readers have already met: a contact form, a spreadsheet, an invoice. Make sample values obviously made up and business-like rather than personal.
The example you learned a lesson from is rarely the one your reader will recognize.
A six-question review checklist
Ask these before every publish, and note next to each the article that taught it to you:
- Does it describe what you actually run, with tools offered as options and nothing implied that you don’t do?
- Does the advice hold on your own site, with your own dated numbers?
- Does a plugin or interface topic show the real screens, default next to plugin, captured on a test copy?
- Is every image used once, with no hero repeated in the body and no overlapping figures?
- Are the facts checked against the record, with a visible correction when something was wrong?
- Would a general reader recognize the example, and are the sample values neutral?
Only the image question turns into a script. The other five need someone who knows the site. Google’s guidance on helpful, people-first content asks whether content shows first-hand experience, and an AI assistant can’t supply that on its own. Google’s position on AI-generated content is about quality, not how the words were produced.
The short version
Automated checks confirm form, not truth. A review of fifteen live AI-assisted articles found six patterns none of them catch: describe what you really run, check the advice on your own site, show real screens from a test copy, use each image once, take facts from the record, and choose examples a reader recognizes. Write them down as questions, attach the article that taught each one, and ask them before every publish. Automate the one that’s mechanical and keep the rest human on purpose.
Frequently Asked Questions
Does this mean AI-assisted articles are unreliable?
Not in the way people usually mean. None of the fifteen corrections were grammar or style. They were about first-hand truth: the assistant filled gaps with the typical case where the real case was different. A reviewer who knows what was actually done closes that gap.
What should a reviewer look at first?
Start with claims about your own setup and your own site, because they are the most likely to be wrong and the most damaging when they are. Then check every screenshot and example against what a first-time reader would recognize.
Who should do the review if I write alone?
Read it yourself a day later, as a stranger, with the six questions open. Better still, ask someone who uses the same tools to try one step of the article on their own setup; the first place they get stuck is usually a gap the assistant filled with the typical case.
