Recently Updated: 16 min read

Spotting Templated and AI-Drafted Guest Post Pitches

Spotting Templated and AI-Drafted Guest Post Pitches

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?

SignalWhat it may meanCheck
Generic greeting with no site nameBulk sendingAsk a question only a reader of your site could answer
Topic fits none of your categoriesThe archive was not readCompare against your categories and recent posts
Same phrasing as earlier pitches from other sendersShared template sourceSearch your archive for the phrase
No author profile, but a link requestLink-first motiveAsk for a profile and the reason for the link
A long list of ready-made headlinesVolume over fitAsk for one outline built for your readers
Pitch voice differs sharply from later emailsSomeone else wrote the pitchAsk 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.

  1. Are dates, product names, quotations and technical claims linked to sources?
  2. Do examples come from real situations, or are they plausible-sounding but unverifiable?
  3. Does the draft contain the author's own experience, or could any writer have produced it?
  4. Were the title, meta description, image alt text and structured data reviewed as well as the body?
  5. 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.

OptionBenefitCostFits when
Total banSimple ruleHard to audit; may turn away honest writersA very small site on a sensitive topic
Conditional acceptanceFlexible; shifts checking to the authorNeeds a declaration and a recordA general-interest publication
Unconditional acceptanceMore pitchesHeavy verification load on editorsA 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

SignProblem for the readerEditor's question
Paragraphs restating the same point in new wordsNo new informationWhat does this paragraph add?
Firm statements with no sourceCannot be verifiedWhere does this claim come from?
Every section closing with the same formulaLooks mass-producedIs the author writing in their own voice?
"A company might..." instead of a real caseNo first-hand experienceCan a concrete situation be described?
Generic openings unrelated to the questionWastes reader timeDoes the opening answer the topic question?
Inconsistent terms or version detailsAccuracy riskDo 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.

  1. Which tools did you use, and for which step: research, drafting or proofreading?
  2. How many of the factual claims did you check against their sources yourself?
  3. Do the examples come from your own experience?
  4. Has a version of this piece gone to another publisher?
  5. 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 fieldExample valuePurpose
Envelope warningsGeneric greeting, no site-specific answerPattern tracking
Process declarationTool use: proofreading onlyRecord of conditional acceptance
Verification resultAll claims matched sourcesReason for acceptance
Published elsewhereNo, or yes with URLCanonical decision
Decision and codeOpen for draft or no site-specific contentStatistics 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 situationReading depthNext step
First message, no earlier recordEnvelope plus skeletonAsk the process questions only if two or more signs appear
Returning sender with one accepted articleDetail pass on sources onlyCompare against the earlier declaration
Returning sender after a rejection for template useFull three passesRequire the written declaration before reading further
Sender who answered the process questions with new, specific detailNormal readNote 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.

0 Comments

No comments yet for this article.

Post a comment

Please log in to leave a comment. Login