AI blog post validator

The category collapses two unrelated tasks into one interface. Task one is measurement: counting characters in a title, checking that a heading level is not skipped, confirming every image carries an alt attribute, establishing that a link resolves. Task two is criticism: deciding whether an introduction answers the question its title poses, whether a section earns its heading, whether a claim is supported or merely asserted.

The first task is arithmetic and has exact answers. The second requires reading and produces arguments. Tools that return a single composite score are averaging the two, which makes the number unfalsifiable in both directions. This route does the second task and none of the first, and says so, which is a smaller claim and a checkable one.

Two of the scoring tools in this space publish bands: one says a score above 80 indicates strong SEO structure and 60 to 79 needs optimisation, another says 80% or above is good. Neither page states whether its number is produced by rules applied to the text or by a model asked to grade it. That omission is the whole question, because the two things behave completely differently when you are wrong.

This route is a generator: the system prompt asks it to produce content matching the format the tool name implies. A score emitted under those conditions would be language, shaped like arithmetic. It would also be sticky in the way grades are, since a number that clears a threshold terminates the review, while a written objection to your fourth section has to be read and either accepted or argued with.

The controllable variable is the brief. Everything else about the output follows from it.

Step 1

State the target query, the reader's prior knowledge and the single proposition the piece must establish, then paste the draft beneath them.

Step 2

Constrain the read if you want depth over breadth, using the 300 character instruction to limit it to structure, or to the argument, or to the opening.

Step 3

Resolve the criticism first, then perform the arithmetic checks separately, since a good review will not mention a title that is nine characters too long.

Worth stating precisely rather than as a disclaimer, because several competitors in the set do operate on live pages.

No URL retrieval

Nothing here fetches an address. The only outbound calls this route makes are to the rate limiter and to the model provider.

No link validation

Follows from the above. A dead link in the draft is invisible to the review because nothing attempts to resolve it.

No corpus

There is no index, so duplicate and stitched-together content is out of reach. That is the case detection tools find hardest anyway.

No formula

Flesch Kincaid, Gunning Fog, SMOG, Coleman Liau and the Automated Readability Index all count syllables and sentence lengths. None of that computation exists here.

No rendered page

It reads your pasted text, not what your CMS produces from it. Template-level problems are outside the frame.

Given a draft alone, a model can only evaluate the draft against general expectations of what a blog post is. That produces notes about paragraph length and transitions, which are true and nearly useless. Given a query, an audience and a goal, the same model can evaluate the draft against a purpose, and the notes become falsifiable: this section does not serve that goal, this paragraph assumes knowledge the stated reader does not have.

This is the structural reason the input on this route is labelled a brief rather than a document. It is also why five runs a day is not the constraint it looks like. A well-briefed pass produces more to act on than three unbriefed ones, and the second run on the same draft usually tells you what the first one already did.

Title and description length are where drafts fail most often and where the published guidance is least consistent. This repository's own audit script enforces 60 characters for a title and 160 for a description and refuses to pass a page that exceeds either. One of the checkers in this result set publishes 40 to 70 characters as its title range without citing a source.

Both are conventions about what survives truncation in a results listing rather than rules issued by anyone, and presenting them otherwise is how this category accumulates folklore. The same applies to word count. Figures such as 800 words as a floor and 1,200 to 2,000 for competitive topics appear in these tools as though they were mechanics. They are assertions about a third party's ranking behaviour, unverifiable from here, and they are not repeated as advice.

One pre-publish check is neither criticism nor judgement. Text drafted in a chat interface and pasted into a CMS can carry invisible characters through: zero-width spaces and joiners, a word joiner, a byte-order mark stranded mid-document, no-break and narrow no-break spaces indistinguishable from ordinary ones, and directional controls.

The local scanner on this site handles exactly 14 of them by codepoint, in the browser, with no model and no probability involved. The consequences are mundane and persistent: broken find-and-replace, mangled slugs, a term that will not match in search. Run it last, after every edit, because a later paste reintroduces what an earlier clean removed.

No ranking outcome is predicted here and no change suggested by this tool is claimed to move a page in search results. That is not caution for its own sake. The mechanism by which a search engine orders results is not observable from a text editor, and any tool asserting otherwise is selling a correlation it has not demonstrated.

Detection is the same shape of problem. This does not estimate whether a draft will pass an AI classifier, and the honest position is available from the round-up in this result set: the classifier it examined is not foolproof and produces both false positives and false negatives. A pre-publish routine organised around satisfying such a tool is optimising against an instrument nobody can calibrate.