SEO Hosting Service: Der Prüfkatalog für die Server- und Vertragsschicht

Ein SEO Hosting Service verkauft Ihnen keine Suchmaschinenoptimierung, sondern eine Infrastrukturzusage. Wer den Begriff recherchiert, bekommt allerdings zwei völlig verschiedene Produkte auf denselben Suchbegriff geliefert, und die Verwechslung ist teuer: Das eine Paket ist für Betreiber ganzer Projektnetzwerke gedacht, das andere für ein einzelnes Hauptprojekt, das schnell und zuverlässig erreichbar sein muss. Dieser Text trennt beide Bedeutungen sauber voneinander und liefert danach den Prüfkatalog, den Sie brauchen, bevor Sie einen Vertrag unterschreiben oder kündigen. Es geht ausdrücklich nur um die Server- und Vertragsschicht, also um alles, was Sie beim Anbieter einkaufen. Was danach im Frontend, im CMS oder im Linkprofil passiert, bleibt außen vor.

Zwei Produkte, ein Name

SEO Hosting im engeren Sinn: Viele IPs für viele Projekte

Im Markt beschreibt hosttest.de SEO-Hosting-Pakete als spezielle Webspace-Angebote, die sich in erster Linie an professionelle Suchmaschinenoptimierer richten. Konkreter wird SeoAgents: Gemeint sind Pakete, die einem einzigen Kunden viele IP-Adressen aus unterschiedlichen Netzbereichen bereitstellen. Der Zweck ist hierbei ausdrücklich nicht Performance. Der Zweck ist, dass mehrere Websites desselben Betreibers auf den ersten Blick nicht wie ein zusammenhängendes Netzwerk aussehen.

Genau hier lohnt sich ein genauerer Blick auf die Verkaufsargumentation. Diese Pakete werben traditionell mit unterschiedlichen Class-C-IPs. Die klassenbasierte IPv4-Adressierung, aus der der Begriff Class-C stammt, wurde jedoch bereits 1993 durch Classless Inter-Domain Routing abgelöst, festgehalten in RFC 1519. Der Begriff beschreibt seit über drei Jahrzehnten keine reale Struktur des Adressraums mehr, sondern nur noch eine Faustformel: Die dritte Zahl der IP-Adresse soll sich unterscheiden. Wer ein Produkt kauft, dessen Kernversprechen über eine 1993 abgeschaffte Einteilung formuliert wird, sollte zumindest nachfragen, welche Netzbereiche, welche autonomen Systeme und welche Registrierungsdaten tatsächlich dahinterstehen.

Für den Normalfall gilt: Wenn Sie eine Website betreiben oder einige wenige klar getrennte Firmenauftritte verwalten, brauchen Sie dieses Produkt nicht. Sie zahlen dann für ein Merkmal, das für Ihr Projekt keinerlei Wirkung entfaltet.

SEO Hosting im weiteren Sinn: Schnelles, stabiles Hosting für ein Hauptprojekt

Der zweite, deutlich häufigere Anwendungsfall meint schlicht Webhosting, das der Suchmaschine keine Steine in den Weg legt. Hier geht es um Antwortzeiten, Verfügbarkeit, Fehlerverhalten und um die Frage, ob der Vertrag diese Eigenschaften überhaupt zusichert oder nur bewirbt. Fast jeder Ratgeber zum Thema nennt dieselben fünf Prüfpunkte: Ladezeit, Verfügbarkeit, Serverstandort, SSL und IP-Reputation. Diese Liste ist nicht falsch, aber sie bleibt unvollständig, solange niemand sagt, welche Zahl im Vertrag stehen muss und wie Sie deren Einhaltung nachweisen.

Die folgenden sechs Punkte sind genau so formuliert, dass Sie sie einem Anbieter vorlegen können.

Prüfpunkt 1: Server-Antwortzeit (TTFB)

Die Server-Antwortzeit, üblicherweise als Time to First Byte gemessen, ist der einzige Ladezeit-Bestandteil, für den ausschließlich der Hoster verantwortlich ist. Nach der Messdefinition von web.dev gilt ein TTFB von 800 Millisekunden oder weniger als gut, ab 1.800 Millisekunden gilt es als schlecht.

Diese Zahl steht nicht für sich allein. Der Schwellenwert für einen guten Largest Contentful Paint liegt bei 2,5 Sekunden für 75 Prozent der Seitenaufrufe, und die Server-Antwortzeit ist der erste Teilabschnitt dieser Messung. Alles, was der Server vor dem ersten Byte verbraucht, fehlt später im Budget für Rendering und Bildauslieferung. Ein Server, der konstant 1,2 Sekunden für die Antwort braucht, verbraucht bereits rund die Hälfte des gesamten LCP-Budgets, bevor der Browser überhaupt etwas anzeigen kann.

