VeraTEST — Retrieval Coverage of a Low-Traffic Industrial B2B Domain

When people search with AI, they often get an answer instead of a list of links.

Traditional SEO asks one question:

Can people find my website?

AI search adds another:

When the system answers directly, does it use my website as the evidence?

We call that Retrieval Coverage.

Rankings measure where a page appears in a list of links. Retrieval Coverage measures whether a page is built into the answer itself. These are related but different outcomes. As AI-mediated search grows, both become measurable dimensions of visibility.

AI-mediated search also changes what a visit means. More and more, a user reads an answer before deciding whether to open any website at all. A ranking describes only one stage of visibility; Retrieval Coverage measures an earlier one — whether a page contributes evidence to the answer itself. A visit that happens after such an answer likely represents a later stage of the buyer's decision, though this report does not measure user behavior directly.

This report is our first published measurement of Retrieval Coverage.

It comes from a broader framework, Behavioral Responsivity:

Behavioral Responsivity is a behavioral model for organizing information under cognitive constraints. It models the relationships people rely on while seeking, understanding, and evaluating information, then represents them through information architecture, knowledge representation, and interface design.

Search, retrieval, and SEO are applications of that model. Retrieval Coverage is one way to measure its outcomes.

This report applies the model to one context: how buyers evaluate high-value industrial equipment.

---

About VeraTEST

Turkish supplier of environmental testing, vibration testing, and measurement equipment for aerospace, automotive, defense, electronics, and industrial R&D laboratories.

Domain registered December 31, 2024. Low traffic — about 70 unique visitors per month during the study.

The structural work described here was carried out over roughly three months.

---

Key findings

• In Google AI Overview, VeraTEST's pages were cited for 92.1% of its product and service queries.
• This followed three months of structural work on a low-traffic domain.
• Coverage was stable across three repeat runs and confirmed in a second browser (90.8% on the same product/service queries).
• Coverage failed only on category pages that had no text at the time, and on two product names that are ambiguous (§3).
• Three independent AI assistants also retrieved VeraTEST, which suggests the observation is not unique to Google.

---

1. What we predicted

Behavioral Responsivity starts from buyer behavior.

Its prediction is simple:

Pages built around the way a buyer actually makes a decision are retrieved more consistently by information-retrieval systems.

We evaluated that prediction on a live client.

Then we measured the result.

---

2. The result

In Google AI Overview, VeraTEST's own pages were cited for 92.1% of its product and service queries.

This came after about three months of structural work on a young, low-traffic domain.

We ran each query three times, in separate incognito sessions, and recorded every result — including the misses.

This is a retrieval outcome, not a traffic outcome. It measures whether the machine answering a buyer's question uses VeraTEST's pages as evidence.

One run, captured in the session behind these figures. VeraTEST holds the top two of three cited sources — the outcome this report measures, on a single query.

---

3. Google AI Overview — full results

The numbers

We tested 45 queries (37 products, 1 service, 7 broad categories), each 3 times = 135 runs.

Rates below name their denominator, because two are used: runs (135 answers returned) and present runs (the 112 in which VeraTEST appeared at all). Mixing them silently would flatter the result.

Two independent browsers agree. Coverage is high, and it is stable across repeat runs.

Restricted to the 38 product and service queries, the Chrome figures rise: Tier 4 on 47.4% of runs (54 of 114), a linked citation on 75.2% of present runs (79 of 105). The lower all-query numbers carry the seven empty category pages described below, which is why the product/service figure is reported as the headline and the all-query figure alongside it.

Per query

Present = number of the 3 runs where VeraTEST was cited. Best tier = highest citation level reached (tiers defined in §4).

At the query level: 28 of 45 reached Tier 4 at least once. 6 were never cited.

The misses

Six queries were never cited. Every one of them has a page — but none was cited, for two different reasons.

Four are category terms — Sensörler, İvmeölçer, Titreşim ve Şok Test Sistemleri, Çevresel Test Kabinleri. Their category pages existed, but at the time of the test they carried no descriptive text — only a list of the products beneath them. A retrieval system had nothing on the page to quote.

Two are specific products with full text — Güç Amplifikatörü and MEMS İvmeölçer — but the term is ambiguous. The answer drifted to a different meaning: audio power amplifiers, and consumer MEMS sensors.

