How to Write Affiliate Content for Products You Don't Own

The keyword research is done. There are twenty page titles in the plan, a niche worth building in, and a house containing none of the products. Buying twelve of them to get started is not a plan, and the advice the internet gives at this exact moment is the most expensive mistake available to a new site: pull the spec sheet, write the review anyway, nobody checks.

People check. But the useful part isn't the warning, it's that there's an honest version of this page and it isn't a compromise. Four of the six page types worth building require nothing in your hands at all.

Two sets of rules, one instruction

The FTC's endorsement guidance is not subtle about this. It says you can't talk about your experience with a product if you haven't tried it, and that if you've used something once you can't suggest you use it regularly. That is a rule about claims, it applies to a personal blog with four readers, and it does not care that the words were drafted quickly or drafted by a model.

Google's helpful-content guidance arrives at the same place from a different direction. Its self-assessment asks whether the content demonstrates first-hand expertise and depth of knowledge, and the example it reaches for is expertise that comes from having actually used a product or service.

These are not the same rule and they carry very different consequences. One is law about what you may claim. The other is guidance about what earns a ranking. They converge on a single instruction anyway: don't say you used it.

Which is a much smaller restriction than it first sounds, because the mistake was never publishing a page about a product you don't own. It was publishing a review of one.

The fork is a page type, not a writing style

“Be careful with your wording” is advice, and advice fails at post forty on a Tuesday night. The version that survives is a template that can't express the lie. Here is the review contract the kit ships, the same block shown on the homepage:

export const Review = z.object({
  title:    z.string().max(60),
  rating:   z.number().min(1).max(5),
  testedOn: z.string().date(),
  sources:  z.array(Source).min(3),
  affiliate: z.object({
    href: goLink,
    disclosed: z.literal(true),
  }),
});

testedOn is a required date. Not a field you should fill in, not a recommended best practice. A review page without a real tested-on date doesn't get written sloppily. It doesn't get published, because the build refuses it. The same template demands at least three sources and an affiliate disclosure it won't let you set to false.

Now the comparison contract:

export const ComparisonFrontmatter = BaseFrontmatter.extend({
  productA: Contender,
  productB: Contender,
  verdict: z.string().min(1),
  winner: z.enum(["a", "b"]).optional(),
});

There is no testedOn field. There is no rating. Not because a comparison is the lesser page, but because it makes a different kind of claim, and the schema is shaped to the claim rather than to the topic. Two contenders, a spec table where every entry traces to a published source, and a verdict. The winner is deliberately optional: a genuine “it depends” is a real answer, and a template that forced a champion would push you into inventing a preference you don't have.

The decision therefore happens once, when you pick a template, and after that the file itself keeps you honest. That is the whole trick.

What it looks like on a real page

The flagship demo page for this kit compares two fat-tire commuter e-bikes. It is a comparison rather than a review for the least sophisticated reason available: the person who built it doesn't own an e-bike and has never ridden either one.

So the page claims nothing about riding them. Every number on it traces to a manufacturer page or a published test, each one carrying a source URL and the date it was last checked. The verdict names no winner. It reads, in part, that neither wins outright, and tells the reader to buy for whichever number is actually their constraint. That is a genuinely useful page and it required a research afternoon rather than four thousand dollars of bicycles.

The page also renders its own source file, read off disk at build time rather than pasted in, so a reader can open the frontmatter and see exactly which claims are cited and when they were verified. A page willing to show its own working is making a different offer than one that isn't.

What a spec-sourced page can and can't say

The template stops the structural lie. The prose is still yours, and this is where a good page quietly turns into a bad one, one verb at a time.

None of that makes the page weaker. Read a few of the pages currently ranking in most product categories and you'll find the same synthesis of specs and other people's testing, minus the citations, plus a fabricated verdict. Yours is the honest version of the thing that already works.

Four page types that need nothing in your hands

The content-plan post sequences six page types on the assumption that you cleared the niche checklist's first test and can get your hands on the products. This is the branch for when you haven't yet. The split falls in a specific place, and it's visible in the schemas: the review contract requires a tested-on date and three sources, while every other money page inherits a shared base that requires citations and says nothing whatsoever about ownership.

Two wait. The single-product review waits on the product. The “best X for Y” roundup waits longer than people expect, because a ranked list reads as tested whether or not you said so, and a list of five where you've used two is the exact page that gets a site in trouble. Let the roundup come after the breadth is real.

Then buy one thing

Not twelve. Every cluster has a product at its center, the one the money queries keep circling. Buy that one, use it properly for as long as your tested-on date is going to imply, and write the review you were tempted to fake in week one.

One page with a real date on it does something the other twelve can't, and it isn't about ranking. It sets the standard the rest of the site is read against. A visitor who finds one page saying plainly “tested on this date” and another saying “compared from published specs, checked on this date” learns that this site distinguishes between the two, which is a thing almost no affiliate site bothers to demonstrate.

Keep the citations from rotting while you're at it. Prices move and models get discontinued, so the kit fails the build when a check date passes the staleness window, 180 days out of the box. A page of cited specs is only honest for as long as the specs are current.

Get something wrong, then say so

Research pages get things wrong. A manufacturer revises a spec, a source turns out to be repeating a press release, a price was promotional. The kit ships a corrections log for exactly this: dated entries naming the page and what changed, rendered at /corrections, for any substantive edit to a claim after publish. A typo doesn't need one. A changed number does.

This reads like a liability and behaves like the opposite. A visible correction log is a claim you can't fake cheaply, and it's one of the things an affiliate program reviewer is looking for when they open your site to decide whether to approve you.

What this doesn't promise

A cited comparison does not automatically outrank a fabricated review. Plenty of invented hands-on testing ranks perfectly well today, and pretending otherwise would be the same species of claim this whole post argues against.

What the honest page buys is narrower. Nothing on your site needs retracting when a reader emails the manufacturer. Your program applications survive the manual review. Every number can be checked back to a source with a date on it, which is the same property that makes a site worth citing to an AI system and the same reason the AI-built objection stops being frightening. You are not gambling that nobody checks. You are building the thing that survives being checked.