Was Sie vom Anbieter verlangen sollten:

• eine zugesicherte Antwortzeit für dynamische Seiten, nicht nur für eine statische Testdatei,
• die Angabe des Messpunkts: gemessen ab Rechenzentrum oder ab einem realen Client in Deutschland,
• die Zusicherung, dass die Zahl auch unter Last gilt, nicht nur nachts um drei.

Prüfen können Sie das ohne Spezialwerkzeug. Ein einfacher Kommandozeilenaufruf gegen eine dynamische URL liefert die Zeit bis zum ersten Byte, und die Crawling-Statistiken in der Google Search Console zeigen Ihnen dieselbe Größe aus der Perspektive der Suchmaschine über Wochen hinweg. Diese beiden Quellen genügen, um eine Zusage zu überprüfen.

Prüfpunkt 2: Verfügbarkeit und was die SLA-Zahl wirklich erlaubt

Verfügbarkeitsangaben klingen alle ähnlich, unterscheiden sich aber um eine Größenordnung. Eine zugesicherte Verfügbarkeit von 99,9 Prozent erlaubt rechnerisch bis zu 43,2 Minuten Ausfall pro 30-Tage-Monat. 99,99 Prozent erlauben 4,3 Minuten.

Der Unterschied zwischen beiden Zeilen ist der Unterschied zwischen einem unbemerkten Aussetzer und einem Vorfall, den Sie im Kalender wiederfinden. Wichtiger als die Zahl selbst sind allerdings drei Klauseln, die in Werbetexten fast nie auftauchen:

1. Was zählt als Ausfall? Viele Verträge zählen nur den vollständigen Ausfall des Servers, nicht die Auslieferung von Fehlerseiten und nicht eine Antwortzeit von zwölf Sekunden. Für Suchmaschinen ist beides praktisch ein Ausfall.
2. Sind Wartungsfenster ausgenommen? Angekündigte Wartung wird häufig aus der Berechnung herausgenommen. Dann bedeutet 99,9 Prozent nur 99,9 Prozent der nicht ohnehin geplanten Zeit.
3. Was ist die Rechtsfolge? In der Regel eine anteilige Gutschrift auf die Monatsgebühr. Bei einem Tarif im zweistelligen Eurobereich ist die Entschädigung für einen halben Tag Ausfall wirtschaftlich bedeutungslos. Die SLA ist deshalb kein Schadenersatz, sondern ein Qualitätsversprechen mit Beweislastregelung.

Prüfpunkt 3: Verhalten bei Fehlern gegenüber Googlebot

Dieser Punkt fehlt in fast jeder Anbieterbeschreibung und ist der teuerste. Google reduziert die Crawling-Frequenz, wenn ein Server langsamer antwortet oder mit Serverfehlern reagiert, und erhöht sie erst wieder, wenn der Server stabil schnell antwortet.

Das hat eine unangenehme Eigenschaft: Die Bremse wirkt verzögert und löst sich verzögert. Ein Wochenende mit überlastetem Server kostet Sie nicht nur die Erreichbarkeit an diesen zwei Tagen, sondern eine gedrosselte Crawlrate darüber hinaus, und die betrifft ausgerechnet neue und geänderte Inhalte.

Konkret sollten Sie mit dem Anbieter klären:

• Welchen Statuscode liefert der Server bei Überlast? Ein Lastabbruch, der als 500 Internal Server Error herausgeht, ist die schlechteste Variante. Für temporäre Zustände existiert 503 Service Unavailable, optional mit einem Retry-After-Header.
• Was passiert im Wartungsfenster? Eine Wartungsseite mit dem Statuscode 200 ist ein aktives Problem, weil sie inhaltlich identische Seiten als gültig ausliefert. Korrekt ist auch hier 503.
• Gibt es ein Rate-Limit oder eine Bot-Abwehr vor der Anwendung? Firewalls, Overload-Schutz und Bot-Management sitzen häufig beim Hoster und blockieren im Zweifel auch Googlebot. Lassen Sie sich schriftlich geben, dass verifizierte Suchmaschinen-Crawler ausgenommen sind, und lassen Sie sich zeigen, wie Sie das selbst in den Logs nachvollziehen können.

Zugriff auf die Rohlogs des Webservers gehört deshalb in den Vertrag. Ohne sie können Sie nie belegen, was der Server einem Crawler tatsächlich geantwortet hat.

Prüfpunkt 4: Serverstandort