So a page alone is not enough.

Two things are needed: descriptive text a system can quote, and a query that points unambiguously at that page.

Neither requirement is new, and we will not dress them up as a discovery. Both follow from textbook information retrieval. A document with no descriptive text has almost nothing to match a query against — the term-document representation that every retrieval model is built on is close to empty — and a term that resolves to a more common namesake is the classic disambiguation problem, familiar from both entity linking and query-ambiguity research. Manning, Raghavan and Schütze's Introduction to Information Retrieval covers both in its opening chapters. Anyone with an IR background would predict these two failure modes before running the test.

Observation 1 — the two failure modes. Across 45 queries, every failure fell into one of two classes: a page with no descriptive text (4 of 6), or a query term whose dominant sense points elsewhere (2 of 6). No query failed for any other reason.

Evidence status: consistent with established IR expectations; the distribution across the two classes is what this report contributes, and it comes from one site.

What the study adds is not the principle but the arithmetic. It puts a number on how much of a real catalogue's retrieval loss those two known failure modes account for — here, all of it — and it does so on an AI-generated answer surface rather than a ranked list. That the six misses partition so cleanly is worth reporting; that empty pages and ambiguous terms retrieve poorly is not.

The mechanisms themselves are not isolated by this design. We observe their footprint on one domain, not their operation.

---

4. Methodology (Google AI Overview)

Citation tiers

Every run was scored on one 0–4 scale. Each query in each run gets one tier: the highest it reached. We never double-count the same page.

• Tier 0 — Not present. VeraTEST does not appear in the answer or its sources.
• Tier 1 — Source only. VeraTEST appears in the sources panel, but not in the answer text.
• Tier 2 — Inline chip. A VeraTEST citation chip is attached to a sentence in the answer.
• Tier 3 — Named in text. VeraTEST is named in the answer's sentences, without a link.
• Tier 4 — Named and linked. VeraTEST is named in the answer's sentences, with a link to its page.

Higher is stronger. Tier 4 means the machine wrote VeraTEST into its answer and pointed to the page. In this dataset, no query rested at Tier 1.

Fixed variables

Every run recorded the same fields, so the test can be repeated.

Every query ran in a fresh incognito or guest session — no login, no search history, no saved location. That strips out personalization: the results are close to what an unknown, first-time visitor would see, not results shaped by our own past activity. It is the least-biased view of retrieval available without special access.

Scope of measurement

In Firefox we recorded VeraTEST presence only — not citation tiers. So Firefox is used as a presence check, and the tier analysis comes from Chrome.

Two fields were dropped because the screen recordings did not capture them reliably: average panel position and number of distinct sources per answer.

Why a manual protocol

Commercial platforms now estimate AI visibility by monitoring many prompts at scale. Their purpose is continuous brand monitoring over time.

This study asks a narrower question: whether a specific page becomes part of an answer under controlled, repeatable conditions.

Because that requires inspecting each answer at the page level, we used a manual protocol built for repeatability rather than scale.

What this can and cannot claim

It can claim high, repeatable retrieval coverage, confirmed across two browsers.

On cause, it goes as far as the evidence honestly allows — and no further.

The pre-rebuild state is documented on a dated screen recording (28 February 2026): the site was still "under construction," ran demo-theme content on query-string URLs (?p=…, ?page_id=…), and its product pages carried only thin, generic, partly machine-translated copy. Pages like that cannot be used as evidence by an AI answer — there is nothing on them to quote. The prior site had no AI Overview presence.

The work then ran in two phases. From 1 March 2026, the first six weeks reshaped the menu, slider, homepage, and category pages — presentation, not semantic work — so we do not count them as part of the intervention measured here. The structural (SEO) work ran 15 April to 15 July 2026: about three months. In that window the taxonomy, and with it the URLs, changed twice — in April, and again at the end of May. The retrieval test was recorded in mid-July, at the end of the work.

So the change is real: from pages that could not be retrieved, to citation in the large majority of product answers. The most plausible explanation is the rebuild — the content, structure, entities, and links this report describes.

