Grün im Build,
rot im Browser.
Re-Check von fabular.pages.dev über die Laufzeit-Kanten, die ein next build nicht sieht: ein Crawl der eigenen Sitemap und ein echter Browser-Lauf gegen die Live-Routen. Schließt an den 2026-06-07-Schnittstellenreview an (dort 153 tote Sitemap-URLs) und weitet ihn auf Karte, API und MCP-Kontrakt.
- Prüfer
- 44up Observatory
- Gegenstand
fabular.pages.dev— Fresh Haven, fab4minds „fabular." Demo-Storefront- Geprüft
sitemap.xml·/produzenten·/api/products|recipes|producers·/api/mcp· Build-Output- Datum
- 2026-06-09 · Erweiterung des
2026-06-07-Schnittstellenreviews - Methode
- Sitemap-Crawl + echter Browser-Lauf (Konsole / CSP) + read-only API-Probes. Keine DB-Writes. Beobachtet vs. abgeleitet markiert.
- Befunde
- 2 kritisch · 2 funktional · 1 strukturell
Zusammenfassung
Jeder next build ist grün — aber an der ausgelieferten Kante zeigen sich fünf Lücken: 158 Sitemap-Produkt-URLs 404en (Umlaut-Slugs), die Produzentenkarte wird von der eigenen CSP blockiert und bleibt leer, die öffentlichen API-Edges antworten mit 200 statt 4xx, und der MCP-Kontrakt schickt Agenten auf ein totes /checkout. Dieselbe Klasse wie 2026-06-07: korrekt im Code-Pfad, falsch an der Schnittstelle.
Das Richtige im System
Keiner dieser Befunde taucht im next build auf — alle fünf zeigen sich erst im Crawl der eigenen Sitemap und im echten Browser-Lauf. Es sind kleine, exakt benennbare Fixes: Slug-Encoding, ein same-origin-Asset, ein Parameter-Clamp, ein Redirect. Die Defekte sind die ausgelieferte Kante — nicht die Architektur.
Befunde — pro Schnittstelle
A · Sitemap & SEO
sitemap.xml158 sitemap-Produkt-URLs (~7%) liefern 404. /sitemap.xml listet 2.329 URLs; ~158 tragen rohe Umlaute/Sonderzeichen (z. B. /produkt/leberkäse-300g) und 404en durchgängig, dazu zwei fehlende Rechtsrouten (Widerrufsbelehrung, Datenschutz). Die Sitemap gibt rohe Slugs aus, die Produktseite macht einen Exact-Match-Lookup — jeder Umlaut-Slug fällt durch. Setzt den 2026-06-07-Befund fort (dort 153).beobachtet (Sitemap-Crawl) · Ursache (Slug-Normalisierung) abgeleitet
B · Browser-Runtime
/produzenten · CSPDie Produzentenkarte rendert im Browser nicht. /produzenten lädt das Welt-Atlas-Topojson von cdn.jsdelivr.net, aber die eigene CSP erlaubt nur self + die API — der Browser blockt den Fetch, die Karte bleibt leer. Im Build unsichtbar (SSR wirft den Fehler nicht), in jeder echten Browser-Sitzung sichtbar (Konsole zeigt den CSP-Block).beobachtet (Browser-Konsole)
C · Schnittstellen — API & MCP-Kontrakt
/api/* · /api/mcpÖffentliche API-Edges antworten mit irreführenden 200. /api/products, /api/recipes, /api/producers nehmen limit/offset ungeprüft: limit=-1, limit=abc, offset=-10, limit=100000 liefern alle 200 — mit leeren, falschen oder übergroßen Ergebnissen statt eines klaren 4xx.beobachtet (read-only API-Probes)
Der MCP-Checkout-Link zeigt auf eine tote Route. Der öffentliche MCP-Endpunkt (/api/mcp) gibt Agenten checkout_url …/checkout zurück — /checkout ist aber 404, die Live-Route heißt /kasse. Ein Agent, der dem Kontrakt folgt, schickt den Kunden in einen 404.beobachtet
D · Auslieferung
PayloadKritische Seiten dekodieren ~1,5–1,7 MB; /warenkorb ist mit ~257 KB First-Load-JS die schwerste Build-Route; /api/suggest ist der heißeste Pfad (foldet pro Request den ganzen Katalog). Lokal schnell, aber payload-schwer — auf mobilen Verbindungen spürbar.beobachtet · nicht-fatal
Grün im Build, rot an der Kante.
Die Sitemap behauptet 2.329 URLs, ~158 existieren nicht unter der gelisteten URL. Die Karte ist deklariert, die CSP lässt sie nicht laden. Die API nimmt jede Zahl und antwortet 200. Der MCP-Kontrakt nennt eine Checkout-Route, die es nicht gibt. Die Schnittstelle — was Maschinen und Browser sehen — ist sauber spezifiziert; der ausgelieferte Build hält die Zusage an der Kante nicht. Kein Architektur-, sondern ein Generierungs-/Konsistenz-Problem.
- Hoch: Sitemap mit der Router-Slug-Normalisierung regenerieren (encode aus / decode ein) — ~158 tote URLs weg.
- Hoch: Karten-Topologie same-origin hosten oder die Bibliothek durch native SVG ersetzen — CSP bleibt strikt, Karte rendert.
- Mittel: API-Parameter zentral clampen/validieren;
/checkout → /kasseals Redirect (oder MCP-URL korrigieren). - Niedrig: Payload je Kernseite trimmen; den Suggest-Index cachen.
Angekündigt,
nicht eingelöst.
Re-Check von fabular.pages.dev (dem fab4minds-„fabular."-Demo) — diesmal über drei Achsen: Social-Sharing · SEO · GEO. Geprüft in der Schnittstellenreview-Form: Spezifikation gegen Wirklichkeit, drei Schweregrade, alles gezählt. Seit dem Befund vom 2026-06-06 hat das Demo nachgebessert — die Lücke ist von fehlenden zu uneingelösten Tags gewandert.
- Prüfer
- 44up Observatory
- Gegenstand
fabular.pages.dev— Fresh Haven, fab4minds „fabular." Demo-Storefront (statischer Pages-Export)- Geprüft
Startseite·Produktseiten·sitemap.xml·robots.txt·llms.txt·/opengraph-image- Datum
- 2026-06-07 · Re-Check des
2026-06-06e-Befunds - Methode
- read-only
curl(HTTP/1.1 + HTTP/2, mehrere UAs) + Playwright Browser-fetch(). Keine DB-Writes. Beobachtet vs. abgeleitet markiert. - Befunde
- 2 kritisch · 2 funktional · 2 strukturell
Zusammenfassung
Seit dem Link-Vorschau-Audit trägt die Startseite jetzt ein og:image, Produktseiten haben eigene og:title/description, der schema.org-Graph ist der reichste im Sektor, robots.txt öffnet für alle KI-Crawler. Die Lücke ist von fehlenden zu uneingelösten Tags gewandert: das angekündigte OG-Bild liefert einen leeren Body, die sitemap listet 153 Produkt-URLs, die 404en, die Produktzahl steht dreifach (40 / 150+ / 2141), und die Twitter-Karte erbt auf Produktseiten den generischen Startseiten-Titel. Ein Storefront, der korrekt ankündigt, aber nicht einlöst, was er ankündigt.
Das Richtige im System
Das Demo ist das stärkste SEO/GEO-Gerüst der drei Storefronts: vollständig server-gerendert (keine JS-Mauer), der reichste schema.org-Graph im Sektor (Product · Offer · AggregateRating · FAQPage · MerchantReturnPolicy · OfferShippingDetails), robots.txt erlaubt explizit alle 16 KI-/Such-Bots, eine strukturierte 120-Zeilen-llms.txt. Die Defekte sind Nutzlast und Konsistenz — nicht Architektur.
Befunde — pro Achse
A · Social-Sharing — OG / Twitter
Start + Produktog:image deklariert, Body leer. Start + Produkt deklarieren /opengraph-image (1200×630 / 800×800, image/png). Der Endpoint antwortet HTTP 200, image/png, aber 0 Bytes — unter curl HTTP/1.1 + HTTP/2 + facebookexternalhit-UA und im echten Browser-fetch() (blobSize 0). WhatsApp/FB/X zeigen weiter eine bildlose Karte — trotz korrekter Tags. Der 2026-06-06e-Fix landete in den Tags, das Bild fehlt weiter.beobachtet (curl + Playwright) · Ursache (OG-Generator liefert leeren Body) abgeleitet
Produkt-Twitter-Karte trägt den Startseiten-Titel. Auf /produkt/bio-karotten-1kg sind die og:-Tags produktspezifisch, twitter:title/description aber die generischen Startseiten-Texte. Geteilte Produkt-Links auf X zeigen den falschen Titel. (Besser als 2026-06-06e — dort waren auch og: generisch.)beobachtet
Dasselbe (leere) /opengraph-image wird mit widersprüchlichen Maßen deklariert (1200×630 Start / 800×800 Produkt). Und: og:image trägt einen Cache-Buster-Query, twitter:image nicht — zwei URLs für eine Quelle.beobachtet · kosmetisch
B · SEO
sitemap · meta · schema153 sitemap-Produkt-URLs (~7%) liefern 404. sitemap.xml listet 2141 /produkt/-URLs; 153 tragen rohe Umlaute (ä/ö/ü) und 404en durchgängig. Crawler & LLMs, die der sitemap folgen, laufen auf ~7% der Produkte ins Leere — Leberkäse, Paranüsse, geräucherte Entenbrust sind für Suche/KI unsichtbar.
Drei widersprüchliche Produktzahlen. meta-description „Über 40 Produkte" · llms.txt „150+" · sitemap 2141 echte Produktseiten. Der indexierte Google-Snippet unterzählt ~50×, llms.txt ~14×. Der „über 40"→„150+"-Undercount aus dem MCP-Audit (2026-06-06d §3.3) überlebt hier in der meta-description.beobachtet
C · GEO — KI-Zugänglichkeit
robots · llms.txtrobots.txt erlaubt explizit alle 16 geprüften KI-/Such-Bots (GPTBot, ClaudeBot, anthropic-ai, PerplexityBot, Googlebot-Extended, CCBot …), nennt Host + Sitemap. llms.txt vorhanden, 120 Zeilen, strukturiert. Stärkste Achse des Storefronts.
Einziger GEO-Defekt ist Konsistenz: eine LLM, die llms.txt („150+") als Wahrheit nimmt, zitiert eine ~14× zu kleine Sortimentszahl gegenüber der realen sitemap (2141).
Deklariert ≠ eingelöst.
Das og:image-Tag existiert, das Bild nicht. Die sitemap behauptet 2141 Produkte, 153 existieren nicht unter der gelisteten URL. Drei Surfaces nennen drei Produktzahlen. Die Schnittstelle — was Maschinen lesen — ist sauber spezifiziert; der Build hält die Zusage nicht. Kein Architektur-, sondern ein Generierungs-/Konsistenz-Problem: Sitemap-Generator, OG-Image-Route und Copy laufen auseinander, weil keine gemeinsame Quelle sie bindet. Die Klasse Befund, die ein Demo am leichtesten übersieht — es zeigt gut, wird selten als geteilter Link oder sitemap-folgender Crawler getestet.
- Hoch:
/opengraph-imagereparieren (echte PNG-Bytes) — ein Fix, Bild auf jeder Karte. - Hoch: sitemap mit der Router-Slug-Normalisierung regenerieren (oder die 153 Umlaut-Produkte deployen) — ~7% tote URLs weg.
- Mittel: produktspezifische
twitter:-Texte; Produktzahl über meta / llms.txt / sitemap auf einen Wert versöhnen. - Niedrig: deklarierte
og:image-Maße ans Asset angleichen.
Wenn der Link
geteilt wird.
Drei Isarland-nahe Storefronts, eine Frage: Was erscheint, wenn man den Link in WhatsApp, Signal, Slack oder LinkedIn einfügt? Geprüft wurde Startseite und je eine Produktseite — denn geteilt wird fast immer ein Produkt, nicht die Startseite. Das Ergebnis kippt zwischen beiden.
Die Schlagzeile kippt zwischen Start- und Produktseite. Auf der Startseite zeigt keiner ein Bild. Auf der Produktseite — dem Link, den Kund:innen wirklich teilen — liefern die beiden echten Builds ein echtes Produktfoto, das Demo nie. Jeder der drei scheitert am WhatsApp-Test auf eine andere Weise. Keiner liefert auf Start und Produkt eine korrekte, bildhafte Karte.
Die Matrix — Start (S) · Produkt (P)
✓ funktioniert · ⚠/rot degradiert oder fehlt · — n/a. WhatsApp/Facebook/LinkedIn/Signal lesen
og:image, nichttwitter:image.Pro Storefront
fabular.pages.dev — das Demo: beste Tags, kein Bild
Fresh Haven · Referenz-DemoDie vollständigste Tag-Schicht der drei (OG + Twitter + canonical + theme-color), komplett statisch — jeder Crawler, jede UA bekommt sie.
Aber
og:imagefehlt — auf Startseite und Produkt (grep -c og:image= 0). Einziges Bild:twitter:image = /icons/icon-512.png, ein 512×512 quadratisches App-Logo, das WhatsApp/FB ignorieren. Auf der Produktseite sindtwitter:title/descriptionsogar die generischen Startseiten-Texte, nicht die des Produkts.→og:imageergänzen (Startseite: eine 1200×630 Share-Karte; Produkt: das Produktfoto) + Produktseiten eigene twitter-Texte geben. Günstigster, wirksamster Fix der drei.isarland.de — live: echte Fotos, drei Lücken
Angular SPA · prerendered MetaProduktseiten tragen ein echtes
og:image(1200×1097 JPEG, 116 KB, unter WhatsApps Größenlimit) — und die Meta ist prerendered, ein echter Kontrast zur dokumentierten fab4minds-JS-Mauer.Der größte Befund: geteilte Produkt-Links zeigen das falsche Produkt. Die prerenderte Meta ist fehlgekeyt:
Im echten Browser (mit JS) rendern beide Produkte korrekt („Samba", „Weißbier, alkoholfrei") — also Browser-richtig, Crawler-falsch: ein Prerender-Snapshot-Bug auf lebenden Produkten, keine toten URLs. Vermutete Ursache: der Snapshot wird abgegriffen, bevor die Produktdaten async laden; Rezept-Routen laden rechtzeitig.→ Prerender-Keying fixen: auf die Produktdaten warten, bevor der Snapshot OG-Titel/-Bild schreibt. Höchste Priorität.
Startseiten-
og:imagezeigt aufapp_logo-192x192.png→ liefert 200 text/html (die SPA-Hülle), kein PNG; die Pfade soft-404en.og:image:width/heightlügen zudem (1062×759 für eine „192er" Datei).→ Auf ein echtes Bild zeigen; falsche Maße korrigieren.Meta ist UA-gegated:
og:title= 1 für WhatsApp/facebookexternalhit, aber 0 für eine normale Browser-UA. WhatsApp + Facebook sind abgedeckt — jeder Crawler außerhalb der Allowlist (Signal, Telegram, Slack, LinkedIn, Mastodon) bekommt die leere Hülle, also keine Vorschau.→ Allowlist weiten oder die Meta-Hülle generell ausliefern. (Auch fehlend: twitter-Tags, og:url, og:site_name/locale.)webshop.…workers.dev — CTO-Build: sauberste Tags, Staging-Bild
Headless-Rebuild · Christoph TrapplDie bestgebaute Tag-Schicht der drei (einziger mit
og:site_name+og:locale), statisch an alle UAs. Produktseite = vollesummary_large_image-Karte (og + twitter).Aber der Bild-Host ist
testshop.isarland.de— das Staging-Backend (dieselbe Fragilität wie im Vor-Audit). Jede Vorschau-Karte hängt daran, dass Staging erreichbar bleibt.→ Vor Go-Live auf den Produktions-Host umstellen.Die
og:image-URL fordertwidth=1200, trägt aberallowUpscale=false, und die Quelle des geprüften Produkts ist nur 200px — der Crawler bekommt ein 200×200, 6 KB-Thumbnail unter einem Großbild-Banner. An einem Produkt beobachtet, bei kleinen Quellen vermutlich wiederkehrend.→allowUpscale=falsedroppen oder eine von der Quelle gedeckte Breite anfordern.Startseite hat gar kein Bild (kein og:image, kein twitter:image,
twitter:card=summary). Auch fehltog:url.→ Startseiten-og:image/twitter:image+og:urlergänzen.Drei Mal dieselbe Lücke, an unterschiedlicher Stelle.
Das Demo beweist das Gerüst und überspringt die Nutzlast (perfekte Tags, kein Produktbild). Der Live-Shop hat die Nutzlast und bricht die Verkabelung (echte Fotos, aber falsch gekeyt + UA-gegated). Der CTO-Build hat die saubersten Tags und die fragilste Quelle (Staging, Thumbnail). Eine korrekte Karte braucht beides — erreichbares, richtig gekeytes, ausreichend großes Bild an jeden Crawler.
og:imageergänzen (Start: Share-Karte, Produkt: Produktfoto) — ein Tag, größter Effekt.allowUpscalelösen, damit Karten nicht 200px sind.