Hier hält sich eine Behauptung besonders hartnäckig. In Googles Dokumentation zu mehrsprachigen und mehrregionalen Websites werden länderspezifische Top-Level-Domains, die Länderausrichtung in der Search Console und hreflang als Geotargeting-Signale genannt. Die physische Serveradresse steht nicht in dieser Liste.

Der Standort ist damit kein direktes Rankingargument. Er bleibt trotzdem aus zwei nüchternen Gründen relevant, und beide sind Vertragsfragen:

Latenz. Jeder Kilometer zwischen Nutzer und Server kostet Zeit, und diese Zeit landet im TTFB aus Prüfpunkt 1. Für ein Publikum in Deutschland ist ein deutsches oder mitteleuropäisches Rechenzentrum schlicht der kürzere Weg.

Rechtsrahmen. Wo die Daten liegen und wer sie verarbeitet, entscheidet darüber, welchen Auftragsverarbeitungsvertrag Sie brauchen und welche Angaben in Ihrer Datenschutzerklärung stehen müssen. Lassen Sie sich das Rechenzentrum und den tatsächlichen Betreiber benennen, nicht nur den Firmensitz des Hosters. Wiederverkäufer nennen gern die eigene Adresse in Deutschland, während die Maschine anderswo steht.

Prüfpunkt 5: IP-Reputation und die Nachbarschaft

Beim Shared Hosting teilen sich viele Websites eine IP-Adresse. Die Sorge, dass ein zwielichtiger Nachbar das eigene Ranking beschädigt, ist der Ursprung des gesamten Multi-IP-Produkts aus dem ersten Abschnitt.

Praktisch relevant wird eine belastete IP-Adresse zuerst an einer anderen Stelle: beim E-Mail-Versand. Steht die IP auf Sperrlisten, kommen Formularbenachrichtigungen und Bestellbestätigungen nicht mehr an, und das merkt man oft erst Wochen später. Trennen Sie deshalb Web- und Mailversand vertraglich, oder lassen Sie sich zusichern, dass der Versand über eine dedizierte, überwachte Infrastruktur läuft.

Für die reine Auslieferung der Website gilt: Eine eigene, dedizierte IP-Adresse ist ein günstiges Zusatzmerkmal, das Sie mitnehmen können, wenn es angeboten wird. Ein Argument, ein Multi-IP-Paket zu buchen, ist es nicht.

Zur IP-Schicht gehört auch das Zertifikat. Google hat HTTPS im August 2014 offiziell als Ranking-Signal bestätigt und es dabei als sehr leichtgewichtig beschrieben, das weniger als ein Prozent der globalen Suchanfragen betrifft. Als Rankingfaktor ist HTTPS damit vernachlässigbar. Als Betriebsvoraussetzung ist es Pflicht, und die Vertragsfrage lautet: Ist das Zertifikat im Preis enthalten, erneuert es sich automatisch, und wer haftet, wenn die Erneuerung fehlschlägt? Ein abgelaufenes Zertifikat macht eine Website für Besucher und Crawler gleichermaßen unbrauchbar.

Prüfpunkt 6: Server-Klasse

Die Tarifklasse entscheidet darüber, ob die Zahlen aus den Prüfpunkten 1 bis 3 überhaupt haltbar sind.

• Shared Hosting. Viele Kunden auf einer Maschine, Ressourcen werden geteilt. Der Preis ist niedrig, die Antwortzeit hängt von fremder Last ab. Fragen Sie nach garantierten statt nur maximalen Ressourcen und nach der Zahl paralleler Anfragen, die Ihr Tarif verarbeiten darf.
• Managed Server oder Managed Cloud. Feste Ressourcen, Betriebssystem und Updates bleiben beim Anbieter. Für die meisten Firmenprojekte der sinnvolle Punkt, weil hier belastbare Zusagen möglich sind, ohne dass Sie einen Administrator beschäftigen müssen.
• Root- oder dedizierter Server. Volle Kontrolle, volle Verantwortung. Ohne jemanden, der Sicherheitsupdates einspielt und Monitoring betreibt, ist das ein Rückschritt und keine Verbesserung.

Die entscheidende Vertragsfrage über alle Klassen hinweg: Was passiert bei Lastspitzen? Wird gedrosselt, wird abgewiesen, oder wird automatisch skaliert und nachberechnet? Alle drei Antworten sind vertretbar, aber Sie müssen wissen, welche gilt.

Der Umzug ohne Ranking-Verlust

Wenn die Prüfung ergibt, dass der aktuelle Anbieter die Zusagen nicht liefert, steht ein Umzug an. Entscheidend ist die Unterscheidung zweier Vorgänge, die oft vermischt werden.

