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.
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.
2
Kritisch
Bricht oder liefert still Falsches.
2
Funktional
Funktioniert, widerspricht oder täuscht.
2
Strukturell
Bricht nicht, wirkt aber unsauber.
0 B
og:image-Body
HTTP 200, leeres PNG
153
tote sitemap-URLs
~7% · Umlaut-Slugs 404
3×
Produktzahl
40 · 150+ · 2141
16/16
KI-Bots erlaubt
robots offen · GEO stark
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 + Produkt
KRITISCHK1
og: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
FUNKTIONALF1
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
STRUKTURS1·S2
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 · schema
KRITISCHK2
153 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
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-image reparieren (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.
44up Observatory · Link-Vorschau / Social-Sharing
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)
Signal
fabular.pages.dev · Demo
isarland.de · Live
webshop · CTO-Build
og:title / description
✓ S + P
✓ S + P (P falsch gekeyt)
✓ S + P
og:image vorhanden
✗ S + P
S: ✗ kaputt · P: ✓
S: ✗ · P: ✓
og:image ist ein echtes Bild
—
S: text/html · P: JPEG 1200×1097
P: JPEG, aber 200×200
Bild-Host
—
www.isarland.de (Prod)
testshop.isarland.de (Staging)
twitter:card
summary_large_image (=Logo)
✗ keine
summary_large_image
og:url
✓
✗
✗ (canonical da)
og:site_name / locale
✗ / ✗
✗ / ✗
✓ / ✓ (de_DE)
Meta an alle Crawler
✓ statisch
⚠ UA-gegated (nur Bots)
✓ statisch
WhatsApp · Startseite
nur Text
nur Text (Bild kaputt)
nur Text
WhatsApp · Produkt
nur Text, kein Bild
Foto ✓ — aber falsches Produkt
Foto ✓ — aber 200px, Staging
✓ funktioniert · ⚠/rot degradiert oder fehlt · — n/a. WhatsApp/Facebook/LinkedIn/Signal lesen og:image, nicht twitter:image.
Pro Storefront
fabular.pages.dev — das Demo: beste Tags, kein Bild
Fresh Haven · Referenz-Demo
✓ Tags
Die vollständigste Tag-Schicht der drei (OG + Twitter + canonical + theme-color), komplett statisch — jeder Crawler, jede UA bekommt sie.
✗ Bild
Aber og:image fehlt — 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 sind twitter:title/description sogar die generischen Startseiten-Texte, nicht die des Produkts.→ og:image ergä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 Meta
✓ Foto
Produktseiten 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.
✗ falsch
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.
✗ Start
Startseiten-og:image zeigt auf app_logo-192x192.png → liefert 200 text/html (die SPA-Hülle), kein PNG; die Pfade soft-404en. og:image:width/height lügen zudem (1062×759 für eine „192er" Datei).→ Auf ein echtes Bild zeigen; falsche Maße korrigieren.
⚠ UA
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.)
Die bestgebaute Tag-Schicht der drei (einziger mit og:site_name + og:locale), statisch an alle UAs. Produktseite = volle summary_large_image-Karte (og + twitter).
⚠ Host
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.
⚠ 200px
Die og:image-URL fordert width=1200, trägt aber allowUpscale=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=false droppen oder eine von der Quelle gedeckte Breite anfordern.
✗ Start
Startseite hat gar kein Bild (kein og:image, kein twitter:image, twitter:card=summary). Auch fehlt og:url.→ Startseiten-og:image/twitter:image + og:url ergä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.
isarland.de: Produkt-Prerender-Keying fixen (geteilte Links zeigen das falsche Produkt) — danach Startseiten-Bild + UA-Gate.
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.