Next.js-Entwicklung in Hamburg für Logistik und Verlage

Hamburg kauft Software aus zwei sehr verschiedenen Gründen, und die beiden Branchen der Stadt erzeugen dabei dasselbe technische Problem.

Speditionen, Reedereien und Hafenlogistiker brauchen Kundenoberflächen über Systemen, die nie eine haben sollten. Verlage und Medienhäuser müssen Jahrzehnte Archiv ins öffentliche Netz bringen, ohne dass es unter der eigenen URL-Zahl zusammenbricht. In beiden Fällen ist die interessante Grenze die Menge an Adressen und nicht die Menge an Seiten.

Die Daten sind ein Batch, kein Feed

Die meisten Hamburger Projekte beginnen mit einem Quellsystem, das kein Webservice ist. Ein Terminal-Operating-System, ein Transportmanagementsystem, ein EDI-Feed, ein nächtlicher Export auf einem SFTP-Server.

Das sollte in der Oberfläche sichtbar sein statt von ihr verdeckt. Eine Seite mit „Position Stand 06:15" ist vertrauenswürdig; eine Seite, die live aussieht über einem Feed, der viermal täglich läuft, produziert jedes Mal Support-Tickets, wenn jemand neu lädt und sich nichts bewegt.

Technisch klärt das die Cache-Frage auf angenehme Weise. Wenn sich die Daten planmäßig ändern, kann die Seite bis zum nächsten Batch gecacht und bei dessen Ankunft revalidiert werden - deutlich billiger als jede Anfrage als potenziell neu zu behandeln. Was Next.js cacht und wann lohnt sich vor dieser Entscheidung, denn der falsche Standard liefert hier entweder eine veraltete Seite, die niemand leeren kann, oder eine Seite, die bei jedem Bot-Besuch neu baut.

Eine URL pro Sendung ist eine SEO-Entscheidung

Eine Tracking-Seite ist das klarste Beispiel für eine URL, die existieren muss, schnell sein muss und nicht indexiert werden darf.

Sie enthält die Sendungsdaten einer Person hinter einer Referenznummer. Suchmaschinen haben darauf nichts zu suchen. In einer Sitemap hat sie nichts zu suchen. Und sie muss trotzdem deutlich unter einer Sekunde rendern, auch für die Person, die die Nummer am Handy in einer Halle mit schlechtem Empfang eingibt.

Alle drei Punkte zu treffen heißt: ein bewusstes robots-Setting auf dieser Route, Ausschluss im Sitemap-Generator statt eines nachträglich angeschraubten Filters, und eine Rendering-Strategie, die keine Seite statisch cacht, deren Schlüssel personenbezogen ist. Drei Entscheidungen in drei Dateien, und die Standards treffen zwei davon falsch.

Archive, die in Hamburger Redaktionen die Standards sprengen

Die Verlagsseite der Stadt hat das umgekehrte Problem: Seiten, die indexiert werden sollen, in Mengen, die das Standard-Setup überschreiten.

Eine Sitemap-Datei fasst fünfzigtausend URLs, ein Zwanzig-Jahres-Archiv braucht also einen Sitemap-Index über mehrere Dateien. Schwieriger ist die URL-Inflation, die Archive von selbst erzeugen - Autorenseiten, Tag-Seiten, Jahres- und Monatslisten, paginierte Indizes -, jede davon eine dünne Seite, die mit dem Artikel konkurriert, auf den sie verlinkt.

Die Lösung ist unspektakulär und wirkt: entscheiden, welche Listen kanonisch sind, welche mit korrekten Beziehungen paginiert werden, und welche gar nicht crawlbar sein sollen. Die Begründung steht in Canonicals und Sitemaps, und technisches SEO ist meist das Projekt, das daraus folgt.

Kaufmännisch

Umfang vor Beginn schriftlich, Preis pro Projekt. Der Rahmen auf Länderebene - deutscher Datenschutz, Barrierefreiheitsfrist, E-Rechnungspflichten - steht auf der Länderseite Deutschland.

Abgerechnet von der Codefacture Yazılım A.Ş. in der Türkei, in Euro, per Überweisung, ohne türkische Umsatzsteuer, weil exportierte Leistungen befreit sind.