Bei einem Umzug mit URL-Wechsel empfiehlt Google, die 301-Weiterleitungen mindestens ein Jahr lang bestehen zu lassen. Für einen reinen Server- oder IP-Wechsel ohne URL-Änderung dokumentiert Google ein eigenes, davon getrenntes Vorgehen. Das ist die gute Nachricht: Ein Hosterwechsel, bei dem sich keine einzige URL ändert, ist aus Suchmaschinensicht der harmlose Fall.

Halten Sie die beiden Vorgänge deshalb strikt getrennt. Wer Serverwechsel und Domain- oder Strukturänderung in dasselbe Wochenende legt, kann hinterher nicht mehr feststellen, welcher der beiden Schritte einen Einbruch verursacht hat.

Ablauf für den reinen Serverwechsel:

1. Vorher messen. Antwortzeiten, Statuscode-Verteilung und indexierte Seitenzahl dokumentieren. Ohne Ausgangswert gibt es später keinen Vergleich.
2. Zielsystem vollständig aufbauen und testen, erreichbar über eine temporäre Adresse, für Suchmaschinen gesperrt.
3. TTL der DNS-Einträge senken, mehrere Stunden vor dem Wechsel, damit die Umstellung schnell greift.
4. Altsystem parallel weiterlaufen lassen. Während der DNS-Umstellung erreichen Besucher und Crawler noch beide Systeme. Beide müssen dieselben Inhalte ausliefern.
5. Umstellen und sofort prüfen: Statuscodes, Zertifikat, robots.txt, Sitemap-Erreichbarkeit, Weiterleitung von www und nicht-www, Antwortzeit.
6. Crawling beobachten. In den Crawling-Statistiken der Search Console zeigt sich innerhalb weniger Tage, ob Antwortzeit und Fehlerquote am neuen Ort besser sind.
7. Altsystem erst abschalten, wenn die Logs des neuen Servers zeigen, dass dort tatsächlich alle Zugriffe ankommen.

Wann sich der Aufpreis rechnet

Die Preisspanne ist erheblich. Als Preisanker im deutschen Markt bewirbt webgo seinen seoService ab 11,95 Euro im Monat. SEO-Hosting-Pakete und reine Performance-Tarife liegen preislich deutlich auseinander. Die Frage ist also nicht, ob teurer besser ist, sondern ab wann der Aufpreis von seinem eigenen Effekt bezahlt wird.

Rechnen Sie mit Ihren eigenen Zahlen, und zwar in dieser Reihenfolge:

1. Wert eines Besuchs. Umsatz oder Deckungsbeitrag aus organischem Traffic im letzten Jahr, geteilt durch die Zahl organischer Besuche im selben Zeitraum.
2. Kosten eines Ausfalls. Diesen Wert mit den Besuchen multiplizieren, die in die erlaubte Ausfallzeit aus Prüfpunkt 2 fallen. Bei 43,2 Minuten sind das die Besuche einer knappen Dreiviertelstunde, gemessen zur Hauptzeit, nicht im Tagesdurchschnitt.
3. Jährliche Mehrkosten des besseren Tarifs. Monatlicher Aufpreis mal zwölf, zuzüglich einmaligem Migrationsaufwand.

Übersteigt Punkt 2 über das Jahr gerechnet Punkt 3, ist die Entscheidung getroffen, und zwar allein über Ausfallzeit, ohne dass ein einziger Rankingeffekt eingerechnet wurde. Bleibt sie darunter, prüfen Sie zusätzlich den Antwortzeit-Effekt: Ein Tarif, der Ihren TTFB verlässlich unter die 800-Millisekunden-Marke bringt, gibt dem gesamten Seitenaufbau Luft, die Sie sonst mühsam an anderer Stelle einsparen müssten.

Ein sinnvoller Zwischenschritt vor dem Upgrade ist immer eine Messperiode von vier Wochen mit sauberen Logs. Viele vermeintliche Hostingprobleme sind Anwendungsprobleme, und die wandern beim Umzug einfach mit.

Was nicht am Hosting liegt

Zur Ehrlichkeit dieses Prüfkatalogs gehört die Abgrenzung. Kein Tarifwechsel repariert Bilder ohne Komprimierung, blockierende Skripte, ein überladenes CMS oder ein schwaches Linkprofil. Diese Baustellen liegen hinter der Serverschicht und werden an anderer Stelle behandelt.

Was Sie beim Hoster einkaufen, ist ein schmales, aber hartes Bündel: eine Antwortzeit, eine Verfügbarkeit, ein definiertes Fehlerverhalten, einen Standort, eine saubere Adresse und eine Ressourcenklasse, die zu Ihrer Last passt. Genau diese sechs Punkte gehören in den Vertrag, mit Zahlen, mit Messpunkt und mit Nachweispflicht. Alles andere ist Marketing um eine Zeile in der Rechnung herum.