Bei Next.js entstehen technische Suchprobleme selten aus fehlendem Wissen, sondern aus dem Rendering-Modell. Ob eine Seite statisch erzeugt, bei Anfrage gerendert oder erst im Browser gefüllt wird, entscheidet darüber, was eine Suchmaschine sieht.
Zuerst prüfen, was tatsächlich ausgeliefert wird
Der erste Schritt bei jeder Prüfung ist nicht ein Werkzeug, sondern der Blick in den ausgelieferten Quelltext. Steht der Inhalt dort, ist er sichtbar. Steht dort nur ein Grundgerüst, das der Browser füllt, ist er es möglicherweise nicht.
Bei statisch erzeugten Anwendungen lohnt es sich, direkt in die Bauausgabe zu schauen statt auf die laufende Seite. Fehler entstehen beim Bauen, und dort sind sie am schnellsten zu finden — und automatisiert prüfbar.
Metadaten pro Seite
Die Metadaten-Schnittstelle erlaubt statische und dynamisch erzeugte Angaben. Der häufigste Fehler ist eine Vorlage, die Titel und Beschreibung für alle dynamischen Seiten gleich lässt.
Bei einer Handvoll Seiten fällt das nicht auf. Bei mehreren hundert ist es das stärkste Signal für maschinell erzeugten Inhalt, das eine Website senden kann. Eine automatische Prüfung auf doppelte Titel und Beschreibungen im Bauprozess fängt das ab.
Kanonische Adressen
Jede indexierbare Seite sollte auf sich selbst verweisen, mit vollständiger Adresse. Auch das wird häufig aus einer Vorlage übernommen und zeigt dann für alle Seiten auf dieselbe.
Die Folge ist, dass die Seiten nicht aufgenommen werden — ein Fehler, der sich in keiner Fehlermeldung zeigt und erst auffällt, wenn Sichtbarkeit ausbleibt.
Sprachfassungen ehrlich auszeichnen
Wo mehrere Sprachfassungen bestehen, gehören sie gegenseitig ausgewiesen. Drei Bedingungen müssen erfüllt sein: Die Verweise sind beidseitig, sie zeigen auf Seiten, die existieren und indexierbar sind, und es gibt eine Angabe für den Fall, dass keine Fassung passt.
Der typische Fehler bei mehrsprachigen Anwendungen ist eine automatische Auszeichnung aller konfigurierten Sprachen für jede Seite — auch für Seiten, die es nur in einer Sprache gibt. Die Verweise zeigen dann auf Fehlerseiten, und die gesamte Auszeichnung wird ignoriert.
Die tragfähige Lösung ist, je Seite zu ermitteln, in welchen Sprachen sie tatsächlich vorliegt, und nur diese auszuzeichnen.
Die Sitemap aus derselben Quelle
Eine Sitemap sollte aus denselben Daten erzeugt werden wie die Seiten selbst. Eine von Hand gepflegte Sitemap läuft dem Bestand hinterher und enthält früher oder später Adressen ohne Seite.
Prüfbar ist das automatisch: Die Menge der Adressen in der Sitemap und die Menge der gebauten indexierbaren Seiten müssen übereinstimmen. Jede Abweichung in beide Richtungen ist ein Fehler.
Bilder und Ladeverhalten
Die Bildkomponente von Next.js löst Grössen, Formate und verzögertes Laden. Der Fehler, der die Messwerte verschlechtert, ist verzögertes Laden für das Bild im sichtbaren Bereich — dann wartet die Anzeige des wichtigsten Elements auf einen Ladevorgang, der hätte sofort starten können.
Für das erste sichtbare Bild gehört deshalb die Priorisierung gesetzt und das verzögerte Laden abgeschaltet.
Der zweite häufige Punkt sind Verschiebungen des Layouts, wenn Elemente nachladen und Platz beanspruchen, der vorher nicht reserviert war. Feste Abmessungen für alles, was nachlädt, lösen das.
Was in den Bauprozess gehört
Die genannten Prüfungen lassen sich alle automatisieren: doppelte Titel, doppelte Beschreibungen, fehlende Überschriften, Abweichungen zwischen Sitemap und Seitenbestand, Sprachauszeichnungen auf nicht existierende Seiten, Seiten ohne eingehende interne Verweise.
Ein Bauprozess, der bei diesen Punkten fehlschlägt, verhindert die Fehlerklasse dauerhaft. Manuelle Prüfungen erledigen dasselbe einmal und danach nie wieder.