Some pitches that reach your inbox were written for you. Others were written for everyone and addressed to no one: a template sent to dozens of publishers, a draft generated in bulk and never checked, or an article already published elsewhere with a few sentences swapped. An editor's job is not to accuse the sender, but to work out which drafts would add value to the site and which would only add risk.
Short answer: Using AI is not by itself a reason to reject a guest post. The reasons to reject are missing value, unverified claims and signs of mass production. Judge each draft on who verified it and what it adds for your readers. If you edit a blog, run a content desk or review contributor pitches, the signals and the decision order below give you a consistent first screen.
What the policies actually say
Two Google pages frame this topic, and it helps to quote their positions accurately rather than from memory. The spam policies define scaled content abuse as many pages being generated for the primary purpose of manipulating search rankings and not helping users. Their examples include using generative AI tools or similar tools to generate many pages without adding value for users, and creating multiple sites with the intent of hiding the scaled nature of the content. Source: Google Search Central: Spam policies for Google Web Search (Opens in a new tab).
The generative AI guidance is more balanced. It says generative AI can be particularly useful when researching a topic and to add structure to original content. It also says that using these tools to generate many pages without adding value for users may violate the scaled content abuse policy, advises focusing on accuracy, quality and relevance especially when content is generated automatically, and calls it critical to manually fact-check and review all AI-generated content for accuracy and trustworthiness before publishing. It adds that this review also applies to metadata such as title elements, meta description elements, structured data and image alt text, and that sharing information about how content was created can give readers more context. Source: Google Search Central: Using generative AI content on your website (Opens in a new tab).
Neither page offers a method for proving that a given text was machine-written. The documentation is silent on detection tools, so treat any detector score as a weak hint at best. What you can assess reliably is quality, sourcing and whether the author owns the verification.
What this means for a publisher
- The question is value and verification, not the tool used.
- A template or a generated draft becomes a problem when it is mass-produced and adds nothing for your readers.
- Because you publish the page, the accuracy of what appears under your name is your concern too.
- A written process and a recorded decision matter more than a clever detection trick.
Reading the envelope: template and pattern signals
The envelope is everything around the draft: greeting, subject line, sender, profile, link request and payment mention. It takes minutes to read and answers a few sorting questions. Does the sender know your site? Do they say who they are? Is the link's purpose clear?
| Signal | What it may mean | Check |
|---|---|---|
| Generic greeting with no site name | Bulk sending | Ask a question only a reader of your site could answer |
| Topic fits none of your categories | The archive was not read | Compare against your categories and recent posts |
| Same phrasing as earlier pitches from other senders | Shared template source | Search your archive for the phrase |
| No author profile, but a link request | Link-first motive | Ask for a profile and the reason for the link |
| A long list of ready-made headlines | Volume over fit | Ask for one outline built for your readers |
| Pitch voice differs sharply from later emails | Someone else wrote the pitch | Ask for a short call or a written sample on a new topic |
None of these decides anything alone. They raise questions, and three together justify asking for more information before reading the draft.
Topic patterns
Bulk-produced pitches can propose interchangeable topics, such as "the ultimate guide to X" or "ten tips for Y". The titles are not wrong; the problem is that the proposal says nothing about your readers. Ask the sender to tie the topic to a specific question your audience asks.
The verification load of AI drafts
The real cost of an AI-assisted draft is not how it was written but who has to check it. If the author verified every factual claim against sources, the load stays with the author. If not, it moves to your editor, who becomes the fact-checker as well. Whether your site can carry that load decides whether a draft is workable.
- Are dates, product names, quotations and technical claims linked to sources?
- Do examples come from real situations, or are they plausible-sounding but unverifiable?
- Does the draft contain the author's own experience, or could any writer have produced it?
- Were the title, meta description, image alt text and structured data reviewed as well as the body?
- Can the author describe which tool was used and for which step?
Decision question: close the door on AI-assisted drafts, or accept with conditions?
A total ban is easy to state and hard to enforce. Where is the line between a spell checker and a tool that drafts the whole piece? Unconditional acceptance leaves you carrying the checking. Practical suggestion: accept with conditions. The author names the tools and how they were used, verifies every factual claim against its source and takes responsibility for the final text. A draft that cannot meet these conditions is declined.
| Option | Benefit | Cost | Fits when |
|---|---|---|---|
| Total ban | Simple rule | Hard to audit; may turn away honest writers | A very small site on a sensitive topic |
| Conditional acceptance | Flexible; shifts checking to the author | Needs a declaration and a record | A general-interest publication |
| Unconditional acceptance | More pitches | Heavy verification load on editors | A strong editorial team with spare capacity |
The same article on other sites
A sender may offer one text to several publishers. That is a question of intent and of your standards. If your site expects original text, ask on the pitch whether any version has been published or offered elsewhere. A yes leaves three options: decline, request a version written for your site, or publish with a canonical link to the original source. The last option follows the logic described in content syndication and canonical tags.
- Search two or three distinctive sentences from the draft in quotation marks.
- Compare style and structure with the author's earlier published work.
- A copy elsewhere is not an automatic reject; ask the author and record the answer.
- If the author says the text is original and a copy exists, base the decision on that contradiction.
Writing the rejection
A rejection should name the standard and offer a way forward, without accusing anyone of bad faith. Answering a template with a template puts you in the same category as the sender. For the general structure of replies, see replying to guest post and link offers.
- "The proposed topic does not match what our readers ask about, so we cannot take this further."
- "We could not find sources for the claims in the draft. If you add them, we can look again."
- "We see this text on another site. We can only consider a version written for us."
- "If you tell us which tools you used and how you checked the claims, we can reassess."
Keep it short. Detailed reasoning invites a debate your written policy should already settle.
Worked example: a language-learning blog
Example scenario: A language-learning blog receives three drafts in one week. The first comes from a teacher and describes a classroom exercise with the method explained. She says she used a tool only to polish grammar. The second is a generic piece on the future of language apps, with no sources, interchangeable examples and an email that never names the blog. The third is an article already live on another site with reworded sentences, though the sender calls it original.
The editor opens the first for draft under the conditional rule: the tool use is declared and the author owns the checking. The second returns for revision with two asks, sources and a site-specific example. The third is declined with the contradiction as the stated reason, and the editor attaches the link to the other site. Three different outcomes came from the same three questions: who verified it, what does it add and does it exist elsewhere.
Reading in three passes
Reading every pitch from top to bottom costs time and produces uneven decisions. Three passes with different purposes are quicker and more consistent. Stop at any pass that settles the question.
Pass one: the envelope
This pass covers the email and form only. It takes a few minutes and answers three questions: does the sender know the site, do they identify themselves, and is the purpose of the link clear? If three or more warning signs appear here, asking for more information before opening the draft saves time.
Pass two: the skeleton
In the second pass you look at headings, subheadings and the source list. A real specialist's outline can reflect a particular question, a specific experience or a stated limit. Templated pieces have headings that fit any subject. Practical suggestion: write one sentence beneath each main heading, then ask whether the heading could sit unchanged in an article on a different topic. If it could, the skeleton is weak.
Pass three: the detail
The third pass checks claims, examples and sources one by one. It is expensive, so reserve it for drafts that survived the first two. This is where the verification load becomes visible: if the author supplied sources and tied the claims to their own knowledge, checking is quick; if not, you check every claim yourself. That difference is the main driver of the accept decision.
Paragraph-level signs
| Sign | Problem for the reader | Editor's question |
|---|---|---|
| Paragraphs restating the same point in new words | No new information | What does this paragraph add? |
| Firm statements with no source | Cannot be verified | Where does this claim come from? |
| Every section closing with the same formula | Looks mass-produced | Is the author writing in their own voice? |
| "A company might..." instead of a real case | No first-hand experience | Can a concrete situation be described? |
| Generic openings unrelated to the question | Wastes reader time | Does the opening answer the topic question? |
| Inconsistent terms or version details | Accuracy risk | Do the terms match the sources? |
Seeing these signs does not show that a text was machine-written; people write this way too. The table questions the benefit to the reader, not the author's character. When you spot a pattern, pass it on as a revision note: "Open with your own observation instead of a general statement."
Questions about the writing process
The purpose of process questions is to record how the draft was made, not to test the author. Google's helpful content and generative AI pages both note that sharing how content was created can give readers context; as a publisher you can collect the same information for your own file.
- Which tools did you use, and for which step: research, drafting or proofreading?
- How many of the factual claims did you check against their sources yourself?
- Do the examples come from your own experience?
- Has a version of this piece gone to another publisher?
- Do you hold the rights to any images, tables or quotations?
An honest, consistent set of answers lets the process continue. Contradictory or evasive answers go in the record and weigh on the decision. The quality of the answers carries as much information as the text itself.
A declaration for conditional acceptance
When accepting AI-assisted drafts with conditions, ask for a brief declaration: the tools used, their purpose (research, structure or proofreading), confirmation that factual claims were checked against sources, and acceptance of responsibility for the text. File it with the archive entry. Adding a note for readers on the page is not required, but consider a short line where the tool use would change what a reader expects.
Editorial capacity and the verification budget
Verification takes time, and every site has limited time. Accepting templated or machine-assisted drafts shifts checking to your editors, so capacity belongs in the decision. If you do not know how many drafts per week you can verify, record the time spent on each for a month. The notes will show which kinds of pitch are expensive.
When capacity is tight, tighten the conditions: require a source list, require a process declaration and return unsourced drafts in round one. When capacity is wider, you can afford a more flexible stance. Either way, publish the rule on the policy page so writers know what to expect.
| Archive field | Example value | Purpose |
|---|---|---|
| Envelope warnings | Generic greeting, no site-specific answer | Pattern tracking |
| Process declaration | Tool use: proofreading only | Record of conditional acceptance |
| Verification result | All claims matched sources | Reason for acceptance |
| Published elsewhere | No, or yes with URL | Canonical decision |
| Decision and code | Open for draft or no site-specific content | Statistics and appeals |
A second example: a sender who comes back
Example scenario: The editor of a photography blog receives a new pitch from an address that was rejected three weeks earlier. The name differs and the topic is new, but the email address matches and three sentences are identical to the earlier pitch. The archive shows the first pitch closed with the code "no site-specific answer".
The editor does not reopen the first record but reuses the code and sends a short message: "If you answer the site-specific question we asked before, we can consider this topic." The sender does not reply and the case closes. Had the sender replied with a detailed, site-specific answer, the editor would have reassessed. The archive made the distinction possible; a search on the name alone would have missed the pattern.
False positives and appeals
These checks will sometimes slow down an honest writer. A specialist writing in a second language may use a tool for phrasing. A quick applicant may have prepared the topic before. A real expert may have a thin online footprint. Reduce the damage in two ways: ask for more information at the first warning rather than rejecting outright, and keep rejection codes specific. "No site-specific answer" records the basis for a decision better than "template" does.
If an author appeals, restate the standard, invite new information and let a second editor read the case. Record any change of decision and its reason.
Spotting patterns across submissions
The archive lets you see patterns that no single pitch shows. Searching by sender address, profile URL and distinctive sentences can reveal repeat or coordinated submissions. Use one fixed code, such as bulk submission, so you can later review how often it appears. Keep only what the evaluation needs, set a retention period and record observed facts and decisions rather than opinions about a person.
Checklist for an incoming draft
- The sender says something specific to your site.
- Author identity and profile are consistent.
- Claims are sourced and verifiable.
- Tool use is declared and the author takes responsibility.
- No unreported earlier publication.
- The link request serves the reader.
- Title, description, alt text and other metadata were checked too.
- The decision is in the archive with a code or an approval note.
Limits of this screening
None of these signals is proof. A writer using a template or an AI tool is not automatically acting in bad faith, and the decision should rest on the benefit to readers, accuracy and your standard.
Policy sentences to publish
- Disclose any tool used in drafting, and verify every factual claim against its source.
- Tell us if the text has been published or offered elsewhere.
- Pitches that are clearly mass-mailed may not receive a reply.
The last sentence is your right to stay silent. Writing it down is fair to senders and lightens your load, but keep a record of unanswered pitches because later patterns depend on it.
Sorting by sender history
The same warning signs weigh differently depending on who sends them. Practical suggestion: keep one line in the archive for every sender address, then apply the rule below.
| Sender situation | Reading depth | Next step |
|---|---|---|
| First message, no earlier record | Envelope plus skeleton | Ask the process questions only if two or more signs appear |
| Returning sender with one accepted article | Detail pass on sources only | Compare against the earlier declaration |
| Returning sender after a rejection for template use | Full three passes | Require the written declaration before reading further |
| Sender who answered the process questions with new, specific detail | Normal read | Note the answer in the record for next time |
The table does not come from Google documentation; it is an internal triage rule. Its purpose is to stop you from giving a repeat template sender the same patience as a first-time writer, and to stop you from punishing a returning author for one weak draft.
A monthly review of your own rejections
Once a month, open the archive and answer three questions: how many rejected pitches came back with a reasonable appeal, how many accepted drafts needed a correction after publication, and which rejection reason you used more than any other. If appeals keep succeeding, the screening is too strict. If corrections keep appearing, it is too loose.
Keep the reason codes short
Limit the archive to five reason codes: template, unverifiable source, published elsewhere, no answer to process questions, off topic. A longer list records the same case under different labels, and the monthly count stops meaning anything. When you change a threshold, write the date and the reason next to it so you can explain later why a similar pitch got a different answer.
Frequently Asked Questions
Should an AI-assisted guest post be rejected automatically?
Google's guidance says generative AI can be useful for research and for structuring original content; the concern is generating many pages without adding value for users. Practical suggestion: accept with conditions, meaning declared tool use and claims verified by the author.
Can I tell for certain that a text was written by AI?
Google's documentation does not offer a detection method. Assess quality, sources and the author's account of the process instead.
Is a template email enough to reject a pitch?
No. It is a warning sign. A cheap test is to ask a question only a reader of your site could answer.
What if the same article is on another site?
You can decline, ask for a version written for your site, or publish with a canonical link to the original. Asking on the pitch whether the text appears elsewhere makes the choice simpler.
Should I mention AI suspicion in the rejection?
State the standard instead: missing sources, no site-specific content or no process description. That guides the author without an accusation you cannot prove.
Do metadata and alt text need checking too?
Yes. Google's guidance says the review of AI-generated content also applies to title elements, meta descriptions, structured data and image alt text.
Conclusion
Screening templated and AI-drafted pitches does not rest on a detector. It rests on steady questions about value, verification and originality. If there is nothing specific to your site, no sources, no account of the process or the text circulates elsewhere, ask for more or decline. Otherwise treat tool use as a condition to declare and verify. Put every decision in the archive.
If you would rather start from placements with clear publication records, take a look at our guest post service.
Post a comment
Please log in to leave a comment. Login