5. SEO und mobile Webauftritte

SEO und mobile Webauftritte

Eine Anwendung, die niemand findet und die auf dem Telefon unbrauchbar ist, hat kein technisches Problem. Sie hat keine Benutzer.

Suchmaschinenoptimierung hat einen zweifelhaften Ruf, und der ist zur Hälfte verdient: Es gibt eine Branche, die Platz eins verspricht und Textwüsten liefert. In diesem Kapitel geht es um die andere Hälfte, um die technische. Ob Ihre Seiten überhaupt erfasst werden können, ob eine Suchmaschine Ihren Inhalt sieht, ob Ihre Adressen stabil sind, ob die richtigen Seiten aus dem Index bleiben. Das ist prüfbar, und deshalb lautet der Leitsatz dieser Woche: Messung statt Meinung.

Wie eine Suchmaschine arbeitet

Schritt	Was passiert	Wo eigene Fehler wirken
Erfassen	Ein Roboter folgt Verweisen und lädt Seiten	`robots.txt`, fehlende interne Verweise, langsame Antworten
Rendern	JavaScript wird in einem zweiten Durchgang ausgeführt	rein clientseitig erzeugte Inhalte
Indexieren	Der Inhalt wird gespeichert und zugeordnet	`noindex`, kanonische Verweise, Duplikate
Bewerten	Die Reihung wird bestimmt	Inhalt, Verweise, Nutzbarkeit, Geschwindigkeit

Der zweite Schritt ist der, an dem moderne Anwendungen scheitern. Der Roboter lädt zunächst nur das HTML. Wenn dort außer einem leeren div nichts steht, kommt die Seite in eine Warteschlange für das Rendern, und dieser Durchgang kostet Rechenzeit, kommt später und wird nicht garantiert vollständig ausgeführt.

Die Prüfung dauert zehn Sekunden:

curl -s https://projekt.example.at/events/summer-festival | grep -c "<h1"

Kommt hier 0 heraus, sieht die Suchmaschine im ersten Durchgang keine Überschrift. Die Antwort darauf haben Sie im Vorjahr schon gebaut: serverseitiges Rendern für Inhalte, die gefunden werden sollen, statische Erzeugung für alles, was sich selten ändert. Interaktive Bereiche hinter der Anmeldung dürfen ruhig clientseitig laufen, die sollen ohnehin nicht in den Index.

Was Sie nicht beeinflussen können, ist die Reihung selbst. Wer Platz eins garantiert, verkauft etwas, das er nicht besitzt. Gekaufte Verweise, versteckter Text und Seiten voller wiederholter Suchbegriffe sind keine Optimierung, sondern ein Grund für eine Abstrafung.

Technische Grundlagen

Aufbau und Adressen

Semantisches HTML aus dem Vorjahr zahlt hier ein zweites Mal: Eine h1 pro Seite, eine saubere Überschriftenhierarchie, main, nav und article an den richtigen Stellen. Eine Suchmaschine liest dieselbe Struktur wie ein Screenreader.

Adressen sind sprechend und dauerhaft:

gut:      /veranstaltungen/sommerfest-2026
schlecht: /p?id=713&ref=nav&session=abc

Was einmal veröffentlicht ist, bleibt erreichbar. Wenn eine Adresse sich ändern muss, kommt eine dauerhafte Weiterleitung (301) darauf, damit weder Verweise noch die aufgebaute Bewertung verloren gehen. Und jede Seite muss über Verweise erreichbar sein; eine Seite, auf die nichts zeigt, findet niemand, auch keine Suchmaschine.

Titel und kanonischer Verweis

export async function generateMetadata({ params }): Promise<Metadata> {
  const event = await loadEvent(params.slug);
  if (!event) return { title: "Not found" };

  return {
    title: `${event.title} - Werkstatt Villach`,
    description: event.summary.slice(0, 155),
    alternates: {
      canonical: `https://projekt.example.at/events/${event.slug}`,
    },
    openGraph: {
      title: event.title,
      images: [event.imageUrl],
      type: "article",
    },
    robots: event.published ? undefined : { index: false },
  };
}

Der Titel ist je Seite verschieden, etwa 50 bis 60 Zeichen lang und stellt das Besondere nach vorne. Die Beschreibung ist keine Stichwortliste, sondern der Text, der in der Trefferliste zum Klicken einlädt.

Der kanonische Verweis löst das Duplikatsproblem. Dieselbe Liste unter /machines, /machines?sort=name und /machines?page=1 ist für eine Suchmaschine dreimal derselbe Inhalt; der kanonische Verweis sagt, welche Adresse gilt.

