Disclosing AI Use in Articles: When and How

Disclosing AI use in an article means telling readers, in a short and honest note, how the content was made. Google's search documentation treats this as a suggestion for web content, not a requirement; the firm requirements it describes sit in product feeds such as Merchant Center. If you run a design agency's blog or any publication where tools help produce text and images, the real question is not "must I label?" but "would a reader reasonably want to know, and how much should I say?"

Short answer: add a one- or two-sentence note when a tool produced the bulk of a text or an image, say what the tool did and who verified it, keep the author's name on a person who answers for the piece, and skip the note when a tool only checked spelling or helped with research.

What Google asks for, and what it only suggests

Start with the wording. On its page about using generative AI content (Opens in a new tab), Google says that explaining how content was created can give readers more context, and it encourages authors to consider adding information about how their content was created in a way suited to their audience, such as describing how automation was used. The language is "consider" and "can help". It is advice.

The page on creating helpful, reliable, people-first content (Opens in a new tab) puts the same idea under a "how" heading. It asks whether the use of automation, including AI generation, is self-evident to visitors through disclosures or in other ways, and it says such disclosures are useful where a reader might wonder how something was made and should be considered where reasonably expected. Again, the verbs are advisory.

Where the language turns into a requirement

The generative AI page describes a different tone for ecommerce. It states that Merchant Center policies require AI-generated images to carry IPTC DigitalSourceType metadata with the value TrainedAlgorithmicMedia, and that AI-generated product data such as titles and descriptions must be specified separately and labeled as AI-generated. That is a product-feed rule. A blog post, newsletter or agency case study does not fall under it: Google's documentation has no statement that extends it to such content. Google's documents can change, so confirm both pages before you build a policy on them.

Keeping this split straight prevents two errors: telling the team that every article must carry a badge, and ignoring a real requirement in a product feed because "disclosure is optional".

Why a reader wants to know

The who, how and why of a page

Google's helpful content page frames trust around three questions: who made this, how was it made and why. A reader judging a piece weighs all three. If the "how" is hidden, readers fill the gap with an assumption, and the assumption might be harsher than the facts.

What the review example teaches

For product reviews, the same page suggests explaining how many products were tested, what the results were and how testing was done. The principle carries over to production notes: say what was done, who did it and how it was checked. A disclosure is a short answer to a question the reader has not asked yet.

What a note cannot do

A note does not make a text accurate. It does not remove the author's responsibility. For AI-assisted writing, verification comes before disclosure; the practices for that are covered in AI-written articles and human editing.

A four-step scale for deciding

Google's documentation sets no threshold. It contains no statement of the form "disclose past this amount of AI contribution". So the threshold is yours. Practical suggestion: classify tool involvement on four steps and decide once, in writing.

Step four is closest to Google's "reasonably expected" test, since a reader may assume a person wrote the whole text. Step three is a gray zone: if the writer rewrote every sentence and verified every claim, the text is in practice the writer's work, and the decision rests on your policy.

Mixed pieces

Many pieces do not fit a single step. A case study might have a human-written introduction and a tool-drafted summary of project outcomes. Put the note where the tool-made part sits, at section level, rather than labeling the whole page. A page-wide label hides the human work; no label hides the tool work.

Wording that works

Good notes are short, concrete and plain. They name the job the tool did and the person who checked it. Adapt these samples.

Light involvement

A spelling and grammar tool was used on this piece. The text and all facts were written and checked by our editor.

Draft involvement

An AI tool produced the first draft of this section. The author rewrote it and checked each claim against its source.

Body generation

The bulk of this text was written with an AI tool. An editor compared every claim with its sources and corrected the draft. Responsible editor: author name.

Each sample states the job, names the checker and avoids tool branding. Google's documentation does not ask for the tool's name, so naming it is optional.

Phrases to avoid

Tone

A note should neither apologize nor boast. "Unfortunately we used AI" reads as a confession; "crafted with cutting-edge AI" reads as an ad. Neither answers the reader's question. State what happened in the same tone as the rest of the site.

Placement: where readers will look

Google's phrase "where reasonably expected" ties placement to where a reader would look. Readers look at the byline, the start of the text and the end.