What we cannot do is prove that in a controlled way. The changes shipped together, so we cannot isolate the contribution of any single one. We took no retrieval measurements on the same queries beforehand, so we cannot report a measured before-to-after figure. And we cannot rule out concurrent factors — the domain aged, and AI Overview itself expanded over the same period.

So we state it plainly: the coverage is most plausibly attributable to the rebuild, but this is a strong association, not a controlled causal estimate.

---

5. The idea behind the method

Not every search is a decision. People also search to learn, to be entertained, or to pass time.

But the moment this report is about is a decision. On a product page like these, the visitor is there to choose equipment they will depend on.

People make those decisions under real limits — limited attention, limited working memory. So the useful thing a page can do is reduce their biggest uncertainties first, with evidence they can trust.

A retrieval system, in turn, tries to understand that decision from the information on the page.

So we start with the decision itself. For any product page, we ask:

• What does the buyer need to know first?
• What evidence reduces their uncertainty?
• Which concepts belong together?
• How should those concepts connect?

One idea runs underneath all of it:

Represent the information that is both most useful to the decision and hardest to fake.

A number like 80 kN, a standard like IEC 60068-2-64, a real list of compatible accessories — these are useful and they cannot be shown without actually having the capability. Slogans are neither.

So we favor durable, verifiable evidence over surface optimization — because such evidence is inherently more valuable for human information-seeking.

Note the direction of the claim: our framework favors this evidence for that reason. We do not claim a search engine rewards it. Our experiment then measures whether retrieval systems also appear to favor pages built this way.

That gives a clean chain of reasoning:

1. First principle — people seek and evaluate information under cognitive limits.
2. Design consequence — emphasize durable, verifiable evidence.
3. Representation — express it through page structure, the knowledge graph, schema, internal links, navigation, and visual hierarchy.
4. Prediction — if information is organized in ways that better match how people seek, understand, and evaluate it, retrieval systems should retrieve it more consistently.
5. Measurement — test that prediction with Retrieval Coverage.

Notice the direction: behavior → design → experiment. Not search engine → design.

The chain's logic is not tied to Google, to SEO, or to AI. Steps one, two and four would read the same for a library catalogue, a technical manual, or an internal knowledge base: people evaluate under cognitive limits, so emphasize durable evidence, so expect better-organized information to be found more reliably.

Two of the five steps are web-specific, and pretending otherwise would be dishonest. The representations named in step three — schema markup, internal links, page structure — are the vocabulary of one medium, and several of them are SEO artifacts by any reasonable definition. Retrieval Coverage in step five is measured on AI answer surfaces that did not exist a few years ago. The claim is not that the framework avoids SEO; it plainly does SEO. The claim is narrower: the reasoning that produces those artifacts starts from how people seek information, not from what a search engine is believed to reward, so when the reward function changes the reasoning survives and only the representations need rewriting.

By retrieval systems we mean anything that represents, retrieves, ranks, or synthesizes information in response to a need — a search engine, an AI assistant, internal search, or documentation search alike.

Behavioral Responsivity does not assume that these systems internally model human behavior the way we do. The claim is more fundamental. Information is organized to serve human information needs; retrieval systems represent, retrieve, rank, and increasingly synthesize that information in response to those needs.

So we begin below the level of any particular search-engine feature or optimization technique. We model the durable behavioral requirements involved in seeking, evaluating, and using information, and represent those requirements coherently — through content, structure, entities, relationships, and interface design. Retrieval systems may represent these relationships differently, and their mechanisms may change over time. The underlying behavioral requirements do not.

This gives a testable prediction: information organized around durable behavioral requirements, and represented coherently across content, structure, entities, and relationships, should be more robustly retrievable than information organized primarily around superficial or system-specific optimization.

Search-engine documentation, patents, observed system behavior, and research on user signals give evidence about aspects of how information is represented, retrieved, and evaluated by contemporary retrieval systems. We use that evidence to understand the current representation layer — but we do not make the representation layer the foundation. The foundation is the behavioral model; search and retrieval mechanisms are systems against which it can be tested.

---

6. Behavioral interventions

The unit we design around is not the page. It is the decision journey — the sequence of questions a buyer answers before acting.

We model the decision journey at two scales: the page, and the site.

Page scale

We do not know who is on the page.

