44up Observatory · Storefront Audit

Fabular Storefront — Audit Round 2

Das Fresh-Haven-Referenz-Storefront, nach den Anpassungen erneut geprüft. Zwei Barrierefreiheits-Lücken sind geschlossen — doch eine Stufe tiefer liegt die Findability hohl, und zwei Pflicht-Rechtsseiten fehlen.

fabular.pages.dev · Re-Probe 2026-06-06 · 4 Achsen · 0 fabrizierte Werte · 44°N
Barrierefreiheit
✓ fixed
Skip-Link + valide Erklärung
Kern-Recht
404
Impressum · Datenschutz fehlen
Findability
poisoned
Sitemap → toter Host
Produktdaten
head only
Katalog-Body 0%
eComm-Schema
no img
Offer top · kein Bild/GTIN
CWV mobil
89
LCP 3118ms ✗ · CLS 0.0 ✓

Zwei Demo-Artefakte (Platzhalter-Host, Emoji statt Foto) und drei Template-Lücken, die ein echter Tenant 1:1 erbt.

Headline · Find-ability

Die Sitemap ist da — aber zeigt auf einen toten Host

Runde 1 vergab KI-Sichtbarkeit 100/100, u. a. weil „sitemap.xml vorhanden & valide". Sie ist valides XML — aber funktional für die Auffindbarkeit gebrochen.

2.246 Einträge, alle auf fresh-haven.example.com

sitemap <loc> Host-Verteilung:  2246 × https://fresh-haven.example.com
canonical / og:url / robots Host / robots Sitemap:  alle → https://fabular.pages.dev
curl https://fresh-haven.example.com/  →  HTTP 000  (DNS löst nicht auf)

Der Sitemap-Host widerspricht dem kanonischen Host — und löst nicht auf. Google Search Console weist Cross-Host-URLs unter fabular.pages.dev ab; jeder Crawler / jede LLM, die der Sitemap folgt, landet auf 2.246 toten Links. Die interne Navigation zeigt nur ~24 Produkte pro Kategorieseite — der einzige vollständige Auffindungspfad für den 2.088-Produkte-Long-Tail ist gebrochen. Die „perfekte" KI-Wertung ist teilweise hohl.

Scorer-Blindstelle: ai_readiness.py:179 prüft per HEAD nur, dass eine Sitemap antwortet — nie, ob die <loc>-Hosts dem kanonischen Host entsprechen. Härtung als Follow-up erfasst (tasks/0003).

Compliance

BFSG geschlossen — die zwei Basis-Rechtsseiten fehlen

✓ Behoben seit Runde 1

  • Skip-Link vorhanden: „Zum Hauptinhalt springen" → <main id="main-content" tabindex="-1">
  • /barrierefreiheit existiert & ist valide: Konformitätsstatus, nicht-barrierefreie Inhalte, Feedback-mailto, EN 301 549, AT-Schlichtungsstelle (Sozialministeriumservice)
  • Widerruf in die AGB eingearbeitet (auch als MerchantReturnPolicy, 14 Tage, im Produkt-Schema gespiegelt)

Offen — und fundamentaler als die a11y-Lücke

  • Kein Impressum. /impressum, /offenlegung, /imprint … alle 404. Pflicht-Offenlegung (ECG §5 AT / DDG §5 DE). AGB trägt nur Name + „Wien 1010" — kein Firmenbuch / UID / ATU / Geschäftsführer.
  • Keine Datenschutzerklärung. /datenschutz, /privacy … alle 404. Pflicht (DSGVO Art. 13). Kein Cookie/Consent-Layer.
  • Tote Verweise: AGB nennt „Impressum" und „Datenschutzerklärung", die BFSG-Seite nennt „Impressum / Datenschutz / Art. 13" — aber keine der Seiten existiert oder ist verlinkt. Der Footer verlinkt nur AGB + Barrierefreiheit. Das Template weiß, dass es sie braucht, und zeigt auf sie — ausgeliefert wurden sie nie.
Data-Quality

Der Fix war das Schaufenster, nicht der Katalog

Runde 1: Nährwerte 1,5% / Kurzbeschreibungen 2% katalogweit. Re-Messung:

/api/products  (total: 2088, paginiert, limit 24)
  offset    0 (Schaufenster):  shortDescription 100%  ·  nutrition 75%
  offset  500:                 shortDescription   0%  ·  nutrition  0%
  offset 1500:                 shortDescription   0%  ·  nutrition  0%

Beschreibungen & Nährwerte wurden nur bei den ~24 Schaufenster-Produkten gefüllt; der 2.088-Produkte-Body bleibt bei beiden leer. Kernfelder (Preis, MwSt, Einheit, Kategorie, Bewertung) zu 100% belegt. Ein Content-Patch auf der sichtbaren Front, kein Katalog-Fill — der strukturelle Befund aus Runde 1 bleibt bestehen.

eCommerce-Schema & -Metriken

Vorbildliches Offer — aber keine Bilder, keine GTIN

Produkt-JSON-LD ist stark: Offer mit priceValidUntil, availability:InStock, itemCondition, vollständigen shippingDetails (Rate + Lieferzeit), hasMerchantReturnPolicy (14 T), dazu aggregateRating, brand, sku; seitenweit LocalBusiness/GroceryStore mit Zahlung, Geo, areaServed, Öffnungszeiten. Über dem Sektorschnitt.

  • image fehlt im Produkt-Schema — weil es gar keine Produktbilder gibt (Detailseiten rendern Emoji + Farb-tint, null <img>). Google Produkt-Rich-Results brauchen faktisch ein Bild — ohne feuert kein Rich-Snippet.
  • gtin/mpn fehlen — kein globaler Identifier; limitiert Google-Merchant-Matching (für ein Demo gering).
  • robots.txt ergänzt jetzt Disallow: /api/ — sinnvoll; KI-Bot-Gruppen bleiben allow-all, Detailseiten tragen das Schema → keine Regression.
Core Web Vitals

Mobile LCP weiterhin durchgefallen

Live-PageSpeed-Lauf (cwv.py --store-id _ref-fabular --force, 2026-06-06).

MobilDesktop
Perf-Score89 ✗99 ✓
LCP3118 ms726 ms
FCP2707 ms726 ms
TTFB5 ms6 ms
CLS0.0 ✓0.009

TTFB ist mit 5 ms top, aber FCP ≈ LCP auf Mobil — die Zeit geht komplett ins Client-Rendering (render-blockierendes CSS/JS), nicht in den Server. CLS auf 0.0 verbessert. LCP unverändert über der 2500-ms-Schwelle (Einzel-PSI-Lauf, LCP mit Labor-Varianz → als „weiterhin ~2,8–3,1 s, ungelöst" lesen). Fix: kritisches CSS/JS deferren/inlinen, Hero-LCP-Element + Headline-Font preloaden (font-display:swap).

Strategischer Kontext

Das Demo beweist weiter die Decke (KI-Extraktion, Offer-Schema, BFSG jetzt sauber) — aber der Re-Probe zeigt: der Deploy erreicht sie nicht, und der schlimmste Befund (die example.com-Sitemap) ist ein Pipeline-Artefakt, das ein echter Tenant 1:1 erbt.

„Das eigene Referenz-Storefront zeigt 2.246 Sitemap-URLs auf eine Domain, die es nicht gibt — eine LLM oder Google, die ihr folgt, findet nichts, obwohl jede Produktseite perfekt ist."

Rechtsseiten + Sitemap-Host-Substitution sind Template-Fixes, die jeden künftigen Tenant auf einmal heben.