How to add an original test to a GEO article
Document the question, setup, inputs, date, environment, procedure, output, and limits. Separate what you observed from the broader recommendation.
Written for a technical editor publishing first-hand tests of search, AI, website, API, or software behaviour.
Key facts
- A first-hand test needs a reproducible setup and an unedited result record.
- Observed behaviour and documented platform rules should receive separate labels.
- The conclusion should stay within the tested system, inputs, and date range.
A useful rule: make each important claim understandable and verifiable without requiring the reader to reconstruct your meaning from the rest of the page.
The direct answer
State the hypothesis and the decision the test informs. Record the tested URL or artifact, system and version, account state, location, device or user agent, date, exact inputs, procedure, and raw output. Publish enough detail for another person to understand the setup. Describe the result as an observation under those conditions, compare it with primary documentation, and avoid extending one run to every model, query, or site. The finished work should let a reader or reviewer identify the subject, the intended result, the evidence behind the recommendation, and the next action without reconstructing your reasoning. Keep material conditions in the same passage as the claim they limit. Use the canonical public page as the source of truth, since search engines and answer systems retrieve pages rather than private briefs. Google describes useful, reliable, people-first content and ordinary search eligibility as the foundation for both search results and its AI features. No heading pattern or schema type can compensate for a page that gives a vague answer, hides its evidence, or serves a different intent from its title. Complete the task for one named reader first, then check how the result appears to crawlers and extraction tools.
- A first-hand test needs a reproducible setup and an unedited result record.
- Observed behaviour and documented platform rules should receive separate labels.
- The conclusion should stay within the tested system, inputs, and date range.
Prepare the page and evidence before editing
Choose a question that documentation does not resolve or a production behaviour that needs confirmation. Write the expected outputs and failure labels before testing. Save relevant documentation and the current version of the page or software. Save a baseline before you change anything: the public URL, response status, canonical, visible title, main heading, opening answer, source links, and the date you checked them. Record the target question in the reader's words and write one sentence describing the decision the page supports. This baseline prevents a common measurement error where several edits ship together and nobody can tell which one improved the result. It also gives editors a compact source ledger. A reviewer can compare each material statement with the cited page, its jurisdiction or product version, and its checked date. If the task affects a generated template, inspect several representative URLs rather than assuming one record proves the template works for every content shape.
- Define the independent variable and the output you will observe.
- Control or record confounders you cannot hold constant.
- Set a stop rule and sample size that match the modest decision.
Complete the process in five controlled steps
Work through the five steps in order and keep one output from each step. The order protects you from polishing copy while a crawl, canonical, intent, or evidence problem still blocks the page. Each output should be small enough for another person to verify from the public URL. Use plain labels and stable entity names throughout the page. When a changing fact controls the answer, cite the primary source beside that fact and include the relevant date or version. After each step, compare the output with the primary question. Remove any section that serves a different reader decision, and link to a separate guide when the adjacent task deserves its own page. This creates a focused answer instead of a broad page assembled from loosely related keywords.
- 1. Freeze the protocol: Write inputs, environment, sequence, capture method, and labels before the run. Evidence of completion: The method cannot drift to fit the result.
- 2. Capture raw output: Save responses, screenshots, headers, logs, or answer text with timestamps. Evidence of completion: Readers can distinguish the record from the summary.
- 3. Repeat the run: Use enough repetitions to reveal obvious variability and keep failed cases. Evidence of completion: The article does not rely on one selected output.
- 4. Compare documentation: Check whether the observed behaviour agrees with current first-party guidance. Evidence of completion: The article separates supported rules from unexpected observations.
- 5. State the boundary: Limit the conclusion to the tested conditions and list the decision it supports. Evidence of completion: Readers do not receive a universal claim from a narrow test.
A worked example
An editor tests whether a client-rendered answer appears in fetched HTML. The protocol names the production URL, deployment version, raw HTTP client, browser renderer, user agents, and July 27 test date. The raw response lacks the answer while the rendered DOM includes it. Google's JavaScript SEO documentation says Google can render JavaScript, but the test does not claim every crawler or preview client will execute the page. The recommendation favours server-rendering the critical answer for deterministic access, labelled as an engineering choice based on the observed output. Treat the example as a model of the reasoning, not as a universal benchmark. The useful part is the chain from question to evidence to action. Preserve the exact entity names, scope, and conditions that a reader would need if an answer engine quoted the passage outside the page. If a number comes from a report, state the reporting window. If a result comes from a test, state the URL type, device or crawler, and date. A compact example earns its space when it helps the reader make the same decision on another page. Remove invented precision, anonymous authority, and conclusions that reach beyond the recorded evidence.
- Documentation and production output can answer different parts of the decision.
- Named clients and versions keep a rendering claim bounded.
- An engineering recommendation should remain distinct from a platform requirement.
Avoid the mistakes that weaken the result
Original tests gain false authority when writers hide failed runs, omit environment details, or turn one observation into a claim about every product and site. Fix the first mistake that changes eligibility or meaning before editing smaller presentation details. Keep source boundaries visible: one citation should support the nearby claim, while a separate claim should receive its own source. Do not repeat the target phrase to manufacture relevance. Search systems can use titles, headings, visible text, links, structured data, and other signals, so those elements should agree on the subject without copying one sentence across the page. Check the public result after deployment because a correct content record can still produce the wrong page through caching, layout inheritance, JavaScript failure, or a stale build.
- Changing the method after seeing results introduces selection bias. Correction: Freeze the protocol and log deviations.
- Screenshots without text or timestamps weaken verification. Correction: Publish accessible output details and test dates.
- A broad headline overstates a narrow environment. Correction: Name the tested system or condition in the title and conclusion.
Verify the result and choose the next action
Invite reproduction, record corrections, and schedule retests when the product or framework changes. Track whether citations preserve the test conditions. Update the modified date when a new run changes the article's conclusion or evidence. Use a fixed observation window and compare like with like. Record the query set, country, device, page version, and publication or change date. Search impressions can show discovery and query matching; clicks and useful sessions show whether the result attracted the intended reader. Observed AI citations add a separate retrieval signal, but a citation count does not prove traffic or revenue. Review the cited passage when you can and check whether the answer preserved its subject, scope, conditions, and source. Keep the page stable long enough to collect evidence unless you find a factual error, broken route, security problem, or misleading claim. The next edit should respond to the strongest observed failure instead of a generic scoring recommendation.
- Keep raw artifacts linked from the internal research record.
- Have another reviewer follow the published method.
- Retire conclusions that no longer reproduce under the named setup.
Put it to work
Find the highest-impact fix on your site.
Capture protocol, raw output, source comparison, limits, and the next decision.
Run the documented testSources
- 1.Google Search Central: JavaScript SEO basicsChecked 2026-07-26
- 2.Google Search Central: Creating helpful, reliable, people-first contentChecked 2026-07-26
- 3.Liu et al.: Evaluating verifiability in generative search enginesChecked 2026-07-26