It might be a test engineer, a design engineer, a laboratory manager, or a procurement lead. They arrive with different first questions — and at different stages of readiness. Some are cold and need the full story. Some are warm and technical, ready to verify and act.

So the page is built as a Decision Knowledge Flow (implemented technically as an intra-page ontology): the sequence in which it removes a buyer's uncertainty, presenting the concepts and evidence needed for the next step of the decision.

It offers that flow as two routes, side by side.

The right column — the fast route.

For a warm or technical buyer who already knows what they need. They do not want the story; they want to verify, clear a last doubt, and act.

The right column gives them, in order:

technical specifications   → FAQ              → request a quote / download the spec sheet
   (verify capability)        (resolve doubts)   (act)

It leads with specifications because specs are the most authoritative and hardest-to-fake evidence on the page. A competitor cannot show 80 kN, or IEC 60068-2-64, without actually having it.

That is the Evidence-First principle:

Critical decision evidence should appear as close as practical to the default viewport. It should reduce the largest decision uncertainties before a qualified buyer invests further attention.

The column is self-sufficient. A ready buyer can qualify the product and act without reading a word of narrative.

The left column — the deliberate route.

For a buyer building understanding from scratch.

It opens with the product image, then the identity and a one-line capability summary, then a reasoning path:

product image
  → identity + one-line capability summary
  → related products in the category (early internal links)
  → why it is required (standards, necessity)
  → how it works (working principle)
  → engineering philosophy
  → key features
  → applications (with comparison to alternatives)

This is the longer arm of the same flow — the order in which uncertainty is removed for someone who wants the reasoning, not only the numbers.

Two routes, one decision.

The diagram shows the reasoning spine of each route. The early wayfinding links to sibling products — third in the left-hand sequence above — are omitted from it for legibility.

The routes run in parallel. Neither waits for the other. A warm buyer acts from the right; a cold buyer reads down the left; many move between them.

Here is the page the diagram describes, in full.

Read down the right column and the fast route is visible as built: the specification tables come first, then amplifier and cooling parameters, then the supported-standards line, then the FAQ, and only then the two actions. Read down the left and the deliberate route unfolds in the order the diagram gives. The two columns are the same Decision Knowledge Flow, offered twice.

The two-column arrangement is a desktop pattern; on a phone the columns stack into one. For this audience that fits: over the last three months, desktop drove 165 of 221 search clicks — about 75% — so the visitors are desktop-first. (Desktop also clicked through at 3.9% versus 1.6% on mobile. We note it, but do not read it as proof the layout works — search click-through happens before the page loads, and we have no industry baseline for the comparison.)

A page is also a small graph.

The concepts are not isolated. Their relationships are the ones an engineer actually uses — shown here for one product, the air-cooled electro-dynamic shaker; every product has its own:

So the page's knowledge graph is organized around decision relevance — the relationships a buyer relies on while deciding, not the ones a schema template suggests.

Two complementary views describe one page. The knowledge graph defines what is connected. The Decision Knowledge Flow defines when each connection becomes relevant.

One page, many readers. Different people enter with different first questions. Between the two columns, the page answers each.

The action buttons sit at the foot of the right column — after the specifications and the FAQ. Even on the fast route, the ask comes only once the buyer can verify capability and clear a last doubt.

For equipment that can cost as much as a house, you ask to be contacted after the product has qualified — not before.

Site scale

Across the whole site, the same logic scales up into one connected structure — an organization at the root, its categories and the products inside them, its services, and a technical-articles hub.

Organization (VeraTEST)
   ├── Categories ──▶ Products ──▶ model variants
   ├── Services
   └── Technical articles

• Knowledge-graph schema — states what each entity is and how it connects.
• Internal linking — ties the catalog into one graph; wayfinding links are placed early on each page.
• Category hierarchy & taxonomy — one clean page per query.
• Entity consistency — the same names and relationships everywhere.

Note what is not a branch here. Industries — aerospace, automotive, electronics, energy — are real relationships in this model, but they do not exist as pages. They live inside each product page's applications section, which is where a buyer meets them: nobody arrives asking to browse an industry, they arrive asking whether this equipment suits theirs. Modeling them as a site-level branch would have created a set of pages the decision does not require. The relationship is represented; the page is not.

