---
name: av-tech-discoverability
description: Bewertet die Readiness-Dimension „Technical Discoverability" — können Suchsysteme die wichtigen Seiten zuverlässig crawlen, rendern, indexieren und interpretieren? Nutzen, wenn im Readiness-Audit (v3, 8 Dimensionen) die technische Auffindbarkeit einer Website bepunktet werden soll. Strukturdaten-*Vollständigkeit/Konsumierbarkeit* liegt jetzt in [[av-knowledge-catalog]], hier bleibt die *Validität*.
---

> **EVN:** Dieser Skill misst die Eigenschaft (Stellhebel) **„Technical Discoverability"** → trägt zum Vorteil **Sichtbarkeit** bei → Nutzen **Auffindbarkeit**.

# av-tech-discoverability — Dimension „Technical Discoverability"

Bewertet die dritte Dimension des Search-&-AI-Readiness-Audits. Leitfrage: *Können Suchsysteme die wichtigen Seiten zuverlässig erreichen, rendern, indexieren und interpretieren?*

Score 0–100 als gewichtete Summe aus 5 Sub-Signalen, jedes gegen die 0/25/50/75/100-Rubrik.

**v3-Hinweis:** Sub-Signal 5 misst die **Validität** strukturierter Daten + Abgleich mit sichtbarem Inhalt (für Crawl/Index/Interpretation). Die **Vollständigkeit/Konsumierbarkeit als verifizierter Datensatz** (JSON-LD-Vielfalt, Feed/API, Transactability) wird in der neuen 8. Achse **`av-knowledge-catalog`** bewertet — hier nicht doppelt werten. Entsprechend sank das AVI-Cross-Gewicht der Dimension 0.10 → 0.05 (method_config v3; der maschinenlesbar-Fokus liegt nun bei der Catalog-Achse).

## Wann nutzen

- Wenn ein Readiness-Audit (v3, 8 Dimensionen) läuft und die technische Auffindbarkeit bepunktet werden muss.
- Wenn Crawl-/Index-/Render-Blocker oder strukturierte-Daten-Gültigkeit auf Schlüssel-Templates geprüft werden sollen.

## Methode — Sub-Signale und Gewichte (aus 03_MEASUREMENT, Dim. C)

1. **Crawl-/Indexierungs-Zugang auf Schlüssel-Templates** — 30 %
2. **Canonical-, robots-, noindex-, sitemap- und interne-Link-Konsistenz** — 25 %
3. **Rendering-/Mobile-Zugänglichkeit und JavaScript-Abhängigkeits-Risiken** (inkl. **Canvas-Text-Exposure**) — 15 %
4. **Page-Experience-Diagnostik (Core Web Vitals) auf Priority-Templates** — 15 %
5. **Gültigkeit anwendbarer strukturierter Daten + Abgleich mit sichtbarem Inhalt** — 15 %

`Tech Discoverability Score = Σ (Sub-Score × Gewicht)`

Score-Anker: 0 = blockiert/kaputt · 25 = schwach, hohes Risiko · 50 = teils, materielle Lücken · 75 = stark, kleine Lücken · 100 = reif für Markt + Modell. **Nie 100 nur weil etwas existiert.**

## Inputs

- robots.txt, Meta-robots, Canonical-Tags, XML-Sitemap.
- Crawl-/URL-Inspection-Ergebnisse (wo Zugriff besteht), Render-Tests, interne Link-Struktur.
- PageSpeed/Lighthouse oder Search-Console-CWV; Rich-Results-Test wo relevant.
- Erkannte Fakten: `noindex`-Vorkommen, Canonical-Ziel, Sitemap-erreichbar, JS-only-Content-Risiko, JSON-LD vorhanden + valide.
- **Canvas-Text-Exposure:** Liegt Schlüssel-Inhalt (Text, Navigation, CTA, Produktdaten) in einem `<canvas>`? Prüfen, ob das Canvas `layoutsubtree` trägt und echtes DOM enthält (→ HTML-in-Canvas, render-/indexierbar) **oder** rein per `fillText`/Bitmap gemalt ist (→ pixel-only, für Crawler/Renderer blind).

