Build a Complete Affiliate Blog With AI: A Compliant Workflow

The usual "AI affiliate blog" recipe goes like this: scrape a bestseller list, have a model write a review of every product, publish dozens of pages a week, and wait for commissions. An earlier version of this article described a pipeline much like that. We've replaced it, because that recipe collides with three sets of rules at once: Google's spam policies, affiliate program agreements, and FTC disclosure guidance. A site built that way is a liability, not an asset.

What follows is the version worth building. AI does the research grunt work, structuring, and first drafts. You supply the product experience and the judgment. Code enforces disclosures and catches mistakes before anything goes live. This article reports no traffic or revenue figures, because results depend on your niche and your evidence, and we won't invent them.

Why the mass-generation approach fails

None of these rules forbid using AI. They forbid publishing pages that don't help anyone and hiding the commercial relationship.

What AI should and shouldn't do

Step 1: Choose a niche you can actually evaluate

The single best predictor of whether an affiliate article can be good is whether you can test, measure, or credibly compare the products. Before you commit, check:

• Access. Can you own, borrow, or rent the products, or do you already use them professionally?
• Measurability. Are there things you can measure, like battery life, noise, speed, or output quality, instead of just restating specs?
• Programs. Which affiliate programs cover the products? Read each operating agreement before you write a word. Rules on prices, trademarks, coupons, and link placement differ.
• Update load. Products in fast-moving categories need refreshing every few months. Budget for that.

This site's own approach is an example. Our cloud GPU guides only discuss providers whose pricing pages and documentation we can check directly, and they state an as-of date on every price.

Step 2: Research demand and intent

Start from real queries, not model guesses. Pull them from Google Search Console if the site already has traffic, from keyword tools, and from the questions people ask in communities and comments. Then use AI for the tedious part, grouping queries by intent:

A model can cluster a few hundred queries in one prompt. Check its groupings, because it will occasionally merge queries with different intent. For more on AI-assisted keyword research, see How to Use AI Agents for SEO Research and AI for SEO Content Briefs.

Step 3: Collect evidence before drafting

Google's guidance on writing high-quality reviews asks for evidence of your own experience, such as visuals, audio, or links, along with quantitative measurements, what sets a product apart from competitors, and its benefits and drawbacks. It also suggests linking to multiple sellers where it helps the reader. Turn that into a test log you fill in per product:

product: "Example Model X"
tested_by: "your name"
tested_on: "2026-10-12"
how_obtained: "bought at retail"        # or loaned by brand, which must be disclosed
setup: "what you did, settings used"
measurements:
  - metric: "time to first result"
    value: "measured value + unit"
    method: "how you measured it"
pros: ["specific, observed"]
cons: ["specific, observed"]
compared_against: ["Model Y", "Model Z"]
photos: ["path/to/own-photo-1.jpg"]
not_tested: ["long-term durability"]    # say so in the article

The not_tested field is there for honesty. If you didn't test durability, the article says that plainly instead of implying it.

Step 4: Draft from the evidence only

Feed the model the test log, your outline, and strict rules:

Write a review draft of {product} using ONLY the test log below.
- Every claim about performance must cite a measurement or observation from the log.
- If the log has no data for something, write [NOT TESTED] instead of guessing.
- List the not_tested items in a "What we didn't test" section.
- No prices, ratings, or availability. Those are inserted later from an allowed source.
- Mark each place a product link belongs with [LINK:{merchant_id}].
TEST LOG:
{yaml}

The edit pass then adds your voice, removes filler, and checks every sentence against the log. The [LINK:...] markers keep tracked URLs out of the draft entirely. Links get inserted by code that also adds the right attributes, which is the next step.

What each page type needs

Matching the outline to the intent from Step 2 keeps drafts from turning into interchangeable "top 10" pages. Give the model the matching skeleton along with the test log:

Two habits make these pages more useful than the generic versions. First, say who the product is not for. A reader who learns a product doesn't fit their use case has still been helped, and the page earns trust for the next recommendation. Second, keep a "How we evaluated" section on every comparison and roundup that links to the test logs or summarizes them. Google's review guidance asks for evidence of the work behind a recommendation, and the section makes your own updates easier because the method is written down.