Most SEO writing discusses only this sitewide structure. We deliberately model both scales: the relationships between pages, and the relationships inside each page.

One model, many representations

We did not "build a knowledge graph." We began by modeling the relationships that matter during a buyer's evaluation.

That model exists before any markup. We start from one question — which relationships matter to the buyer? — and only then encode the answer. This is the reverse of starting from entities and adding meaning afterward.

It also strengthens the conversion layer: the same structure that makes a page legible to a retriever makes it faster for a buyer to qualify the product and act.

The knowledge graph is only one representation of that model. Schema markup, internal linking, headings, page layout, and navigation are additional representations of the same underlying structure.

The knowledge graph is not the model. It is the representation of the model.

The model is not the markup. When these representations agree, a retrieval system receives reinforcing evidence instead of scattered signals.

That consistency is slow to build and hard to fabricate, which is consistent with the retrieval outcomes observed in this study.

(We define these concepts here only as far as the case study needs. Each will get its own dedicated article.)

---

7. Representation layer

A behavioral model is only useful if a machine can read it.

This section is the engineering: how the model was encoded as structured data, links, and a clean crawl surface. It is the "how" behind §5 and §6 — deliberately separated from the behavioral "why."

The semantic layer: two ontologies

Beneath the markup sits the model it encodes, held as two ontologies.

Site-level ontology — a user-defined taxonomy (the categories and their hierarchy) plus the cross-entity relationships between products, categories, services, and industries. This is the site graph.

Page-level ontology — an intra-page ontology that combines entity relationships with a decision-oriented knowledge flow: decision-relevant claims are connected to the attributes, specifications, standards, and other verifiable evidence that support them.

The schema, internal links, and page structure below are the machine-readable expressions of these two ontologies.

Four schema layers, linked by @id

A single identity anchors everything. Every other schema references it by @id, which lets the relationships between pages be read as one graph rather than page by page.