robots.txt, Sitemap, Statuscodes

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const pages = await allPublished();
  return [
    { url: "https://projekt.example.at/", changeFrequency: "weekly", priority: 1 },
    ...pages.map((p) => ({
      url: `https://projekt.example.at/events/${p.slug}`,
      lastModified: p.updatedAt,
    })),
  ];
}

Die Sitemap wird erzeugt, nicht gepflegt. Eine von Hand geschriebene Liste ist nach zwei Wochen falsch.

Bei den Statuscodes zählen drei Fälle: 301 für dauerhafte Weiterleitungen, 302 nur für tatsächlich vorübergehende, und 404 für alles, was es nicht gibt. Der häufige Fehler ist der weiche 404: Die Anwendung antwortet mit 200 und zeigt „nicht gefunden” im Text. Für die Suchmaschine ist das eine gültige, inhaltsleere Seite, und davon sammelt sie dann Tausende.

Mehrsprachigkeit

Wenn Ihr Projekt aus dem Vorjahr mehrsprachig ist, braucht jede Sprachvariante einen hreflang-Verweis auf alle anderen, und alle verweisen wechselseitig aufeinander. Dazu ein x-default für Besucher, deren Sprache Sie nicht anbieten. Ohne das konkurrieren Ihre Sprachfassungen miteinander statt sich zu ergänzen.

Strukturierte Daten

Strukturierte Daten sagen einer Suchmaschine, was auf der Seite steht, nicht nur welche Wörter. Aus einer Veranstaltungsseite wird damit ein Eintrag mit Datum, Ort und Preis, der in der Trefferliste anders dargestellt werden kann.

Das Format ist JSON-LD nach dem Vokabular von schema.org, eingebettet in einem script-Element vom Typ application/ld+json:

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "Workshop Summer Festival",
  "startDate": "2026-06-27T17:00:00+02:00",
  "endDate": "2026-06-27T23:00:00+02:00",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "location": {
    "@type": "Place",
    "name": "Werkstatt Villach",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "Musterweg 4",
      "postalCode": "9500",
      "addressLocality": "Villach",
      "addressCountry": "AT"
    }
  },
  "offers": {
    "@type": "Offer",
    "price": "12.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://projekt.example.at/events/summer-festival-2026"
  }
}

Passende Typen für Schulprojekte sind Event, Product, Article, Organization, LocalBusiness, Recipe und FAQPage. Erzeugen Sie das aus denselben Daten, aus denen Sie die Seite rendern, sonst laufen die beiden auseinander.

Und das ist die Regel, die dahintersteht: Strukturierte Daten müssen dem sichtbaren Inhalt entsprechen. Bewertungen auszuzeichnen, die es auf der Seite nicht gibt, oder Preise, die woanders stehen, ist ein Richtlinienverstoß mit handfesten Folgen. Prüfen lässt sich das mit dem Testwerkzeug für Rich Results.

Dieselbe Familie sind die Open-Graph-Angaben, die bestimmen, wie Ihr Link in Messenger und sozialen Netzwerken aussieht: Titel, Beschreibung und ein Vorschaubild mit 1200 mal 630 Bildpunkten. Ohne sie erscheint ein grauer Kasten mit der nackten Adresse.

Geschwindigkeit und Sichtbarkeit

Die Core Web Vitals aus dem Vorjahr kommen hier wieder, jetzt unter anderem Vorzeichen: Sie sind ein Rangfaktor. Ein schwacher, verglichen mit der Frage, ob Ihr Inhalt zur Suche passt, aber ein messbarer, und bei ähnlich guten Treffern entscheidet er.

Wichtig ist der Unterschied zwischen Labor und Feld. Lighthouse misst unter kontrollierten Bedingungen auf Ihrem Rechner. Für die Bewertung zählen Werte echter Geräte echter Benutzer, und die fallen praktisch immer schlechter aus. Messen Sie deshalb mobil und gedrosselt, so wie im Vorjahr beschrieben, und nehmen Sie das Ergebnis als das realistischere.

Mobile Webauftritte

Mobile-first ist eine Haltung

Suchmaschinen indexieren die mobile Fassung Ihrer Seite. Daraus folgt eine Konsequenz, die viele überrascht: Was auf dem Telefon ausgeblendet ist, existiert für den Index nicht. Wer Inhalte auf kleinen Bildschirmen per CSS versteckt, statt sie umzubauen, verliert sie aus der Bewertung.

Die Punkte, an denen es hakt