If a page type needs evidence you can't collect, pick a different page type. A documented spec comparison that says plainly it isn't hands-on is honest and can still be useful. A "review" without a test isn't.

Step 5: Make disclosures and link attributes automatic

Disclosures that depend on remembering are disclosures that eventually get forgotten. Move them into your templates.

This site works this way. Affiliate merchants live in one registry file, each with its tracking URL and a plain-language label. A post's frontmatter lists the merchant IDs it uses, and the page template then renders:

• a visible affiliate disclosure box above the article body, near the content it applies to, rather than in a footer;
• partner links with rel="sponsored nofollow noopener noreferrer";
• an "Advertisement" label next to each partner offer.

A check script runs before every deploy. It fails the build if a post references a merchant that isn't registered, if a monetized post is missing its required images, or if any tracked merchant URL appears pasted directly in an article body, where it would skip the disclosure and attributes. You don't need this exact setup. The principle is that only the template can produce an affiliate link, so every affiliate link comes with its disclosure.

If you also accept free products or loans from brands, disclose that in the review itself. The FTC's FAQ treats free products and commissions as material connections that both need disclosing.

Step 6: Run pre-publish checks

A small script catches the mistakes AI drafts are prone to. Run it on every Markdown file before it can be published:

# prepublish.py: exit non-zero if any draft fails
import pathlib, re, sys

RULES = [
    (r"\[(NOT TESTED|NEEDS INFO)\]", "unresolved gap marker"),
    (r"\[LINK:[^\]]+\]", None),                       # allowed: template fills these
    (r"https?://(www\.)?(amzn\.to|amazon\.[a-z.]+)/\S*tag=", "raw tracked Amazon link in body"),
    (r"\$\d[\d,.]*(?![^\n]*as of)", "price without an 'as of' date on the same line"),
    (r"(?i)\b(I|we) (tested|used|tried)\b", "experience claim: confirm it's true and logged"),
]

failed = False
for path in pathlib.Path("drafts").glob("*.md"):
    text = path.read_text(encoding="utf-8")
    for pattern, message in RULES:
        if message and re.search(pattern, text):
            print(f"{path.name}: {message}")
            failed = failed or "confirm" not in message   # experience claims warn, don't fail
sys.exit(1 if failed else 0)

The experience-claim rule only warns, because "we tested" is fine when it's true. It exists to make you look. Extend the rules for your own programs' requirements, such as banned coupon language or trademark restrictions.

Step 7: Publish slowly and keep pages current

Publish at the pace your testing allows. A handful of well-evidenced reviews and comparisons does more for a new site than a flood of thin ones, and it's far less risky. Then maintain them:

• Re-check prices and specs on a schedule, and update the as-of dates when you do.
• Mark discontinued products and point readers to a current alternative you've evaluated.
• Watch Search Console queries for questions your page doesn't answer yet, and add sections for them.
• Link related pages together, for example from a how-to guide to the comparison that answers "which one should I buy?"

How to Build a Niche Site With AI in 30 Days covers site structure and launch, and content batch days help with producing drafts efficiently once your evidence is collected.

Old pipeline vs. compliant pipeline

FAQ

Is AI-written affiliate content against Google's rules? Not by itself. Google's spam policies target pages generated mainly to manipulate rankings without adding value, however they're produced. AI-assisted pages built on real evidence and written to help readers aren't that.

Can I write about products I haven't tested? Yes, if you say so. Spec comparisons, buying guides based on documentation, and roundups of what's available can be useful. They just can't pretend to be hands-on reviews.

Where exactly should the disclosure go? Near the recommendation, where readers will see it before they act. The FTC's FAQ warns that disclosures at the bottom of a page or behind a link are easy to miss. A short line above the content, plus labels next to the links, is a solid pattern.

Do affiliate links need rel="sponsored" or rel="nofollow"? Google asks for sponsored on paid and affiliate links, and nofollow is also acceptable. Using both, as this site does, covers both.

Can I show Amazon prices if I update them daily? Amazon's program policies allow prices only when Amazon serves the link displaying them or when you pull them through its Creators API or PA API under those terms. Updating scraped prices by hand doesn't meet that condition. Check the current policy before you display any.

What does this site's disclosure look like? See our affiliate disclosure page and any of our cloud GPU guides, such as Run a Private LLM on a DigitalOcean GPU Droplet.