CI / validate (push) Waiting to run

Details

feat(web): Marketing-Pages-Lift + JSON-LD + Cross-Linking-Footer

- Marketing-Pages aus apps/landing/ (deferred) nach apps/web/src/pages/:
  ueber.astro, fuer-veranstalter.astro (mit FAQ-Schema.org), mitwirken.astro.
  Statt Apex-Cutover bleibt seepuls.com SSR-Aggregator + Marketing
  integriert (siehe apps/landing/DEFERRED.md für Begründung).
- apps/web/src/lib/app.ts: AppMeta lokal definiert (SOT für JSON-LD-
  Builder + Footer).
- Base.astro: Organization + WebSite + SoftwareApplication JSON-LD global,
  jsonLd-Prop für Page-spezifische Schemas. Cross-Linking-Footer mit
  „Weitere Werkzeuge des Vereins".
- event/[slug].astro: Event-Schema.org + Breadcrumb.
- venue/[slug].astro: Place/EventVenue/PerformingArtsTheater/Museum/BarOrPub
  je nach venue.category + Breadcrumb.
- sitemap.xml.ts um /ueber, /fuer-veranstalter, /mitwirken erweitert.
- marketing-kit auf ^0.3.0.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-25 02:29:48 +02:00

3.1 KiB

Raw Permalink Blame History

apps/landing/ — DEFERRED (2026-05-23)

Diese Astro-Marketing-Landing ist nicht aktiv im Live-Routing.

Entscheidung 2026-05-23

Statt eines Apex-Cutovers wie bei pageta/wordeck/herbatrium (<x>.com → Marketing-Landing, App auf app.<x>.com) wurden die drei substanziellen Marketing-Pages dieser Landing in apps/web/ integriert und werden dort auf der Apex-Domain ausgespielt:

Diese Landing (apps/landing/src/pages/)	Lebt jetzt unter
`index.astro`	nicht migriert (apps/web rendert `/` schon als Aggregator-Index — der Apex-SEO-Substanz; eine separate Marketing-„Was ist Seepuls"-Seite war nicht stark genug, um den Aggregator vom Apex zu verdrängen)
`ueber.astro`	`apps/web/src/pages/ueber.astro` → `https://seepuls.com/ueber`
`fuer-veranstalter.astro`	`apps/web/src/pages/fuer-veranstalter.astro` → `https://seepuls.com/fuer-veranstalter`
`mitwirken.astro`	`apps/web/src/pages/mitwirken.astro` → `https://seepuls.com/mitwirken`
`robots.txt.ts`, `sitemap.xml.ts`, `llms.txt.ts`	bleiben in `apps/landing/` (nicht deployed); `apps/web/src/pages/{robots,sitemap}.{txt,xml}.ts` sind die Live-Versionen

Warum nicht Cutover

Anders als bei den drei Apps der ersten Cutover-Welle ist seepuls.com SEO-mäßig wertvoll auf der Apex — siehe mana/docs/playbooks/LANDING_CUTOVER.md und die Diskussion in der Session vom 2026-05-23:

100+ Permalinks unter /venue/* und /event/* haben echtes Crawl-Kapital — ein Cutover hätte sie nur per 301 umgeschoben.
Login ist optional, kein Cookie-Scope-Argument für eine App-Subdomain.
Primary-Switch von seepuls.mana.how auf seepuls.com war erst 2026-05-20; zweiter Switch innerhalb 72 h wäre operative Reibung gegen Googles ersten Re-Index-Cycle.
Die SSR-Astro-App spielt frische Events ohne Container-Rebuild aus — saubere Marketing/App-Trennung würde zwei Deploy-Pipelines, zwei Sitemap-Generatoren und einen GSC-Property-Split bedeuten.
AASA-Pfade (/heute, /venue/*, /event/*) sind genau die SEO-Pfade — Universal-Links + 301-Kette werden semantisch konfliktreich.

Was mit dieser Datei passieren soll

Nicht löschen, nicht deployen. Bleibt als Code-Schnipsel-Source für @mana/marketing-kit-Pattern (Hero/StorySection/FAQ-Aufbau).
Bei Schema-/Theme-Updates in @mana/marketing-kit: die migrierten Versionen in apps/web/src/pages/ mit-aktualisieren, nicht hier.
Falls sich die Architektur-Entscheidung irgendwann umkehrt (großer Re-Brand, Marketing-Domain getrennt von Aggregator), könnte diese Landing-Variante als Ausgangspunkt für einen späteren Cutover dienen.

Port-Status

3203 ist in mana/docs/PORTS.md als „Marketing-Landings, Welle 1" reserviert. Auf mana-server läuft seit 2026-05-20 ein seepuls-landing-Container auf diesem Port — er ist über Cloudflared nicht verlinkt (kein hostname-Eintrag), also für die Außenwelt unsichtbar, aber er belegt den Port. Folgeschritt (separater Sprint): Container stoppen + entfernen, Port als „belegt durch deferred Landing" markieren oder freigeben.

3.1 KiB Raw Permalink Blame History