1. Organization — site-wide, in the header (Woody Snippets, JSON-LD). It defines a stable identity (@id: veratest.com.tr/#organization) that every other schema points back to.
2. Breadcrumb — generated automatically (RankMath). It reports each page's place in the hierarchy — Home → Category → Subcategory — as structured data.
3. CollectionPage — one snippet per category page (Woody Snippets, JSON-LD), shown only on its own page through a display condition. Seven category pages carry it.
4. ProductGroup — one snippet per product page. Each product is modeled as a ProductGroup that declares variesBy: schema.org/model and enumerates its models under hasVariant, each a ProductModel with its own @id (#ats-1, #ats-6h, through #ats-80) pointing back via isVariantOf. Every technical figure is written as an additionalProperty — a PropertyValue carrying a name and a unit-bearing value, such as Sine Force Range · 1 – 80 kN.

Layers 3 and 4 are where the graph is written down. Each CollectionPage connects up to the Organization and WebSite entities (publisher, isPartOf) and down to its child products (hasPart), and names its subject as a DefinedTerm (about). Each ProductGroup names its brand and points its seller at the same Organization by @id — the manufacturer and the seller are different parties here, and the markup says so. A machine can walk the whole thing: website → category → product group → model variants, with one identity behind all of it.

The product schema is deliberately restrained: no price, no availability, no invented reviews, no duplicate breadcrumb — only the entity, its models, and its real specifications. That keeps the markup an honest representation of the page rather than a decoration, which is the same principle the page content follows.

Restraint has a cost, and it is worth naming rather than hiding. Capital equipment of this class is not sold at a list price, so the Offer node carries a URL and nothing else. Rich-result guidance for product markup expects an offer to carry a price and an availability state; this one cannot, honestly. We would rather emit an offer that is true and ineligible than one that is eligible and invented. The same trade-off explains a second gap: the page's FAQ is written for the reader and carries no FAQPage markup, so one block of visible content has no machine-readable counterpart. Both are places where the representations do not fully agree — the condition this section argues for.

The seven category pages carrying CollectionPage schema:

• Titreşim ve Şok Test Sistemleri
• Elektro-Dinamik Sarsıcılar
• Hidrolik Sarsıcılar
• Şok ve Darbe Test Sistemleri
• Çevresel Test Kabinleri
• Sensörler
• İvmeölçer

Internal linking — two layers

The link graph has two layers that do different jobs.

A navigational mesh — a comprehensive menu and footer expose every product and category from every page. In the crawl, almost every page sits one click from the homepage (crawl depth 1), and every product and category page is reachable from every other — roughly fifty unique internal links into and out of each page. This flat, fully-connected mesh is deliberate, but it is navigation: it makes everything reachable, not everything related.

A contextual layer — on top of the mesh, each product page adds about a dozen in-body links that encode real relationships, written into the text rather than the menu:

• siblings in the same category (for example, air-cooled ↔ water-cooled ↔ multi-axis ↔ high-displacement shakers),
• compatible accessories (slip table, head expander),
• systems it integrates with (combined vibration-and-climatic testing),
• the equipment it operates with (the controller),
• named alternatives for a different requirement,
• and two constant actions — request a quote, and download the spec sheet.

These are the links that matter for the model. Their anchors are the entity names themselves — "Slip Table," "head expander," "water-cooled electro-dynamic shaker" (illustrated here with the air-cooled electro-dynamic shaker; every product carries its own set) — not "click here." These relationships come from the page's Decision Knowledge Flow; the schema and the internal links express that same structure, with matching anchor text, so the three views agree.

We separate the two layers on purpose. A raw outlink count is dominated by the menu; the signal worth reading is the contextual layer, where a link exists because the relationship is real, not because a template repeats on every page.

External links concentrate in the technical-articles hub — the citation layer sits with the articles, not the product pages.

A cleaner crawl surface

The sitemap was trimmed so a crawler spends its budget on real content, not theme scaffolding.

Demo and theme post types — slider, portfolio, floating buttons, HTML blocks, and the unused WooCommerce product type — were removed from the sitemap (RankMath post-type filtering).

The sitemap index dropped from five files to three: posts, pages, and categories. The portfolio and product sitemaps were removed.

Taxonomy change and URL preservation

The category taxonomy changed twice during the work — once in April, and again at the end of May when the desired category structure was finalized — and with it the URLs.

To keep old links alive, old URLs are preserved with permanent (301) redirects to their new addresses — a regex rule to move an entire category subtree in one pass, and exact rules for individual pages. Redirects are verified in Search Console: the old URL resolves via a 301, and moves to the "page with redirect" state.

(The exact old→new rule set is maintained as a separate technical record.)

Why this matters here

These are the representations of the behavioral model from §5 and §6.

The schema states the entities and their relationships. The breadcrumb states the hierarchy. The sitemap keeps the crawl surface clean. The redirects keep the entity's history intact through the rebuild.

When they agree — same entities, same relationships, same identity — a retrieval system receives one coherent structure instead of scattered signals. That is the model expressed consistently across every representation.

---

8. Cross-LLM Visibility Assessment (supporting evidence)

Google AI Overview is the main test. This section is supporting evidence.

We also evaluated three major AI assistants, to check whether the same brand is retrieved by systems that run their own web search.

24 queries, 3 runs each — 72 runs per assistant.

Each assistant ran in the mode that discards session state — an incognito session on Perplexity, temporary chat on Gemini and ChatGPT — so no run carried history into the next. One limit remains worth stating: ChatGPT's free tier exposes no fixed model version, so those runs cannot be pinned to a single model the way the Gemini runs can. This section is reported as supporting evidence, not as a result.

Three separate systems retrieve VeraTEST, which suggests the observation is not unique to Google.

One pattern is worth naming. Our queries came in two forms: those that included the word "Türkiye" and those that did not. That single word raised presence sharply for the memory-based assistants (Gemini 83% vs 47%; ChatGPT 61% vs 47%), and barely moved the search-based one (Perplexity 89% vs 83%). VeraTEST did no local-SEO work beyond the word "Türkiye" on one page — so this seems to be a locality effect, not an intent effect.

The full protocol and per-query results are in the appendix, and will also appear in a separate report so this one stays focused on the Google result.

---

9. What this means

This study does not argue that Retrieval Coverage replaces traffic or rankings.

It argues that AI-mediated search adds a measurable layer between websites and buyers: whether the retrieval system chooses a page as evidence.

Behavioral Responsivity proposes that this layer can be measured, improved, and reported systematically.

VeraTEST is our first published measurement.

For a niche B2B brand with expensive products and few visitors, this is the visibility that counts — being the evidence in the answer, at the moment the buyer decides.

---

10. Future work

Future reports will test whether these observations generalize — across industries, languages, retrieval systems, and levels of website maturity.

Framework claims are treated as tentative until repeated replication; claims that restate established retrieval principles are labeled as such rather than presented as findings.

Planned reports follow a compatible protocol, so results stay comparable over time while the method is refined:

• Field Report 001 — Industrial Testing (this report)
• Field Report 002 — next industry
• Field Report 003 — …

Next steps on this site

Two of the six misses point to concrete tests. In the next iteration we will:

• retitle Güç Amplifikatörü and strengthen its entity signals, to separate it from audio power amplifiers;
• extend MEMS İvmeölçer with the MEMS-related entities and attributes a reader needs, supported by a dedicated article.

Both are direct tests of Observation 1: if adding descriptive text and disambiguating the entity moves these terms into coverage, the two failure modes were the binding constraint here rather than an artifact of this domain.

Principles status

We separate what kind of claim each statement is.

Behavioral principles

Three categories, and the distinction between them is the point. A design choice is something we decided; the study did not test it. An applied item is something we built; that is a fact about the site, not evidence about the world. Only an observation is a claim the measurement supports.

Design choices — decided, not tested

Nothing in this report tests these. We built the pages this way and then measured retrieval; a different section order was never run against the same queries, so the report cannot say whether the ordering did any work. Treating them as findings would be the mistake this table exists to prevent.

Applied — built and verifiable, not evidence

Observations — what the measurement actually supports

The first row previously appeared three times across these tables, split into a representation principle and two retrieval hypotheses, each marked "Observed — 1 report." It is one statement, it is textbook information retrieval, and counting it three times inflated a thin evidence base. The third row is a definition of the metric, which cannot be confirmed or refuted by using it.

What is missing from this table is the claim the report most wants to make — that organizing information around the decision improves retrieval. The study cannot support it. Everything shipped together, there is no before-measurement on the same queries, and the domain aged while AI Overview expanded. Future reports need a design that can isolate it; this one names it as untested rather than implying otherwise.

Over time, this builds a comparable evidence base rather than a set of unrelated success stories.

---

Appendix — Cross-LLM protocol

Assistants: ChatGPT — free tier, temporary chat, no fixed model version exposed. Gemini 3.1 Pro — temporary chat. Perplexity — free tier, incognito session. Web search: on. Session state: discarded on every assistant — incognito on Perplexity, temporary chat on the other two. Location: METU, Ankara, ethernet. Runs: 3 per query. Outcome recorded: VeraTEST named (Y/N).

Limits: three runs is a small sample; chatbot answers vary run to run; all runs came from one location and one time window. ChatGPT's free tier does not expose a fixed model version, so its runs are not pinned to one model, which makes the ChatGPT rate the softest of the three. We report these as indicative rates, not fixed numbers.

Queries (12, asked in English and Turkish = 24):

Commercial (asks for suppliers, includes "Türkiye"):

• Which companies should I consider for Modal Çekiç in Türkiye? / Türkiye'de modal çekiç için hangi firmaları değerlendirmeliyim?
• …for slip table… / Türkiye'de slip table için…
• …for head expander… / Türkiye'de head expander için…
• …for Klimatik Kabin… / Türkiye'de klimatik kabin için…
• …for Hidrolik Şok Test Sistemi… / Türkiye'de hidrolik şok test sistemi için…
• …for Elektro Dinamik Sarsıcı… / Türkiye'de elektro dinamik sarsıcı için…

Informational (asks what a product is + who provides it, no country word):

• What is a Modal Çekiç, and which manufacturers or suppliers provide it? / Modal çekiç nedir ve hangi üreticiler veya tedarikçiler sağlar?
• What is a Klimatik Kabin…? / Klimatik kabin nedir…?
• What is a Head Expander…? / Head expander nedir…?
• What is a Slip Table…? / Slip table nedir…?
• What is a Hidrolik Şok Test Sistemi…? / Hidrolik şok test sistemi nedir…?
• What is an Elektro Dinamik Sarsıcı…? / Elektro dinamik sarsıcı nedir…?