## Sub-Check — Canvas-Text-Exposure (innerhalb Sub-Signal 3)

Pixel-only Canvas mit materiellem Inhalt ist ein **Render-/Index-Blocker** wie JS-only-Content: Suchsysteme sehen nur eine Bitmap, kein Text. Die HTML-in-Canvas-API (`<canvas layoutsubtree>` + `drawElementImage`/`texElementImage2D`, Chrome Origin Trial 2026) hält denselben Inhalt im DOM/Accessibility-Tree → render- und indexierbar.

- **Erkennung:** `<canvas>`-Elemente auf Priority-Templates zählen; je Canvas prüfen: `layoutsubtree`-Attribut vorhanden? Kind-Elemente mit Text/Interaktion im DOM? Ist Schlüssel-Inhalt (nicht nur Deko/Chart-Pixel) betroffen?
- **Scoring-Wirkung** auf das `rendering`-Sub-Signal:
  - Kein materieller Inhalt im Canvas, oder Canvas nur dekorativ → neutral.
  - Pixel-only Canvas trägt Schlüssel-Inhalt (Text/Nav/CTA) → Sub-Score senken (Render-Blocker), Reason nennt das betroffene Template.
  - `layoutsubtree` + echtes DOM im Canvas → positiv, kein Abzug.
- **Guardrail:** kein KI-Sichtbarkeits-*Versprechen* — gemessen wird nur, ob der Canvas-Inhalt technisch render-/crawl-bar ist. Browser-Support ist heute Chrome-only (Origin Trial); Pixel-only bleibt unabhängig davon der riskante Default. Live-Demo: `audit.phibel.app/canvas-demo`.

## Output-Format (JSON)

```json
{
  "axis_key": "technical_discoverability",
  "score": 0,
  "sub_signals": {
    "crawl_index":   {"score": 0, "weight": 30, "reason": "", "evidence_label": "VERIFIED"},
    "directives":    {"score": 0, "weight": 25, "reason": "", "evidence_label": "VERIFIED"},
    "rendering":     {"score": 0, "weight": 15, "reason": "", "evidence_label": "VERIFIED"},
    "page_experience":{"score": 0, "weight": 15, "reason": "", "evidence_label": "MEASURED"},
    "structured_data":{"score": 0, "weight": 15, "reason": "", "evidence_label": "VERIFIED"}
  },
  "confidence": "B",
  "measured_at": "YYYY-MM-DD"
}
```

## Guardrails

- **Strukturierte Daten = Sub-Signal, KEIN KI-Sichtbarkeits-Versprechen.** Schema kann Rich-Result-Eligibility unterstützen, garantiert aber weder Rich-Result-Anzeige noch generative-KI-Einbindung. „Mehr Schema" ist KEIN automatischer Gewinn (sd-policies).
- Strukturierte Daten müssen zum sichtbaren Inhalt passen — Mismatch senkt den Score.
- robots.txt steuert Crawler-Zugang, ist KEIN Mechanismus zum Ausschluss aus dem Index — robots-Erlaubnisse nicht als Ranking-Signal framen.
- Gute Core Web Vitals garantieren keine Rankings.
- Fehlt Crawl-/CWV-Zugriff: `MISSING_DATA` statt 0; Confidence auf C; Ergebnis als „directional" labeln.
- Evidenz-Label je Sub-Signal, Mess-Datum immer ausweisen.

## Verwandte Skills

- **av-knowledge-catalog** — bewertet die Strukturdaten-*Vollständigkeit/Konsumierbarkeit* als Datensatz (Abgrenzung: hier nur *Validität* für Crawl/Index).
- **av-intake** — liefert Domain / Priority-URLs als Crawl-Scope.
- **av-guardrails** — erzwingt Evidenz-Labels und Truth-Rules.
- **av-gap-strategist** — nutzt den Dimensions-Score für die Gap-Strategie.