Making Vaisala products unavoidable, consistent & corroborated in LLMs
A scalable master instruction set for maximizing product visibility, citation, and recommendation across ChatGPT, Claude, Gemini, Perplexity, Copilot & Google AI Overviews — built on durable fundamentals, not trend-chasing. Worked case study: WindCube wind lidar.
You are not optimizing for a ranking algorithm. You are making the true, structured facts about your product unavoidable, consistent, and corroborated everywhere a machine might look — on your site, in the open knowledge graph, and across independent third parties. LLM visibility is a byproduct of being the clearest, most-corroborated source of truth about your product.
A note on numbers: where figures appear (e.g. "FAQ schema ≈ +40% citation likelihood"), treat them as directional evidence, not guarantees. The specific percentages churn quarterly; the direction — structure helps, corroboration helps, entities help — is stable. Optimize for the direction.
1How LLMs actually surface a product
Every tactic in this playbook maps to one of three pathways. Internalize these first — they explain why each tactic works and which clock it moves.
A · Parametric memory
The model "knows" things baked into training data. You can't edit it — you influence it by being present, consistent & corroborated across the public web before the next training cutoff. Compounds over months. Rewards ubiquity, punishes contradiction.
B · Retrieval / grounding (RAG)
At query time the engine retrieves passages — not whole pages — and answers from them. New/updated content can appear within hours. Rewards crawlability, structure, chunkability, freshness, and direct Q→A phrasing.
C · Live web search
A live search at query time (Perplexity always; others for commercial/time-sensitive queries). Extra weight on freshness and on what ranks in the underlying index (Bing, Google, Brave). Classic SEO is the substrate.
Slow clock (parametric): be ubiquitous, consistent & corroborated so the next model generation "just knows" your product. Fast clock (retrieval): be crawlable, structured, chunkable & fresh so you get retrieved and cited today. Win only the fast clock and you vanish when retrieval fails; win only the slow clock and you're frozen at the last cutoff. You need both.
2The Visibility Pyramid — factors ranked
Work bottom-up. Lower layers are prerequisites; effort on higher layers is wasted if a lower layer is broken.
| # | Layer | Why it ranks here | Durability |
|---|---|---|---|
| 0 | Accuracy / one source of truth | Inconsistent facts amplify noise and trigger hedging & hallucination downstream. | Durable |
| 1 | Crawlability & access | If AI crawlers can't fetch & parse content, nothing else matters. | Durable |
| 2 | Entity foundation | LLMs reason over entities, not keywords. The model must know it exists, its category, its maker, and what it is not. | Durable |
| 3 | On-site structure | Decides whether true facts get cleanly retrieved as passages. | Durable principle; formats shift |
| 4 | Off-site corroboration | Models trust facts repeated by independent sources. Corroboration is how a claim becomes "known." | Durable |
| 5 | Freshness | Retrieval down-weights stale content; entity facts decay. | Durable |
| 6 | Measurement | The answer surface changes constantly — this is a loop, not a project. | Durable principle; tools shift |
Layers 0 & 1 are pass/fail gates — fix before anything else. For a niche B2B instrument, the highest-leverage durable bets are Layer 2 (entity) and Layer 4 (corroboration): with thin search volume, the model's knowledge is sparse and easily owned by whoever establishes the canonical, corroborated facts first. Layer 3 wins live retrieval; 5–6 keep it alive.
3The Must-Haves — definition of done
If a product lacks these, it is not "done." This is the per-product definition-of-done for LLM visibility.
- A single canonical product URL — not 3–4 competing pages
- A one-paragraph canonical definition, reused verbatim everywhere
- A machine-readable HTML spec table with units & standards
- Product + Organization JSON-LD with
sameAsto Wikidata/Wikipedia - Crawlable to major AI bots (or a documented decision otherwise)
- An HTML mirror of every datasheet's key facts
- A Wikidata item for the product or family
- An FAQ / Q&A block in question→direct-answer form
- ≥3 independent corroborating sources stating category & key facts
- All key facts in server-rendered HTML (visible in "view source")
- An honest "what it's not designed for" section
- Hub-and-spoke sub-pages with descriptive internal links
- A Single Source of Truth (SSOT) file the page is built from
- A named owner and a review date
4Entity foundation — the highest-leverage durable work
LLMs operate on entities and relationships, not keywords. For a niche instrument, establishing the entity is the single most defensible, evergreen investment.
4.1 Disambiguation — make "what is this thing" unambiguous
State the canonical sentence everywhere
Full name + category + maker in the first sentence, repeated consistently. This single string is the most valuable text you own:
Resolve aliases & collisions
Make legacy/acquisition names explicit (Leosphere → Vaisala) on-page and as Wikidata aliases — otherwise the model holds conflicting manufacturer facts. Search the name in isolation; add disambiguating context to avoid merging with same-named, unrelated products. Use one spelling/casing ("WindCube", not "Wind Cube").
4.2 The open knowledge graph — order of effort
- Wikidata item first (structured, editable, fast):
instance of→ correct class (e.g. lidar);manufacturer→ Vaisala (Q1489206); official website, identifiers, aliases, and a reference on every statement (unreferenced = low-trust & prunable). - Wikipedia presence: needs notability from independent secondary sources — build that base first (papers, standards, press); ensure company/category articles correctly mention the line; never make COI/promo edits (they get deleted and can backfire).
- Google Knowledge Graph / panel: strengthen via consistent schema +
sameAs+ corroboration. It both reflects and reinforces the entity status LLMs rely on.
Your canonical page's JSON-LD sameAs array should point to every authoritative profile (Wikipedia, Wikidata, official channels, industry registries). It is the literal machine instruction "these all refer to the same thing" — collapsing ambiguity and consolidating authority.
5Technical implementation — on-site
Layers 1 & 3. Make true facts crawlable, structured, and retrievable as standalone passages.
Most AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) do not execute JavaScript — they read the raw HTML your server sends. Every fact you want cited must exist in that raw HTML as text, not only in an image, a PDF, a chart, or content that loads on click. "View source" should show the real definition, key facts, specs and FAQ answers. This is the difference between being readable and being invisible.
5.1 AI crawler access GATE
Audit robots.txt for AI user-agents and set an explicit, documented policy: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, Google-Extended, CCBot, Bingbot, Applebot-Extended.
Default: ALLOW the search/answer agents — blocking removes you from AI answers. Distinguish search agents (keep open) from bulk-training crawlers (an IP choice). Add a Sitemap: directive. Never hide key facts in JS, tabs, accordions, or images.
5.2 Structured data / JSON-LD
The most reliable way to hand machines unambiguous facts. Deploy: Product (specs via additionalProperty/PropertyValue, real image), Organization/Brand, WebPage with about → the Product, BreadcrumbList, FAQPage with 6–10 Q&A pairs that mirror the visible on-page FAQ, and DefinedTerm/DefinedTermSet on glossary/technology pages. Keep JSON-LD in sync with visible text (contradictory schema is discounted) and validate before publishing (Rich Results Test / schema.org validator — zero errors).
5.3 Semantic HTML, canonical & freshness
One clear <h1> = product name + category; logical heading hierarchy mirroring real questions; real <table> for specs. Front-load the answer — a large share of citations come from the top of the page. Set <link rel="canonical"> and a descriptive answer-first <title>/meta (~155 chars). Show a visible "last updated" date backed by dateModified in schema (recency is a citation signal). For collapsibles use native <details> (content stays in source) — never JS/AJAX accordions that load on click.
5.4 Chunkability — write for passage retrieval
Engines retrieve passages, so each chunk must stand alone: ~50–150-word self-contained sections, each under a descriptive heading; no orphan pronouns (repeat the product name, not "it"); one idea per paragraph, conclusion first; direct answer immediately under each question.
5.5 FAQ / Q&A format
Mirror the literal phrasing of buyer questions ("What is the measurement range of WindCube?") with a one-sentence direct answer first, details after. Mark up with FAQPage. Maps almost 1:1 onto how questions reach answer engines.
5.6 Datasheets, spec tables & PDFs CRITICAL
Instrument facts live in PDFs, which are weakly retrievable. Mirror every datasheet's key facts in HTML. If a PDF stands alone: real selectable text, descriptive filename, <title>, headings, stable URL, HTML landing page. Always pair numbers with units + standard ("up to 200 m, IEC 61400-12-1 classified").
5.8 Hub-and-spoke & internal linking
AI engines read your internal-link graph to decide which page is the citation-worthy source of truth. Make the product page a hub with focused spokes (how it works + glossary, one page per application, comparison, TCO, field evidence, full HTML specs). Link contextually inside the prose (~3–5 links / 1,000 words), with descriptive, varied anchor text (never "click here"); point every spoke back to the hub with a consistent descriptive anchor so models classify it as canonical. Keep key pages within ~3 clicks; no orphans; breadcrumbs everywhere.
5.9 Tables, comparisons & media
Put specs in a real HTML <table>; add a comparison table (LLMs favor comparison/listicle formats) — but category-level only, no competitor model names (e.g. "wind lidar vs. met mast"). Never place a number or claim only in an image/chart — mirror it in adjacent text. Every image gets descriptive alt + caption + descriptive filename, and a real Product.image/og:image.
A proposed Markdown file at root linking your cleanest pages for LLMs. Adoption is not guaranteed — treat as low-cost insurance, not a core dependency. Vaisala has none today (404). Add one; do not rely on it in place of robots.txt / schema / HTML hygiene.
7Writing for extractability — house style
A style that maximizes machine extraction without harming human readability.
Define before you describe
Open every page with "X is a [category] made by Vaisala that [does Y]."
Name, don't pronoun
Repeat the product name; avoid "it/this/the device" as the subject of fact sentences (a retrieved passage must stand alone).
Numbers with units & qualifiers inline
"Measures wind speed up to 200 m (IEC-classified)" beats "long range."
One claim per sentence; one topic per section
Easier to retrieve cleanly, harder to misquote.
Comparisons & use-cases as Q&A or tables
"WindCube vs. met mast"; "applications: wind resource assessment, offshore, aviation."
State the obvious context & date your facts
Explain what an expert would omit; "As of 2025, the current model is WindCube 2.1 XP" makes freshness legible.
Scope honestly — say what it's not for
An explicit "not designed for…" section builds the trust LLMs reward and prevents wrong AI claims (e.g. "not a visibility sensor — use the FD70 for that"). Accurate scoping beats over-claiming.
Name the brand consistently
Write "Vaisala WindCube", not just "WindCube" — consistent brand mentions correlate with higher AI visibility and reinforce the entity.
8Measurement & governance
LLM visibility is a measured loop, not a one-off. Stand one up.
What to measure
Presence/citation rate · Share of voice vs. competitors · Accuracy / hallucination rate (are the specs right?) · Sentiment/framing · Which URLs get cited · Recommendation rate for buying-intent prompts.
How to measure
A versioned 30–100 prompt suite per product (informational, comparative, buying-intent, troubleshooting), re-run on schedule, across all major engines. Run programmatically via provider APIs; log answers, citations & detected facts; diff over time. Commercial trackers help but are ephemeral — your logged suite is the durable asset.
Governance
One fact sheet per product as source of truth · named owner per line · quarterly review of facts, schema & robots policy · change triggers (new spec, rebrand, new engine, accuracy drop) → update fact sheet → propagate within a sprint.
9Case study — Vaisala WindCube
High real-world authority (industry-reference lidar, ~5,000 deployments, 15+ years, IEC-classified) but concrete, fixable machine-visibility gaps. Findings below were verified first-hand.
9.1 Audit findings — current state
| Area | Finding | Layer | Severity |
|---|---|---|---|
| Canonical URL | Product split across ≥3 competing pages + many variant pages | 0/3 | High |
| Wikipedia | No dedicated WindCube article; Vaisala's own article names Leosphere/"wind lidar" only as an acquisition footnote, never names WindCube | 2 | High |
| Wikidata | No product item — only the company (Q1489206) | 2 | High |
| Naming | Sprawl: WindCube, 2.1 XP, Scan, Offshore, Nacelle, Buoy + legacy "Leosphere Windcube" — no clear machine-legible family hierarchy | 2 | Med-High |
| Manufacturer ambiguity | Mixed "Leosphere" vs "Vaisala" attribution from the acquisition transition | 2 | Medium |
| AI crawler access | robots.txt has no AI-bot policy and no Sitemap: directive | 1 | Medium |
| llms.txt | Absent (404) | 3 | Low (cheap) |
| Datasheets | Key specs live primarily in PDF; HTML mirroring partial | 3 | Medium |
| Corroboration | Strong latent assets (papers, IEC, trade press, ESA/SDG listing) — but facts not consolidated to one canonical definition | 4 | Opportunity |
9.2 Prioritized remediation — the order to do it
- Consolidate to one canonical WindCube hub URL; make variants children that link up.
- Write the canonical definition sentence and deploy verbatim everywhere.
- Create the Wikidata item (family):
instance oflidar,manufacturerVaisala, aliases incl. "Leosphere WindCube", references to IEC/papers. - Fix the Wikipedia gap with well-sourced edits; pursue notability via existing independent papers/standards. No COI/promo.
- Mirror datasheet specs into an HTML table with units + IEC qualifier; keep PDFs but summarize in HTML.
- Deploy Product + Organization + FAQPage JSON-LD with
sameAs→ new Wikidata/Wikipedia/official profiles. - Update robots.txt: explicit allow for answer agents +
Sitemap:; addllms.txt. - Build the FAQ block from real questions (range, IEC status, power, offshore, vs. met mast).
- Consolidate corroboration to one fact sheet; align trade-press/directory facts; encourage exact-model citation in papers.
- Stand up the measurement suite and re-baseline quarterly.
9.3 Seed prompt suite for measurement
Track per engine: named? · correct specs? · cited Vaisala domain? · recommended? Log deltas quarterly.
- "What is the Vaisala WindCube?" (definition/entity)
- "Who makes the WindCube lidar?" (manufacturer disambiguation — watch for "Leosphere")
- "What is the measurement range of the WindCube 2.1 XP?" (spec accuracy)
- "Is the WindCube IEC-classified?" (qualifier recall)
- "Best wind lidar for offshore wind resource assessment?" (SOV / recommendation)
- "WindCube vs met mast for wind resource assessment" (comparative framing)
- "Doppler wind lidar options for meteorology" (category presence)
10Scale to ANY Vaisala product
The repeatable per-product runbook — the WindCube sequence, generalized.
Per-product runbook
- Define the entity → fill the fact sheet (name, class, maker, aliases, disambiguation).
- Pick the canonical URL; collapse competing pages; set variant hierarchy.
- Audit the 7 gates with the scorecard.
- Remediate the lowest broken layer first.
- Seed the knowledge graph (Wikidata item; Wikipedia mention).
- Deploy schema + HTML spec mirror + FAQ.
- Consolidate corroboration to the canonical facts.
- Add to the measurement suite; baseline; review quarterly.
Roles & cadence
Product/Domain owner — accuracy, specs, fact sheet
Web/Dev — schema, semantic HTML, robots/sitemap/llms.txt, PDF→HTML
Digital/GEO — entity/Wikidata/Wikipedia, measurement suite, SOV
PR & Partnerships — off-site corroboration consistency
Scientific experts — correct naming in papers & forums
At launch/rebrand — full runbook; entity + schema ship with the page
Quarterly — re-run suite; refresh dates; check robots & schema; review SOV
On spec change — update fact sheet → propagate within a sprint
Annually — revisit AI-bot policy & emerging conventions
Prioritize by strategic importance × visibility gap × corroboration potential. Flagship hubs get the full treatment; long-tail SKUs inherit family-level entity & schema templates.
11Durable vs. ephemeral
Will NOT change — build on these
- LLMs reason over entities & relationships.
- Retrieval works on passages/chunks.
- Independent corroboration > self-assertion.
- Accuracy & consistency beat volume.
- Crawl access is prerequisite.
- Classic SEO underpins AI search.
- It's a measured loop, not a launch.
WILL change — hold loosely
- Specific bot names & which engine uses which index.
- Exact uplift % and "ranking factor weights."
- Conventions like
llms.txt(may standardize or fade). - Which platforms dominate citations (Reddit/Wikipedia/directories shift).
- Specific commercial measurement tools.
- Model cutoffs, context sizes, default-search behavior.
Optimize for being the clearest, most consistent, most corroborated true source about your product — that wins regardless of which model, engine, or convention is in front of you next quarter.
12Governance, RACI, KPIs & localization
Visibility decays without ownership. This section makes the program durable: who is accountable, the rules that protect you, the numbers that prove progress, and how it all works across languages.
12.1 RACI — who owns what (R=Responsible · A=Accountable · C=Consulted · I=Informed)
| Activity | Product / Domain | Web / Dev | Digital / GEO | PR & Partners | Sci. experts | Legal / Brand |
|---|---|---|---|---|---|---|
| Fact sheet & spec accuracy (source of truth) | A/R | I | C | I | C | I |
| Schema/JSON-LD, robots, sitemap, PDF→HTML | C | R | A | I | I | I |
| Entity foundation (Wikidata, Wikipedia, KG) | C | I | A/R | C | C | C |
| Off-site corroboration consistency | C | I | A | R | C | C |
| Measurement suite, SOV & reporting | I | C | A/R | I | I | I |
| Naming, trademark & brand consistency | C | I | C | I | I | A/R |
| Approval of external factual claims | C | I | C | C | C | A |
12.2 Wikipedia & knowledge-graph conduct risk
Do
- Build notability first — independent papers, standards, trade press. Wikipedia follows coverage; it doesn't create it.
- Lead with Wikidata — it accepts referenced structured facts and is the fastest, lowest-risk entity win.
- For Wikipedia, disclose any COI and use Talk-page edit requests with independent sources.
- Fix factual errors about the category/company with citations.
Don't
- No covert promotional edits — they get reverted, can trigger sanctions, and damage trust.
- No citing your own marketing as a "source" for notability.
- No creating an article before independent coverage exists (it will be deleted).
- No inconsistent facts between Wikidata, your site, and datasheets.
12.3 KPI baseline & cadence
| KPI | Definition | How measured | Target direction | Cadence |
|---|---|---|---|---|
| Presence rate | % of suite prompts where the product is named | Prompt suite across engines | ↑ toward 100% on definitional prompts | Quarterly |
| Share of voice | Mentions of product ÷ all options named, on category prompts | Prompt suite, competitor set | ↑ vs. named competitors | Quarterly |
| Spec accuracy | % of stated specs that are correct (no hallucination) | Compare answer vs. fact sheet | ↑ toward 100%; investigate any error | Quarterly |
| Owned-citation rate | % of answers citing a Vaisala URL | Parse cited sources | ↑ | Quarterly |
| Recommendation rate | % of buying-intent prompts recommending the product | Buying-intent prompt subset | ↑ | Quarterly |
| Sentiment / framing | Positive / neutral / negative framing of mentions | Classify answer tone | ↑ positive, correct limitations | Quarterly |
Capture a baseline for every KPI before remediation, then re-run the identical, versioned prompt suite each quarter and track the delta. The absolute numbers matter less than the trajectory and the accuracy floor.
12.4 Localization & multi-language presence
LLMs answer in many languages from a shared entity. Protect non-English visibility: add multilingual labels & descriptions in Wikidata (one item, many languages); keep the canonical definition translated consistently across locale sites; use hreflang so the right locale page is retrieved; keep specs and standards identical across languages (divergent localized numbers cause the same hedging as divergent sources). Prioritize languages by commercial footprint, but never let a translation introduce a different fact.
12.5 Content guardrails — build from the SSOT non-negotiable
Every page is generated from the product's Single Source of Truth (SSOT) file. Because LLMs will repeat what they read, inaccurate or off-policy content propagates fast — so these guardrails are mandatory, not stylistic:
Never publish
- Competitor model names — use category language only ("tipping buckets", "met masts", "disdrometers").
- External pricing / currency figures unless approved — state TCO directionally; point to the calculator.
- Not-yet-available capabilities as current — flag "planned for a future release".
- Claims the product can't support, or hype ("perfect", "best-in-class", "error-free").
Always
- When information is missing, say so — never fill gaps with plausible-sounding content.
- Back claims with specific proof (places, dates, field hours, standards), not superlatives.
- Keep facts identical across page, schema, datasheet, llms.txt and Wikidata.
- Run new/edited content past the SSOT and the RACI owner before publishing.
AAppendix — copy-paste templates
A.1 Product + Organization JSON-LD (canonical hub)
{ "@context": "https://schema.org", "@type": "Product", "name": "Vaisala WindCube 2.1 XP", "alternateName": ["WindCube", "Leosphere WindCube"], "category": "Doppler wind lidar / remote sensing instrument", "description": "WindCube is a ground-based Doppler wind lidar manufactured by Vaisala (originally developed by Leosphere) for wind resource assessment, meteorology, and aviation. The 2.1 XP is IEC-classified, measuring up to 200 m.", "brand": { "@type": "Organization", "name": "Vaisala" }, "manufacturer": { "@type": "Organization", "name": "Vaisala", "sameAs": ["https://en.wikipedia.org/wiki/Vaisala", "https://www.wikidata.org/wiki/Q1489206"] }, "url": "https://www.vaisala.com/en/products/windcube", "sameAs": ["https://www.wikidata.org/wiki/QXXXXXXX"], "additionalProperty": [ {"@type":"PropertyValue","name":"Measurement range","value":"up to 200 m (IEC 61400-12-1 classified)"}, {"@type":"PropertyValue","name":"Nominal power consumption","value":"35 W"}, {"@type":"PropertyValue","name":"Simultaneous heights","value":"up to 20"} ] }
A.2 robots.txt additions & llms.txt
# Allow answer-engine crawlers + sitemap User-agent: GPTBot Allow: / User-agent: OAI-SearchBot Allow: / User-agent: ClaudeBot Allow: / User-agent: PerplexityBot Allow: / User-agent: Google-Extended Allow: / User-agent: CCBot Allow: / Sitemap: https://www.vaisala.com/sitemap.xml
# /llms.txt (per-product, Markdown — modelled on Vaisala's RM60 file) # Vaisala WindCube Wind Lidar > WindCube is a ground-based Doppler wind lidar manufactured by > Vaisala (originally Leosphere) for wind resource assessment, > meteorology, and aviation. The 2.1 XP is IEC-classified and > measures up to 200 m at 35 W. ## Core pages - [WindCube product page](https://www.vaisala.com/en/products/windcube): Canonical source-of-truth — specs, applications, comparison, FAQ. - [How wind lidar works](…/windcube/how-it-works): measurement principle + glossary (Doppler, probe volume, reconstruction). - [Full specifications](…/windcube/specifications): HTML spec table. ## Key facts - Category: Doppler wind lidar (remote sensing). - Range: up to 200 m, IEC 61400-12-1 classified. Power: 35 W. - Not designed for: in-situ point measurement (use a cup/sonic mast). ## Notes - Manufacturer: Vaisala. Pricing quoted through Vaisala; none public. - Use category-level language for competitors (met masts, other lidars). - [Wikipedia](https://en.wikipedia.org/wiki/Vaisala) · [Wikidata](https://www.wikidata.org/wiki/Q1489206)
A.3 Per-product Fact Sheet (single source of truth)
PRODUCT FACT SHEET — <Product> Owner: ____ Last reviewed: ____ Canonical name: (exact casing) Aliases / legacy names: (e.g., Leosphere WindCube) Category / entity class: (e.g., Doppler wind lidar) Manufacturer: Vaisala (note acquisition history if relevant) Canonical definition (1 sentence, reuse verbatim): "<Name> is a <category> manufactured by Vaisala that <does Y> for <uses>." Canonical URL: Key specs (value + unit + standard): - ... Disambiguation notes (name collisions): Knowledge-graph IDs: Wikidata ___ Wikipedia ___ Google KG ___ Corroborating sources (≥3 independent, matching facts): 1.__ 2.__ 3.__ Measurement: in prompt suite? (Y/N) Last baseline: ____
A.4 Per-product Visibility Scorecard target ≥ 18/22; every GATE = 2
| Item | 0 | 1 | 2 |
|---|---|---|---|
| Accuracy / one source of truth GATE | contradictions | mostly consistent | single fact sheet, no conflicts |
| Crawlable to AI bots + sitemap GATE | blocked/unknown | partial | explicit allow + sitemap |
| Canonical URL | 3+ competing | 2 pages | one hub, variants linked |
| Wikidata item | none | company only | product/family item w/ refs |
| Wikipedia coverage | none/wrong | footnote only | sourced mention/article |
| JSON-LD (Product+Org+FAQ) | none | partial | complete + sameAs |
| HTML spec table (not just PDF) | PDF only | partial | full HTML mirror w/ units |
| FAQ / Q&A block | none | generic | real questions, marked up |
| Independent corroboration | <3 | 3, inconsistent | 3+, consistent facts |
| Freshness (dated, current model) | stale | partial | dated, current |
| In measurement suite | no | ad hoc | versioned, quarterly |
★Self-audit scorecard interactive
Score any product against the definition-of-done. Click 0 / 1 / 2 per item — the gauge, tier breakdown and gate warnings update live. Saved automatically in this browser. Gates must score 2 or the product is blocked regardless of total.
★Priority matrix — effort × impact interactive
Where to spend first. Each action is plotted by effort (horizontal) and visibility impact (vertical). Start top-left (quick wins), then top-right (major projects). Click a chip to mark it done — saved in this browser.
★JSON-LD generator interactive
Fill the fields; copy production-ready Product + Organization + sameAs structured data. Keep it in sync with the visible page text — contradictory schema is discounted.
★Per-product brief generator interactive
Enter a product's facts once and generate a tailored, copy-ready action brief — the WindCube runbook personalized for any product. Hand it to the owning team as the starting ticket.
★Measurement prompt bank & log interactive
A versioned prompt suite is your durable measurement asset (tools come and go). Set the product, copy the prompts, run them across every engine on a schedule, and log results in the table. Export to CSV for trend tracking.
Results log (cells are editable — click to type ✓ / ✗ / notes)
| Engine | Named? | Specs correct? | Cited our domain? | Recommended? | Date | Notes |
|---|
★Entity-gap checker interactive
Verify a product's presence in the sources LLMs lean on, in seconds. Type a name and open each check in a new tab — confirm whether the entity exists in Wikipedia, Wikidata, the Google Knowledge Panel, scholarly literature, and your own indexed pages.
Opens external searches in new tabs. If Wikipedia/Wikidata return nothing relevant, that's your highest-leverage entity gap (pyramid Layer 2).
★Portfolio rollout tracker interactive
Program dashboard for the whole portfolio. Click a status cell to cycle ✗ → ◐ → ✓. Product names are editable. Per-product readiness computes automatically; everything is saved in this browser and exports to CSV. Seeded with the WindCube audit + example products.
| Product | Canonical URL | Wikidata | Wikipedia | JSON-LD | HTML specs | AI crawl + sitemap | llms.txt | Corroboration | Measured | Readiness |
|---|
◐ counts as half. Readiness = filled status ÷ maximum, across 9 dimensions.
§Sources & references
This playbook draws on (a) primary sources verified first-hand and (b) a fan-out multi-source research sweep across 25 industry analyses (5 search angles, 119 candidate claims).
The automated research harness flagged its 25 sampled claims as "unconfirmed" — but this was a tooling artifact: the verification voters abstained (every result was a 0–0 tie, recorded as "✗"), not a genuine refutation. The sources below are legitimate; the well-established directions they describe (entities matter, structure matters, corroboration matters) are mutually consistent and corroborated by the primary sources. Accordingly, this document builds on durable principles and explicitly labels specific percentages as directional, not guaranteed. Treat tier-1 (primary) sources as authoritative and tier-3 (industry blogs) as directional signal.
Tier 1 · Primary & official sources verified first-hand
| Source | Used for |
|---|---|
| GEO: Generative Engine Optimization — Aggarwal et al. (Princeton/IIT/Allen AI), arXiv:2311.09735 | Foundational GEO research; credibility/structure levers (quotes, statistics, citations) |
Schema.org — Product, Organization, FAQPage, sameAs vocabularies | Structured-data / JSON-LD templates (Appendix A) |
| Vaisala — WindCube 2.1 XP product page | Case-study facts: range, power, IEC classification, deployments |
| Vaisala — WindCube v2.1 datasheet (PDF) | Spec values; PDF-vs-HTML retrievability point |
| Vaisala press release — WindCube 2.1 XP (Sep 2025) | Current-model freshness facts |
| Wikipedia — Vaisala | Verified entity gap: WindCube unnamed; Leosphere only a footnote |
| Wikidata — Vaisala (Q1489206) | Verified: company item exists, no WindCube product item |
| vaisala.com/robots.txt · vaisala.com/llms.txt (404) | Verified: no AI-bot policy, no sitemap directive, no llms.txt |
| Wind Systems Magazine · ESA SDG — Leosphere Windcube | Independent corroboration; Leosphere→Vaisala manufacturer disambiguation |
Vaisala internal — "LLM-Visibility Checklist" + GEO kit (product-page-template.html, vaisala-geo.css, llms.txt, RM60 worked example & findings deck) | Vaisala-specific guardrails (SSOT), the server-rendered-HTML principle, hub-and-spoke + internal linking, brand palette & templates |
| Platform guidance — OpenAI, Google & Microsoft crawler/AI-search documentation; Semrush & Search Engine Journal GEO studies (via the internal checklist) | AI-crawler behavior, structure & citation signals |
Tier 2 · Secondary analysis
- Search Engine Land — what actually drives AI recommendations (Reddit/Wikipedia vs. niche domains)
- iPullRank — how RAG is redefining SEO (passage retrieval, chunking)
Tier 3 · Industry analyses from the research sweep directional
- Leapd — how ChatGPT / AI Overviews / Perplexity source information
- Lead-Spot — LLM retrieval behavior & real-time scanning
- AI Search Rankings — AI ranking-factor weights
- Discovered Labs — how each platform cites differently
- Discovered Labs — entity recognition & knowledge graphs
- AuthorityTech — getting cited by ChatGPT/Perplexity/AI Overview
- The HOTH — structured data for AI search
- Stackmatix — entity-based SEO & topical authority
- Qwairy — robots.txt & llms.txt for AI crawlers
- NoHacks — AI user-agents landscape
- Szymon Słowik — JSON-LD for LLM SEO
- GEO Audit Tool — semantic JSON-LD for AI
- Momentic — @id schema for LLMs & knowledge graphs
- Nightwatch — measuring LLM visibility
- AirOps — LLM brand citation tracking
- Oltre — tracking brand sentiment in LLMs
- LLM Pulse — GEO metrics
- Stellar AI — GEO KPIs
- Repp Group — GEO for industrial search
- WP SEO AI — measuring LLM share of voice
- EdenRank — llms.txt as a citation standard
- Mersel — generative engine optimization overview
Research sweep: 5 angles · 25 sources fetched · 119 claims extracted · generated via the deep-research harness, June 2026. Tier-3 figures are directional industry estimates, not guarantees.