Last Flag Wiki
Community-Wiki für das Spiel Last Flag mit TypeScript-strict und SEO-first-Architektur.
Warum dieses Projekt
Last Flag ist ein Multiplayer-Capture-the-Flag-Spiel, das wir selbst gespielt haben. Guides und Item-Daten waren uber Discord und Reddit verstreut - wir wollten eine ordentliche Referenz dafur bauen.
Was gebaut wurde
Last Flag Wiki ist eine statisch generierte Content-Site auf Next.js 16 App Router mit React 19 und strikter TypeScript-Konfiguration. Inhalte werden in MDX geschrieben - Markdown mit eingebetteten React-Komponenten - und zur Build-Zeit zu statischem HTML kompiliert.
Kernfunktionen:
- Item-Datenbank - jede Waffe, jedes Rüstungsteil, jedes Verbrauchsgut und jedes Upgrade mit Stats, Fundort und Tier-Bewertung
- Map-Guides - taktische Breakdowns jeder Map mit Flaggenpositionen, Rotationspfaden und annotierten Diagrammen
- Crafting-Rechner - interaktive Komponente (nur clientseitig) zur Planung von Ressourcenkombinationen
- Suche - clientseitige Volltextsuche über den statischen JSON-Datenexport, kein Server erforderlich
- Redirect-System - wenn Map- oder Item-Namen zwischen Patches geändert werden, leiten alte URLs auf die neuen kanonischen Seiten weiter statt 404 zu zeigen
Technische Architektur
Static Generation zuerst. Jede Seite wird zur Build-Zeit generiert. Es gibt keinen Server, der ausfallen kann, keine Datenbank, die gewartet werden muss, keine API, die unter Last zum Engpass wird. Die gesamte Site ist eine Sammlung von HTML-, JS- und CSS-Dateien, die von einem CDN oder jedem statischen Hoster ausgeliefert werden können.
Strict TypeScript. tsconfig.json hat strict: true, noUncheckedIndexedAccess: true und exactOptionalPropertyTypes: true. Das klingt nach Overhead, bis man Item-Daten pflegt, bei denen ein fehlendes Feld ein Runtime-Bug auf einer nutzerseitigen Seite ist. Der Strict-Modus fängt diese Bugs zur Build-Zeit ab.
MDX-Content. Spiel-Guides profitieren davon, in Fließtext geschrieben zu werden - sie brauchen aber auch strukturierte Elemente: Stat-Tabellen, Vergleichsgrids, Callout-Boxen für kritische Informationen. MDX lässt den Content-Autor Markdown für Fließtext schreiben und React-Komponenten für strukturierten Content nutzen. Kein CMS-UI erforderlich; der Content liegt im Repository neben dem Code.
Null unnötige Abhängigkeiten. Die Dependency-Liste ist bewusst minimal: Next.js, React, Tailwind, content-collections für MDX-Verarbeitung - und nichts weiter. Keine schweren Komponentenbibliotheken, kein State-Management-Framework. Jede Abhängigkeit ist eine Wartungslast in einem langlebigen Projekt.
Custom Font Handling. DM Serif Display wird über next/font/local selbst gehostet - keine Abhängigkeit von Googles CDN für den primären Display-Font der Site.
SEO-Entscheidungen
Wiki-Content konkurriert mit etablierten Fandom-Wikis und YouTube-Guides. Auf organischer Suche zu gewinnen erfordert technische Korrektheit, nicht nur Inhaltsvolumen.
Heading-Hierarchie. Jede Seite hat ein einziges H1 (der Item- oder Guide-Name), gefolgt von einer logischen H2/H3-Struktur, die den tatsächlichen Suchanfragen der Spieler entspricht.
BreadcrumbList-Schema. Jede Seite enthält BreadcrumbList-Strukturdaten, damit Google die Site-Hierarchie versteht und Breadcrumbs in Suchergebnissen anzeigen kann.
Kanonische URLs. Item-Varianten und Patch-spezifische Seiten verwenden Canonical-Tags, die auf den primären Eintrag zeigen, um doppelte Indexierung zu verhindern.
Interne Verlinkung. Jede Item-Erwähnung in einem Guide verlinkt auf die Item-Datenbankseite. Das schafft einen dichten internen Link-Graphen, der Equity an die wichtigsten Seiten weitergibt und die Crawling-Effizienz verbessert.
Redirect-Handling. Spiel-Content ändert sich zwischen Patches - Items werden umbenannt, Maps überarbeitet. Permanente Weiterleitungen (308) erhalten die SEO-Equity alter URLs statt sie durch 404-Fehler zu verlieren.
Ergebnis
Last Flag Wiki gibt der Community des Spiels eine permanente, durchsuchbare, von Google indexierte Referenz. Die statische Architektur bedeutet, dass sie korrekt funktioniert, solange jemand die Domain bezahlt - keine Datenbankmigrationen, keine Security-Patches, keine Runtime-Abhängigkeiten, die unter Zeitdruck aktualisiert werden müssen.