Practical suggestion: explain the general method once on a page, then put a short note on each relevant article that links to it. Do not tuck the note into a corner that small screens or screen readers skip; keep it in the text flow.

When readers ask questions

A short note invites follow-up. A "how we make our articles" page answers three questions: what do we use tools for, how are sources chosen, what does the editor check? Keep it brief and dated. Reader questions become the list of lines to add in the next version.

Keeping the author's name meaningful

The helpful content page asks whether it is self-evident to visitors who authored the content and whether pages carry a byline where one might be expected. It encourages accurate authorship information and treats made-up names or false credentials as deception. For disclosure, the consequence is simple: a tool's name never replaces the author's, and no fictional author is invented.

The byline answers "who" and the note answers "how". Together they show the reader the production method and the person accountable. See how to build an author page for E-E-A-T for the author side and the page-level E-E-A-T checklist for a broader audit.

Images and metadata

A separate decision from the text

Whether to disclose a tool-made image is independent of how the text was written. An illustration made with a tool may deserve a caption note even if a person wrote the article. If the image is decorative and not presented as a photograph, a short caption phrase such as "illustration generated with an AI tool" is enough.

Metadata

Google's page recommends adding image metadata. For ecommerce it names the IPTC DigitalSourceType value TrainedAlgorithmicMedia as a Merchant Center requirement. For blog images the page states no requirement, though marking the file gives a machine-readable counterpart to the caption. Treat it as a low-cost habit, not a rule.

When disclosure is not enough

Unverified text

A label does not fix a wrong claim. Google's page says it is critical to manually fact-check and review all AI-generated content for accuracy and trustworthiness before publishing; disclosure sits on top of that check, not in its place.

Mass-produced pages with no value

The same page says generating many pages without adding value may violate Google's spam policy. Stamping "AI-assisted" on each page does not change that. The page must give the reader something; a note only describes how it was made.

Misleading authorship

A fabricated author profile with an "AI-assisted" label underneath is still deception about who stands behind the text. The note and the byline must tell the same story.

Example: a note that falls short

Example scenario: A design agency blog posts a comparison of two portfolio platforms with the sentence "This post was produced with AI assistance." The feature table inside the post came from a tool's guess and nobody opened the platforms' own pages to confirm it. The note exists, but the reader still does not know what was done, what was checked or who is responsible. When a platform's owner points out two wrong entries, the note offers no protection; it shows that checking was skipped. The fixed version states that a tool drafted the table, that an editor compared each cell with the platform's own documentation and names that editor. The fix is in the verification, and the note follows from it.

Who writes and approves the note

Spread the work over three roles. The author declares tool use. The editor sets the involvement step and writes the note. The publisher sets the threshold and the note template. Authors may rate their own involvement low because writing a note feels like extra work, so the classification belongs to the editor.

Outside contributors and agencies belong in the chain too. Put one question on your brief or submission form: did you use an AI tool, and for what? For buyers of writing services, the review step is covered in the editor review checklist for AI-assisted article services.

A fill-in template

Use one pattern on every relevant piece: "The [draft/body/summary] of this piece was prepared with an AI tool. [Name] checked [facts/names/sources]. Responsible editor: [name]." Readers who see the same pattern recognize it quickly.

Updates and corrections

If a piece is updated, its involvement step can change. A human-written post that gets a tool-drafted section needs its note revised. A tool-drafted post later rewritten by a person may carry a note that is now misleading. Practical suggestion: add a line to the production record at each update and check whether the note is still true.

Disclosure and citation work as a pair. The note says how the text was made; the sources say what it rests on. For formats, see citing sources in articles.

Decision rule: add a note?

1. Did a tool produce the body of the text or image? If yes, add a note.
2. Could a reader who assumes a person wrote it be misled? If yes, add a note.
3. Is the content part of a product feed such as Merchant Center? If yes, apply that platform's requirement.
4. Did the tool only help with spelling or research? Record it in the policy; no reader note.
5. Does the byline show a real, accountable person? If not, fix that first.

Worked example: a design agency blog

Example scenario: A design agency's blog has three kinds of posts: project write-ups, tool comparisons and opinion columns. The writing team uses an AI tool for first drafts of tool comparisons, for summaries of project briefs and for alt text suggestions. Columns are written entirely by the creative director.

