I have a folder of forty articles I wrote with an AI model and published with barely any editing. They read well. The headings match the queries, the grammar is spotless, the facts survive a check. Almost none of them ranked for anything with real competition, and the two that did were pages where I happened to paste in my own billing screenshot.
The problem was never the prose. It was that nothing on those pages could only have been written by someone who had opened the software or waited eleven days for a refund to clear. Everything on them could have appeared on any of the other nine results.
That absence is exactly what Google’s first E is testing. Experience was added to E-A-T on 15 December 2022, and it is the one signal a language model structurally cannot supply, because a model has no account, no receipts and no Tuesday afternoon where the export failed twice. Expertise can be borrowed from sources. Experience has to be lived and then written down.
What follows is the process I now run on every draft. It adds about forty minutes per article once the habit is built.
What Google actually counts as Experience
Google’s own framing when it announced the change was specific: content created from first-hand life experience, such as using a product yourself or visiting a place. It also made the point that for some queries, someone who has actually used the thing is more useful than a credentialed expert who has not. Software reviews were the example it reached for.
Trust sits at the centre of the four signals. Experience matters because it is the cheapest, fastest way to earn it on a page where you have no institutional authority.
| Signal | The question it answers | What proves it on the page |
|---|---|---|
| Experience | Did this person do the thing? | Your own screenshots, numbers, dates, failures, receipts |
| Expertise | Do they know the field? | Correct terminology, edge cases, caveats a novice would miss |
| Authoritativeness | Do others treat them as a source? | Citations, mentions, a body of work on one topic |
| Trust | Is this page safe to act on? | Accuracy, transparent method, disclosed conflicts, a real byline |
Why AI drafts fail the Experience test
The January 2025 revision of the quality rater guidelines replaced the old section on auto-generated main content with a set of new ones covering scaled content abuse and, more importantly for writers, main content produced with little effort, little originality and little added value. The Lowest rating is applied when nearly all main content is copied, paraphrased, embedded or AI generated with nothing added. A follow-up section lists what paraphrased content tends to look like, including pages that contain only commonly known facts.
Note what that does not say. AI writing is not penalised for being AI writing. Google states that using generative AI tools by itself does not set the effort level or page quality rating, and the March 2024 spam policy on scaled content abuse applies whether pages were made by automation, people, or both. The judgement is about value per page.
| Failure pattern | How it reads | The replacement |
|---|---|---|
| Hedged quantities | "Costs typically range" and "results may vary" | The exact number you were charged, with the date |
| Only common knowledge | Facts available in the first paragraph of any competitor | One thing you learned that is not documented anywhere |
| Frictionless steps | Every instruction works on the first attempt | The step that broke, and what fixed it |
| Borrowed specifics | Benchmarks lifted from someone else’s test | Your own run, even a small one, with the method stated |
| Manufactured balance | Five pros and five cons of identical length | Uneven lists, because real opinions are lopsided |
| No time signature | Nothing indicates when any of this happened | Dates, durations, version numbers |
Capture first, because you cannot add experience you never had
This is the step people skip, and skipping it is why the rest of the process feels impossible. You cannot retrofit a screenshot you never took. Before you touch the draft, do the task and keep a scratch file open while you do it.
Log 01 Timestamps When you started, when it worked, and how long the boring middle part actually took. | Log 02 Exact settings Plan tier, version number, hardware, quantities, oven temperature. The specifics competitors leave vague. | Log 03 Every error Copy the error text verbatim. Errors are the highest value paragraphs you will write. |
Log 04 Real cost What you paid including the part that was not on the pricing page. | Log 05 The surprise One thing that went differently than the documentation implied. | Log 06 Screenshots Capture more than you need, with your own interface visible. Crop later. |
The ten inserts that carry experience
Once you have raw material, the editing job becomes mechanical. Go through the draft and place these. Not all ten belong in every piece, but a page with fewer than five reads generic.
| Insert | What it looks like in the copy | Best placement |
|---|---|---|
| 1. Origin line | How long you used it, on what, in what period | First two paragraphs |
| 2. Your own number | A figure from your dashboard, invoice or stopwatch | Intro and one per major section |
| 3. Failure note | What broke, the error text, the workaround | Inside the how-to steps |
| 4. Decision moment | What you nearly chose instead and why you did not | Comparison section |
| 5. Original screenshot | Your account visible, not a press image | Directly under the step it illustrates |
| 6. Cost reality | The charge that was not on the pricing page | Pricing or value section |
| 7. Setup time | Real elapsed time, including the part you got stuck on | Early, so readers can self-select |
| 8. Edge case | The situation the official docs do not cover | Late body, before the verdict |
| 9. Your own test | A small comparison you ran, with the method named | Its own subheading |
| 10. Who it is wrong for | The reader who should close the tab and buy elsewhere | Verdict |
Density rule Aim for one experience marker every 250 to 300 words, with at least one in the opening and one in the closing. If you scroll the page and hit three screens with nothing that only you could have written, that stretch is filler. |
Prompt so the draft leaves room for you
Most people fight the model at the wrong end. If you ask for a finished article, you get confident generic sentences that are hard to unpick later. Ask instead for a draft with holes in it, and the editing job turns into filling blanks rather than deleting fluff.
| Produces hollow copy | Produces a fillable frame |
|---|---|
Write a 1,500 word review of [product]. Include pros and cons, pricing, and a conclusion. Make it engaging and SEO friendly. | Here are my raw notes from six weeks of using [product]: [paste log]. Draft the structure only. Where a claim needs first-hand proof, insert [EXP: what evidence is needed here] instead of writing a general statement. Never invent numbers, dates or outcomes. Flag anything my notes do not support. |
Two things change. The model works from your material rather than an averaged version of the internet, and every remaining gap is visibly marked, so nothing generic slips through just because it sounds plausible.
Add the proof layer
Claims of experience are worth more when a reader can check them. This is also where the page earns links, because original assets cannot be copied.
Proof Original images Screenshots with your data visible, or photos you took. Name the files descriptively and write alt text that describes what is shown, not the keyword. | Proof Methodology box Four lines near the top: what you tested, for how long, on what setup, and when. This single element separates a review from a rewrite. |
Proof Version and date stamps Software versions, model numbers, and the month of testing. Vague pages age badly and read as untested. | Proof Raw data Link the spreadsheet behind any chart. Almost nobody opens it. Its presence still changes how the page is judged. |
Make the byline do its job
Google’s guidance on helpful content asks publishers to self-assess against Who, How and Why. The Who questions are blunt: is it self-evident to visitors who wrote this, do pages carry a byline where a reader would expect one, and does that byline lead to real background about the person and the areas they cover.
The How section is where AI use is addressed directly. Google’s position is that disclosure is useful for content where somebody might reasonably wonder how it was made, and it suggests explaining what role automation played and why it was used. A two-sentence editorial note at the top of the article satisfies that without turning into a disclaimer.
Four things belong on every article that claims experience: a named author, a bio explaining why they are credible on this specific topic, a link to a fuller author page, and a last-updated line that says what changed.
The line not to cross The rater guidelines were tightened to flag exaggerated claims of personal experience or expertise. Inventing a test you did not run is a trust failure, and trust failures are sitewide, not page level. If your experience is secondary, label it accurately. "I interviewed nine warehouse managers who use this" or "I read 200 support threads and grouped the complaints" is honest, verifiable and still beats a fabricated first-hand story. |
About the photographs in this document Figures 1 to 5 are openly licensed stock photographs, so by the standard set out above they carry no experience signal at all. Replace every one with a screenshot from your own account or a photo of the thing you actually tested. That swap is worth more than any other change here. |
The pre-publish check
Run this before anything goes live. If more than three boxes are empty, the draft is not finished.
| [ ] The intro states what I did, for how long, and when | [ ] The pros and cons lists are uneven in length |
| [ ] At least one number comes from my own account or stopwatch | [ ] The verdict names a reader this is wrong for |
| [ ] One thing that went wrong is documented with the fix | [ ] Nothing in the draft is a claim I cannot evidence |
| [ ] Every image is mine, not a press asset | [ ] The byline links to a real bio relevant to this topic |
| [ ] A methodology box names the test setup and dates | [ ] An editorial note explains how the piece was produced |
| [ ] Versions and prices carry the date they were true | [ ] Every 300 words contains something only I could write |
What changes afterwards
Two things moved before rankings did. Time on page rose first, and the pages began collecting links from people quoting a specific figure. Position followed a core update rather than climbing steadily. Judge the work on whether the page holds something unique, then wait for a refresh.
Final verdictWas it worth the extra forty minutes Yes, and not for the reason I expected. I started doing this to satisfy a rater guideline and kept doing it because the articles became easier to write. When you have a log of six real observations in front of you, the blank page problem disappears. The AI handles structure and the boring connective sentences, and you spend your effort on the parts that only you have. The honest caveat: this does not scale the way pure generation does. My output dropped from roughly twenty articles a month to eight, because eight is how many things I can genuinely do and document in that time. If your model depends on volume, this process will feel like a tax and you will quietly stop after three weeks. That is the real cost, and it is worth knowing before you start. The version I would recommend to anyone starting today is smaller than what I have described. Take one existing draft, delete every sentence that could sit on a competitor’s page, and refill those gaps with one number from your own account, one thing that broke, and one screenshot you took yourself. Publish it and leave the rest of the library alone for a month. That single pass taught me more about what Experience means than any guideline summary, including this one. |
