---
title: "How to write SEO blog articles for an online store without invented facts"
description: "An SEO article on a store blog may only mention products that exist and are in stock, and only claims the store can prove. We ground the writer in a catalogue exported from the store, have a second agent try to refute each draft, and let a script with no model in it block publication on fake product links, banned words and invisible AI characters."
date: 2026-10-11
lang: en
canonical: https://goingstellar.ro/methods/seo-articles-online-store-no-invented-facts/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: E-commerce / Store blogs
license: CC BY 4.0
alternate_ro: https://goingstellar.ro/ro/metode/articole-seo-magazin-online-fara-fapte-inventate/
---

# How to write SEO blog articles for an online store without invented facts

*An SEO article on a store blog may only mention products that exist and are in stock, and only claims the store can prove. We ground the writer in a catalogue exported from the store, have a second agent try to refute each draft, and let a script with no model in it block publication on fake product links, banned words and invisible AI characters.*

> E-commerce · Store blogs · 2026-10-11 · https://goingstellar.ro/methods/seo-articles-online-store-no-invented-facts/

## Key points

- An SEO article on a store blog should link only to products that exist and are in stock, using the exact product handle copied from a fresh catalogue export.
- A list of confirmed facts given to AI writers spreads its own errors with the same authority as its true facts, so the verifier must be allowed to challenge the list.
- The final check before publishing a store article should be a script with no language model in it, because a failed or interrupted AI verification can silently pass an unverified draft.
- Banned-word checks match the word, not the meaning, so a forbidden word fails even inside a sentence that denies it.
- On Shopify, an article's SEO title and meta description are the metafields global.title_tag and global.description_tag, not the article summary.

## What a store blog article must not invent

An SEO article for an online store must not invent products, product links, prices, delivery promises or performance claims. Every product the article recommends has to be a real product that is in stock today, linked by its exact address, and every claim has to come from a short list of facts the store can prove. A language model will happily write a fluent article around a product that does not exist; the method below exists to stop that before it reaches the blog.

SEO (search engine optimisation) here means making a page that answers a real search query well enough to be shown and clicked. A store blog article is an editorial page on the store's own domain that answers such a query and links to products. The risk is specific to stores: a wrong fact in an article is not only a style problem, it is a promise to a customer.

We run this method for several store blogs, each in its own brand voice. Our first batch was 27 articles, 9 per store on three stores, published live. We do not yet have measured proof of what traffic they bring, and we say so in the limits below.

## Step 1: ground the writer in the store's own catalogue

**1. Export the catalogue.** Pull the store's blogs, products and images through the store's admin API into a local file. Rebuild this export whenever stock or the catalogue changes, because an article written from last month's catalogue will link to products that have since sold out.