The managing partner sets the policy. Columns carry no note. Project write-ups that include a tool-drafted summary get a one-line note at the end of that section. Tool comparisons, where the tool drafted the bulk of the body, carry a short note next to the byline: "First draft prepared with an AI tool. The author checked every feature against vendor documentation. Responsible editor: name." Alt text suggestions stay out of the visible text and go in the production record after the editor compares them with each image.

After two weeks a reader emails asking which vendor pages the author checked. The agency adds a "how we make our posts" page describing source selection and the editor's checks, and links the byline note to it. The cover illustration, generated with a tool, gets a caption phrase and a metadata mark.

Misreadings

"If I disclose, my rankings drop"

Google's documentation has no statement that disclosure raises or lowers rankings. Google frames it as context for readers. Tying it to search results, or hiding use for fear of them, finds no support in that documentation.

"Every use of AI needs a label"

Google suggests disclosures where reasonably expected; it does not extend this to every spell check. Labeling every sentence tires readers and buries the notes that matter.

"The note replaces the byline"

The author's name identifies the person who verified the text. The note sits beside it, not in its place.

"Once on the About page is enough"

A general statement does not describe each article. Readers can land on a single page from a search result or a link, so the note belongs in the piece or next to the byline.

Disclosure beyond the article page

A design agency blog rarely lives only on its own pages. The same piece travels into a newsletter, a social caption and sometimes a client deck. The reader who meets it there has the same reasonable interest in knowing how it was made, yet the note can stay behind on the original page.

Newsletters and syndicated copies

Practical suggestion: carry the note into the newsletter version as a single line under the headline or at the foot, and link back to the page where the longer statement sits. If a partner site republishes the piece, send the note with the text so that it is not trimmed away as boilerplate.

Social posts and short captions

A caption does not need a paragraph. A short pointer such as "Drafted with a writing tool, checked and edited by our team" is enough when the post itself links to the full piece. The wording should not claim more than the page does, and it should not claim less.

Client-facing documents

When an agency delivers copy to a client, the client is the first reader. Name in the handover which parts came from a tool and who checked them, so that the client can decide how to present the material under its own name. The delivery note and the published note should tell the same story.

Practical suggestion: keep one master wording per type of piece in a shared document and copy from it. Surfaces that each get a fresh phrasing drift apart quickly, and a reader who sees two different accounts of the same article has less reason to trust either.

One master wording per type of piece also makes later audits quick, because a reviewer compares each published note against a single reference instead of guessing what was intended.

Pre-publication checklist

• Tool involvement is classified on the four-step scale.
• Pieces with a tool-made body carry a short note.
• The note names the job and the person who checked.
• The note sits where readers look.
• The byline shows a real, accountable person.
• Tool-made images are marked in the caption or metadata.
• Product-feed requirements are applied separately where relevant.
• The text was fact-checked by hand; the note does not stand in for that.
• No claim is made that the note affects rankings.

Frequently Asked Questions

Is disclosing AI use required?

Google's search documents suggest disclosures where reasonably expected and do not present them as a requirement for web content. Merchant Center rules for product images and product data are separate and are stated as requirements.

Does disclosure affect rankings?

Google's documentation has no statement about ranking effects. Google presents disclosure as a way to give readers context about how content was created.

Do I need to name the AI tool?

Google's documentation does not ask for the tool's name. Saying what the tool did and who checked the result tells readers more than a product name does.

Should I disclose a spelling check done by a tool?

The documents set no threshold. Practical suggestion: no reader note for spelling checks or topic research, but list those uses in your policy.

Where should the note go?

Where readers will look: next to the byline, at the top or at the end of the text. A general statement on an About page can sit alongside it if the note links there.

Does the note reduce the author's responsibility?

No. The byline should name the person who verified the text and answers for it. Google's helpful content page treats invented author information as deception.

Conclusion

Telling readers how an article was made is, in Google's documents, advice that gives readers context, with firm requirements limited to product-feed rules. Put a short, specific note on pieces whose body a tool produced, keep a real person's name on the byline and fact-check by hand before publishing. Treat disclosure as honesty toward readers, not as a ranking device.

If you would like an editor-checked workflow for your content, the content writing service page lists the options.