Sichtfenster. Ohne <meta name="viewport" content="width=device-width, initial-scale=1"> skaliert das Telefon Ihre Seite wie eine Desktopseite herunter.
Zoom nicht verbieten. user-scalable=no ist bequem gegen ungewollte Zoomsprünge und ein Barrierefreiheitsverstoß.
Eingabefelder ab 16 Pixel Schriftgröße, sonst zoomt iOS beim Hineintippen automatisch hinein.
Berührungsziele mit ausreichender Fläche und Abstand, besonders bei Löschen neben Bearbeiten.
Daumenzone. Häufige Aktionen gehören ins untere Drittel, nicht in die obere rechte Ecke.
Eingabetypen setzen: type, inputmode, autocomplete und enterkeyhint bestimmen, welche Tastatur erscheint und wie viel getippt werden muss.
Sichere Bereiche über env(safe-area-inset-bottom), damit Ihre Fußleiste nicht unter dem Balken des Geräts liegt.

Schlechte Verbindung

Im Mobilfunknetz zählen Bytes. Bilder in mehreren Größen mit srcset ausliefern, moderne Formate verwenden, alles unterhalb des Sichtbereichs verzögert laden, Schriften lokal und knapp halten. Und dann testen Sie es unter langsamem 3G in den Entwicklungswerkzeugen, statt es im Schul-WLAN für schnell zu halten.

Was passiert, wenn die Verbindung ganz weg ist, ist Thema von Kapitel 8. Hier geht es um den Webauftritt im mobilen Browser, nicht um die installierbare Anwendung.

Messen und nachweisen

Anwendung bei der Search Console anmelden und die Inhaberschaft über einen DNS-Eintrag oder eine Datei bestätigen.
Sitemap einreichen und nach einigen Tagen den Indexierungsbericht ansehen: Welche Seiten sind drin, welche nicht, und mit welcher Begründung.
Einzelne Adresse prüfen mit der URL-Prüfung: Was sieht der Roboter, wann war er zuletzt da, welche kanonische Adresse hat er gewählt.
Ausgangsmessung festhalten: indexierte Seiten, Core Web Vitals mobil, drei Beispielseiten mit Titel und Beschreibung.
Maßnahmen umsetzen und nach zwei Wochen erneut messen. Der Index braucht Zeit; wer nach einem Tag urteilt, misst nichts.

Häufige Stolperfallen

Inhalte erst im Browser erzeugen und sich über die fehlende Indexierung wundern.
Titel und Beschreibung für alle Seiten identisch, meist der Projektname.
Testumgebung im Index, weil noindex fehlt.
robots.txt als Sperre missverstanden, obwohl noindex gemeint war.
Weicher 404: Statuscode 200 mit dem Text „nicht gefunden”.
Adressen geändert ohne Weiterleitung. Alle bestehenden Verweise laufen ins Leere.
Strukturierte Daten, die nicht dem sichtbaren Inhalt entsprechen.
Inhalte auf dem Telefon ausgeblendet statt umgebaut, und damit aus dem Index.
Zoom gesperrt oder Eingabefelder zu klein.
Auf dem Notebook optimiert, nie mit Drosselung auf einem Telefon geprüft.

Lernergebnisse

Erklären: den Weg einer Seite von der Erfassung über das Rendern und Indexieren bis zur Bewertung beschreiben.
Analysieren: prüfen, was eine Suchmaschine im ersten Durchgang von Ihrer Seite sieht, und die Rendering-Strategie danach wählen.
Anwenden: Titel, Beschreibung, kanonische Verweise, Sitemap und Statuscodes korrekt umsetzen.
Erklären: den Unterschied zwischen robots.txt und noindex erklären und beides passend einsetzen.
Anwenden: strukturierte Daten für den eigenen Inhaltstyp erzeugen und auf Übereinstimmung mit dem sichtbaren Inhalt prüfen.
Anwenden: die Anwendung mobil unter realistischen Bedingungen prüfen und die typischen Schwachstellen beheben.
Beurteilen: Maßnahmen nach Wirkung reihen und unseriöse Versprechen als solche erkennen.

Arbeit am Jahresprojekt

Ein Bericht in docs/sichtbarkeit.md mit:

Ausgangsmessung: indexierte Seiten, Core Web Vitals mobil, drei Beispielseiten mit Metadaten.
Nachweis, dass der öffentliche Bereich ohne JavaScript lesbaren Inhalt liefert.
Erzeugte Sitemap, robots.txt, kanonische Verweise, noindex für Test- und Kontobereiche.
Strukturierte Daten für mindestens einen Inhaltstyp, mit Prüfergebnis.
Open-Graph-Angaben samt Vorschaubild.
Mobile Prüfung mit Drosselung, Vorher-Nachher, mit Bildschirmfotos.

Passende Übungen

Aufgabe - Indexierbarkeit prüfen und Hindernisse beheben
Aufgabe - Strukturierte Daten für den eigenen Inhaltstyp
Aufgabe - Mobile Prüfung mit Drosselung