**2. Build an index and a compact in-stock catalogue.** From the export, keep only products that are in stock and write them to a short catalogue file the writer can read: title, exact handle (the product's address on the store), the attributes the article may talk about. The writer receives this file, not a summary of it.

**3. Use the exact handle from the catalogue.** The writer copies the handle, it never rebuilds one from the product title. A rebuilt handle looks right and returns a page that does not exist.

**4. Keep a store-facts file.** Delivery terms, promotions, the store's guarantees: only claims the store can prove, each written once. The voice of each store lives in its own document; the facts live in one place.

## Step 2: a writer and a verifier for every article

Each article is written by one agent and then checked by a second agent whose only task is to refute it: is every product link in the in-stock catalogue, is every comparison correct, does any banned word appear, does any claim go beyond the store-facts file. A draft the verifier cannot pass goes back for repair, not to the blog.

The verifier must be allowed to contest the facts file itself, not only the draft. On another content project we gave writers a list of confirmed facts so they would not invent; the list contained errors, and every agent repeated them with the same authority as the true facts. It happened four times, and one error produced a question with no correct answer. Facts now live in a versioned file, each with its source and the date the source was read, and the verifiers are told to challenge it.

After the workflow, a fixed script normalises the output before anything else happens. Agents sometimes return the article body with its HTML escaped as text, and publishing that raw output would show tags to readers. We never publish raw workflow output.

## Step 3: a deterministic gate before publishing

The last check before publishing is a script with no language model in it. In dry-run mode it reads the whole batch and refuses any article that links to a handle missing from the catalogue or out of stock, contains a banned word, or falls outside the length limits. The same script then publishes as a hidden draft for a human to read in the store admin, and only after that goes live. Publishing is outward-facing, so a person confirms before the live step.

This gate matters most when the workflow fails halfway. Long writing runs can hit usage limits, and when they do the verification stage falls back to the unverified draft. The dry-run gate is the safety net for that case, and unverified articles are also spot-checked by hand.

Banned words are matched by pattern, so they trip even inside a negation. A sentence that says the product is *not* a forbidden thing still contains the forbidden word and still fails. The fix is to rephrase, not to weaken the pattern.

## Step 4: remove what makes the text read as machine-written

A de-AI pass runs last, on the text that will actually be published. It removes invisible Unicode characters that generated or pasted text carries (zero-width spaces and joiners, byte-order marks, soft hyphens, narrow non-breaking spaces, every character in the Unicode format category), reports heavy use of em-dashes, and lists phrases that read as machine-written using a blocklist that ignores diacritics, so a phrase is caught with or without accents.

The pass gives a cleanliness score out of 100, and we publish at 80 or above. Invisible characters and em-dashes are fixed automatically. Flagged phrases are listed but not rewritten automatically, because an automatic rewrite produces more machine-sounding text; a person rewrites them.

Proper names need a deterministic check of their own. Models misspell brand and product names with confidence. In captions we generated from video, a sub-brand name came out misspelt on published posts. The correction now compares capitalised words against names taken from the product titles in the store, never from memory, and fixes them in code rather than by asking the model again.

## Step 5: SEO fields and page furniture

On a Shopify store, an article's SEO title and meta description are not the article's summary. They are set as the metafields `global.title_tag` and `global.description_tag`; the summary is the excerpt shown on the blog page. We set both, and keep the title to 60 characters and the description to 160, aiming for 145 to 158.

A good article SEO title starts with the strongest query term. The description gives a hook, a concrete benefit drawn from the store-facts file and a soft call to action.

The hero image is never a guessed image address. It is either the main product's own image from the catalogue or an image generated with that real product photo as reference, so the product shown is the product sold.

## Where we were wrong

We once assumed that about 14 published articles had plain product photos as hero images and started to regenerate them all. The images were already contextual scenes. A quick look would have shown it; regenerating would have wasted every generation. Look before a bulk change.

Our first guard against generated captions that impersonate a speaker matched names in a case-insensitive way, which defeated its own capital-letter test. The first scan reported 23 broken captions that were fine. A guard is tested on good and bad examples before anyone trusts its count.

The bigger SEO problem on our stores was not the blog at all. An audit found 138 of 153 products on one store sharing exactly the same description. Articles help, but thin, duplicated product pages are fixed on the product pages.

## Limits

The method stops invented products, broken links, banned words and machine-written tells. It does not prove that an article ranks or sells. Google states that word count is not a ranking factor, and content written to a word-count target is one of the warning signs in its guidance on helpful content, together with the questions of who wrote a page, how it was made and why it exists. Our pipeline answers the first two for itself; whether a given article helps a reader is still a human judgement.

A facts file is only as correct as the sources behind it. If a delivery promise changes and the file does not, every new article repeats the old promise.

## Checklist

**1. Catalogue.** A fresh in-stock export, read by the writer as a file.

**2. Handles.** Copied exactly, never rebuilt from titles.

**3. Facts.** One versioned file with sources and dates, open to challenge by the verifier.

**4. Verifier.** A second agent that tries to refute each draft.

**5. Gate.** A deterministic dry-run on the full batch, then a hidden draft, then a confirmed live publish.

**6. De-AI.** Invisible characters removed, flagged phrases rewritten by a person, score of 80 or above.

**7. SEO fields.** Title and description as metafields, within 60 and 160 characters.

## Questions and answers

### How do I stop AI from inventing products in my store's blog articles?

Give the writer a file with only the products that are in stock today, including each product's exact handle, and forbid any product not in that file. Then check every product link against the same file with a script before publishing, and refuse the article if a link points to a missing or sold-out product. Rebuild the file whenever stock changes, so articles never link to products that have sold out.

### Should a second AI check articles written by the first one?

Yes, as a verifier whose only job is to refute the draft: every link in the catalogue, every claim in the facts file, no banned words. It should also be allowed to question the facts file itself. A second model is not enough on its own, because a long run can be cut short and fall back to an unverified draft; a deterministic script with no model in it should make the final decision.

### Where do I set the SEO title of a Shopify blog article?

Shopify articles have no separate SEO input field in the API. The SEO title and meta description are the metafields global.title_tag and global.description_tag, which the theme renders into the page head. The article summary is the excerpt shown on the blog listing, not the meta description. Keep the title within 60 characters and the description within 160.

### How can I make AI-written store copy read less like AI?

Run a pass on the final text that removes invisible Unicode characters left by generation or pasting, flags heavy em-dash use and lists phrases that read as machine-written. Fix the invisible characters automatically, but have a person rewrite the flagged phrases, because an automatic rewrite produces more of the same. Check product and brand names against the store's own product titles in code.

### Does a longer article rank better for a store?

Not by itself. Google says word count is not a ranking factor, and content written to hit a word count is one of the warning signs in its guidance on helpful content. Write enough to answer the query fully, with real products and provable claims. On many stores the larger gain is fixing thin or duplicated product descriptions rather than adding more blog articles.

## How to cite

**Cite this as:** Going Stellar (2026). *How to write SEO blog articles for an online store without invented facts*. GOING STELLAR S.R.L.. https://goingstellar.ro/methods/seo-articles-online-store-no-invented-facts/

```bibtex
@misc{goingstellar2026seo,
  title  = {How to write SEO blog articles for an online store without invented facts},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/methods/seo-articles-online-store-no-invented-facts/},
  note   = {2026-10-11}
}
```

Licence. Free to quote with attribution.

## Also available

- This page as HTML: https://goingstellar.ro/methods/seo-articles-online-store-no-invented-facts/
- Same article in Romanian: https://goingstellar.ro/ro/metode/articole-seo-magazin-online-fara-fapte-inventate/