A complete guide to semantic SEO architecture.

What is semantic SEO architecture?

Google publicly recommends helpful, reliable, people-first content, crawlable links and clear structured data. The terms “topical authority”, “micro-intent” and “cost of retrieval” are used in this guide as working models for design and QA. We do not present them as named Google metrics or as a ranking formula.

In working form, topical authority can be expressed as a ratio: ((historical data × topical coverage) ÷ cost of retrieval) × the right visual annotations, where visual semantics is a multiplier rather than an afterthought. It is not a unit of measurement but a way of seeing why coverage alone does not help when a site is expensive to process, and why page layout is not a subject separate from architecture. As a multiplier, a wrong annotation cancels everything else: neither the lowest processing cost nor the broadest coverage helps if the page’s main content is not what the query asks for. The threshold for opening a new page is covered on the query template page.

How is a topical map built?

1. Define the macro topic. Broad enough to support the business goal, precise enough that you know what does not belong on the site.
2. Group related needs. A cluster is not a folder for tidiness; it gathers questions that share entities, attributes and a user journey.
3. Give each URL one dominant intent. Secondary questions are allowed only where they serve the main task.
4. Set the boundary. Write down which question belongs to another URL and which anchor text leads there.
5. Check the evidence. A page without a source, local data, a test or direct experience is usually a templated paraphrase.

How is an entity–attribute matrix built?

If a source does not exist, the attribute is not filled in by assumption. It can be labelled as an estimate, or left out of the content entirely.

Micro-intents and cannibalisation

• Different entity: “taxi Belgrade” and “taxi Niš” may share a format, but hold local data about different entities.
• Different stage of the task: a fare page answers the price question, a calculator performs the calculation, a service page enables contact.
• Same task, two pages: if two guides both answer “how much does a taxi cost in Serbia”, they need to be merged or their scope clearly separated.

We found exactly this on our own project. Two URLs targeted the same price query; the weaker one sat at position 9.35 while the stronger held 5.35. The finding and its resolution are documented in the audit example.

How are internal links designed?

Google recommends that important pages are linked from other relevant pages and that anchor text is descriptive, with meaningful surrounding context. That is why “protocol for testing visual search” is a better anchor than “click here”.

Quality nodes on the home page

The home page is not merely a junction. The links on it are a statement of which pages the site itself considers its best, and a crawler uses them as an early judgement on whether to go deeper. Martin Splitt of Google describes how a crawler that reaches unique documents with real human effort behind them from the home page becomes more inclined to crawl further.

The most important pair is targeted from the most important page

On local projects, the most important service-and-location pair should be targeted by the strongest page, usually the home page, because it carries the most internal links and is crawled most often. The common failure is the opposite: the home page, the about page and the main service page compete with one another, because they share the same signals — internal links, query relevance, click data and the URL listed in the business profile.

A verifiable test: write the sentence “this page exists so the reader can…” for the home page and for the main service page. If they end the same way, one of them has to change its intent.

How does content reduce the effort of finding an answer?

• The H1 names the topic and the dominant intent.
• The opening paragraph gives a self-contained answer without marketing preamble.
• H2 and H3 follow the user’s journey, not a list of synonyms.
• Tables are for comparison; lists are for sets; numbered steps are for processes.
• Facts carry a source and a date wherever they can change.
• Estimates carry their formula, assumptions and limits.
• Recommendations explain why they help and when they do not apply.

Clear sentences are good because of readers. There is no need to force every sentence into subject–predicate–object, nor to claim that such syntax is a special form of BERT optimisation.

What does a cohesive JSON-LD graph look like?

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example" },
    { "@type": "WebSite",
      "@id": "https://example.com/#website",
      "publisher": { "@id": "https://example.com/#org" } },
    { "@type": "WebPage",
      "@id": "https://example.com/guide/#webpage",
      "isPartOf": { "@id": "https://example.com/#website" } },
    { "@type": "Article",
      "@id": "https://example.com/guide/#article",
      "mainEntityOfPage": { "@id": "https://example.com/guide/#webpage" } }
  ]
}

This is a structural example, not a complete Article to copy. The properties you need depend on the visible content and on the guidelines for the specific rich-result type. For implementation see the schema markup guide.

How is the system checked before publishing?

After publishing, measure indexing, impressions, clicks and conversions separately. A change in position without conversions may not solve the business goal; more conversions without more traffic can be the better result.

Frequently asked questions