Page-generated data: eight risks

What validation tools don’t see

On hundreds of pages, a validation tool warned that the author of a post must be a person or organization. In every case, it was – as a correct reference to the company. Anyone who had ‘fixed’ the warning would have degraded the data.

Validation tools for structured data primarily focus on whether the mandatory fields for display in search results are present. They do not check whether the statements are correct and consistent. In our audits, we therefore regularly encounter data that passes every format check and yet publishes unclarified information as fact.

That’s why the question is worth asking: What risks arise when each page generates its own data? The eight points come from the comparison we developed in an audit and have been using ever since. The examples are generalized or recreated.

1. Identity drift

An offering fragments into identifiers that do not explain what belongs together: on different page types, it carries its own identifiers each time. Whether it is the same offering, a variant, or a separate service must be reconstructed by the AI. With a domain-based approach, identities and relationships are assigned centrally.

2. Unresolved numbers become structured facts

One page says “over 40” in the text, “25” in the FAQ—and the structured data lists 25 as a fixed statement. The format check reports no error because the format is correct. With a domain-based approach, the decision comes first, publication second.

3. An unresolved dataset reaches the entire domain

A central dataset is the correct mechanism – as long as its content is accurate. If it contains an outdated description or an incorrect contact address, it distributes it to every page. Domain-based, the dataset behind a central identifier is first reviewed and approved.

4. Parallel descriptions

Visitors read “Delivery in 48 hours for in-stock items,” while the FAQ answers in the structured data say “Delivery in 48 hours.” If a buyer needs a custom build, the choice hinges precisely on that constraint. With a domain-based approach, humans and machines read the same approved statement.

5. Old and current numbers get mixed

An older announcement cites one customer count, a newer one another, a third yet another—without an explained counting method. An AI may then reproduce the oldest number as if it were current. With a domain-based approach, history and current value remain distinguishable.

6. Broken history

The text says that a product was renamed. But the product data does not list the former name as a former name. The link between old and new must be reconstructed from text and old pages. With a domain-based approach, former names and predecessors remain assigned to the correct entries.

7. Others write your story

Where your domain is silent on ownership, origin, and relationships, external sources fill the gap: directories, third-party reports, and, by comparison, other providers. With a domain-based approach, your domain states its core facts itself.

8. Publication drift

A template error repeats across many pages – for example, one where multiple reference pages carry the same identifier. Domain-based, identifiers originate from an inventory and are validated before publication.

A ninth risk that we also have

Domain-based data resolves the eight risks, but they have their own. At one company, the locations in the footer were changed, but the structured data was not. Suddenly, text and data diverged again – this time not because each page generated its own data, but because the shared inventory was not updated. Norbert Kathriner stated it bluntly: “That is a disadvantage of Aivis-OS.”

This has become a requirement for our own software: The guardian that reports discrepancies must check against the live page, not just the inventory. What domain-based data achieves when facts are clarified and maintained is described in the article “Domain-based structured data: eight advantages”.