Navigation and Discovery Repair

Direct answer

This site uses one public truth surface. The visible page, page title, description, canonical URL, internal links, structured data, search index, sitemap, llms.txt, and AI manifest should all describe the same content.

That means the site should be easy to use by people first, then easy for search engines, answer engines, and generative systems to quote accurately.

What changed in this repair

• The header was split into a brand row and a navigation row so links do not wrap awkwardly on normal desktop screens.
• Search and Contact moved into utility actions instead of competing with primary navigation.
• Technical shortcuts were grouped as secondary research links.
• The footer was rebuilt as a practical site map with Start, Technical Research, Evidence & Integrity, Contact, and Machine-readable groups.
• The page head now includes stronger visible-content metadata: canonical URL, robots directive, author, Open Graph site name, modified time, and Twitter title/description.
• JSON-LD now includes Organization, WebSite, WebPage, BreadcrumbList, Article, and visible navigation entities when applicable.
• Glossary tooltips no longer create strange domain fragments when a term appears inside a domain name such as Cognivirus.com.

Why this matters

A site about distributed AI behavior should not make the reader assemble the site itself. Navigation is part of the safety explanation. If a visitor cannot quickly find the plain-language guide, examples, evidence, glossary, and contact route, the research loses practical value.

For answer engines and generative systems, the same principle applies. The site should expose short, stable answers and then route readers to evidence, limitations, and review context.

Header doctrine

The header now has three roles:

1. Identity. Brand, version, and purpose are visible at the top.
2. Primary path. The main navigation uses short labels: Start, Problem, Plain English, Examples, Consent, Research, Evidence, and Glossary.
3. Utility. Search and Contact are separate actions, not fragile overflow links.

The desktop menu should stay on one visual line where practical. On smaller screens, the same links collapse into a keyboard-accessible menu.

Footer doctrine

The footer is treated as a second navigation system, not an afterthought. It provides:

• public-reader routes;
• technical-research routes;
• evidence and integrity routes;
• contact and owner accountability;
• machine-readable discovery files.

The footer also repeats the current version and build time because archived copies and generated summaries need version context.

Metadata doctrine

Every page should have:

• a unique title;
• a concise description;
• one canonical URL;
• visible evidence and update context;
• structured data that matches visible page content;
• internal links to definitions, evidence, or contact where relevant.

Structured data must not describe hidden claims. The page body remains the authority.

Answer-first doctrine

AEO and GEO readiness on this site means:

• answer the main question near the top of the page;
• define unusual terms before relying on them;
• expose limitations and evidence level;
• link to source and integrity pages;
• avoid ranking promises, certification claims, or hidden model-facing instructions.

No hidden bot-only layer

Cognivirus.com does not use cloaked text, prompt-injection blocks, hidden ranking copy, fake citations, or bot-only claims. Machine-readable files exist to point back to public pages, not to create a separate version of the site.

Review checklist

• Does the visible page answer the likely reader question?
• Does the page title match the visible heading?
• Does the description match the page body?
• Does the canonical URL resolve to the same page?
• Does JSON-LD describe only visible content?
• Does the footer provide a route to evidence and contact?
• Do discovery files point to Cognivirus.com rather than external guidance sites?
• Does the page avoid unsupported ranking or readiness guarantees?

Remaining live checks

Local package validation can confirm structure, links, JSON, and routes. Live deployment still requires a production crawl, Search Console or equivalent inspection, accessibility review with assistive technology, and real analytics after deployment.