So nehmen Sie eine Website
vom Entwickler ab

So nutzen Sie diese Anleitung

Eine fertige Website kann überzeugend aussehen und trotzdem Anfragen verlieren, für Suchmaschinen gesperrt sein oder vom Konto eines früheren Dienstleisters abhängen. Nehmen Sie deshalb die funktionierende Website auf Ihrer Domain ab, nicht nur eine Projektpräsentation. Im Folgenden erfahren Sie, welches Tool Sie öffnen, was Sie eingeben, wie Sie das Ergebnis bewerten und welche Korrektur Sie anfordern.

Halten Sie Leistungsbeschreibung, freigegebene Entwürfe sowie die Liste der Seiten und Integrationen bereit. Dokumentieren Sie geprüfte Adresse, Datum und Version. Legen Sie eine Tabelle an: „Adresse / Szenario“, „Erwartetes Ergebnis“, „Tatsächliches Ergebnis“, „Nachweis“, „Verantwortlich“, „Status“. Nutzen Sie vier Statuswerte: geprüft, Fehler vorhanden, nicht geprüft, nicht anwendbar. Fehlender Kontozugriff bedeutet „nicht geprüft“, nicht „alles in Ordnung“.

Benötigte Tools

Übergeben Sie öffentlichen Tools nur normale, öffentlich zugängliche URLs. Seiten mit geheimen Anmeldelinks, personenbezogenen Daten oder Zahlungstokens prüfen Sie in der vereinbarten Umgebung. Schaltflächen können je nach Sprache und Version anders heißen; die Anleitung nennt die wichtigsten Orientierungspunkte.

Prüfen Sie, ob die Website tatsächlich an Sie übergeben wurde

Domain über WHOIS und das Registrar-Konto prüfen

1. Öffnen Sie WHOIS, geben Sie die Domain ohne Seitenpfad ein, beispielsweise example.ru, und starten Sie die Suche.
2. Suchen Sie Registrar und Ablaufdatum. Bei .ru-Domains kann das Datum im Feld paid-till stehen; bei anderen Endungen kann es anders heißen.
3. Melden Sie sich beim genannten Registrar mit dem Kundenkonto des Auftraggebers an. Prüfen Sie, ob die Domain aufgeführt ist, Verlängerung und DNS-Verwaltung möglich sind und der Wiederherstellungskontakt dem zuständigen Mitarbeiter gehört.
4. Gleichen Sie die Daten des Domaininhabers mit der vereinbarten Eigentumszuordnung ab. Ausgeblendete WHOIS-Daten sind normal: Der öffentliche Dienst ersetzt weder Konto- noch Dokumentenprüfung.

Erwartetes Ergebnis: Inhaber, nächster Zahlungstermin, Verlängerungsverfahren und die Person zur Wiederherstellung des Zugangs stehen fest. Der Dienstleister kann technisch weiter zuständig sein; das Projekt darf aber nicht von einem unbekannten Privatkonto abhängen.

Verzeichnis der übrigen Zugänge anlegen

Speichern Sie keine Passwörter in einer öffentlich zugänglichen Mängelliste. Ein Verweis auf einen sicheren Ablageort und der Name der zuständigen Person genügen. Beschränken Plattformbedingungen den Zugriff, halten Sie fest, was der Auftraggeber selbst erledigen kann und wofür Unterstützung nötig ist.

Weiterleitungen, Serverantworten und Zertifikat prüfen

Vier Domainvarianten in httpstatus.io

Eine Website lässt sich oft über HTTP oder HTTPS sowie mit oder ohne www aufrufen. Legen Sie die Hauptadresse fest, beispielsweise https://example.ru/. Öffnen Sie anschließend httpstatus.io und fügen Sie vier Zeilen in das Eingabefeld ein. Ersetzen Sie die Beispieldomain durch Ihre eigene:

http://example.ru/
http://www.example.ru/
https://example.ru/
https://www.example.ru/

Klicken Sie auf Check status. Klappen Sie die Ergebnisse auf und prüfen Sie die Statusfolge sowie die Zieladresse. Die Haupt-URL sollte 200 zurückgeben. Bei einer dauerhaften Zusammenführung führen alternative Adressen üblicherweise über 301 oder 308 zur Hauptadresse mit HTTPS, die mit 200 antwortet. Wiederholen Sie die Prüfung mit einer Unterseite: Der Pfad muss erhalten bleiben.

Speichern Sie den Bericht und senden Sie dem Entwickler Ausgangs-URL, vollständige Kette und erwartete Zieladresse. Eine vorübergehende Weiterleitung mit 302 ist nicht immer falsch: Klären Sie ihren Zweck. Problematisch sind ein Widerspruch zur Anforderung, eine Schleife oder der Verlust der Seite.

Liefert die 404-Seite wirklich den Status 404?

Ergänzen Sie Ihre Domain um einen sicher nicht vorhandenen Pfad, zum Beispiel /proverka-priemki-ne-sushchestvuet-8472/. Öffnen Sie ihn im Browser und prüfen Sie ihn mit demselben Tool. Erwartet werden eine verständliche Seite mit Navigation und der Statuscode 404. Steht dort „Seite nicht gefunden“, der Server liefert aber 200, wird fälschlich Erfolg gemeldet. Für eine absichtlich entfernte Ressource ist auch dieser Status möglich: 410.

HTTPS mit SSL Labs prüfen

1. Öffnen Sie SSL Server Test. Im Feld Hostname geben Sie die Domain ohne https:// und ohne Pfad ein.
2. Aktivieren Sie bei Bedarf Do not show the results on the boards, starten Sie den Test und warten Sie auf das Ergebnis.
3. Prüfen Sie Ablaufdatum, Domainübereinstimmung und Meldungen zum Vertrauen in die Zertifikatskette. Senden Sie Protokollhinweise mit dem Berichtslink an den Serveradministrator.

Die Website muss im normalen Browser ohne Warnung vor einem ungültigen Zertifikat öffnen. Prüfen Sie auch Bilder, Schriften und Skripte: HTTPS für die Seite korrigiert keine Ressourcenlinks über HTTP. Die SSL-Labs-Note bewertet die TLS-Konfiguration, nicht die gesamte Sicherheit der Website.

Prüfen Sie, ob Suchmaschinen ausgeschlossen werden

Schritt 1. robots.txt öffnen

Geben Sie im Browser Folgendes ein: https://example.com/robots.txt Suchen Sie die Gruppe für User-agent: * und gegebenenfalls eigene Regeln für Googlebot und Yandex. Dieses Zeilenpaar verbietet dem betreffenden Bot das gesamte Crawling:

User-agent: *
Disallow: /

Bei einer veröffentlichten Website ist dies Anlass, die Einstellungen zu prüfen. Entfernen Sie aber nicht wahllos alle Regeln: Kundenkonto, Warenkorb und technische URLs können bewusst gesperrt sein. Maßgeblich ist das Zusammenspiel von Gruppen, Regeln und konkreter URL.

Öffnen Sie Yandex Webmaster → Tools → Robots.txt analysis (robots.txt-Analyse) und geben Sie die Websiteadresse ein. Prüfen Sie nach dem Laden die Freigabe für Startseite, Leistungsseite, Artikel und weitere wichtige URLs. Ist eine benötigte Seite gesperrt, sichern Sie URL und auslösende Regel. Das Vorgehen erläutert die Hilfeseite des Tools.

Schritt 2. noindex in Seite und Headern suchen

Öffnen Sie über das Browsermenü den Seitenquelltext. Suchen Sie nach name="robots", name="googlebot" und noindex. Entscheidend ist ein tatsächlicher Meta-Tag innerhalb von <head>, beispielsweise:

<meta name="robots" content="noindex, nofollow">

In einem Artikel wie diesem kann das Wort noindex in einem Lehrbeispiel stehen, ohne eine aktive Sperre zu sein. Prüfen Sie zusätzlich die Antwortheader in httpstatus.io: Die Anweisung kann auch so übertragen werden: X-Robots-Tag: noindex. Prüfen Sie in WordPress auch „Einstellungen → Lesen“ und die Option, Suchmaschinen von der Indexierung abzuhalten. Auch SEO-Plugins können Einschränkungen hinzufügen.

Erwartetes Ergebnis: Für die Suche bestimmte Seiten haben keine versehentliche Indexierungssperre. Google muss die Seite abrufen können, um noindex zu lesen; eine Crawling-Sperre in robots.txt ersetzt diese Anweisung nicht. Den Unterschied erläutert die Google-Dokumentation.

Schritt 3. XML-Sitemap prüfen

Entnehmen Sie die Sitemap-Adresse der Zeile Sitemap: in robots.txt oder erfragen Sie sie beim Entwickler. Die Datei kann sitemap.xml, sitemap_index.xml oder anders heißen. Öffnen Sie sie; enthält sie weitere Sitemaps, öffnen Sie die für Seiten, Produkte und Artikel. Prüfen Sie, ob die URLs zur produktiven Domain und deren Haupt-HTTPS-Variante gehören, nicht zur Testumgebung.

Öffnen Sie URLs aus jedem Bereich. Weiterleitungen, gelöschte Seiten oder noindex-Seiten dürfen nicht versehentlich enthalten sein. Vergleichen Sie die vollständige Liste mit dem vereinbarten Seitenverzeichnis: Eine erreichbare Sitemap beweist keine Vollständigkeit. Verwenden Sie in Yandex Webmaster Tools → Sitemap validator (Sitemap-Prüfung), fügen Sie den Link ein und analysieren Sie Fehler. Dazu gibt es eine offizielle Anleitung.

Schritt 4. Seite in Google Search Console prüfen

1. In Search Console wählen Sie die bestätigte Property Ihrer Website aus.
2. Fügen Sie die vollständige URL einer wichtigen Seite oben in das URL-Prüffeld ein.
3. Unterscheiden Sie gespeicherte Indexdaten von einer Prüfung der aktuellen Seite. Klicken Sie auf Live-URL testen / Test Live URL, um die aktuelle Antwort zu prüfen.
4. Öffnen Sie die Angaben zu Crawling und Indexierung. Bei einer Sperre oder einem Abruffehler nennen Sie dem Entwickler die konkrete Ursache. Wiederholen Sie nach der Korrektur den Live-Test.

Ein erfolgreicher Live-Test zeigt die technische Eignung für die Suche, garantiert aber weder sofortige Indexierung noch gute Platzierungen. Die Unterschiede beschreibt die Google-Hilfe. Nutzen Sie für Yandex zusätzlich die Serverantwortprüfung in Webmaster und die Indexierungsberichte.

Defekte Links, Duplikate und Markup-Fehler finden

Crawl mit Screaming Frog starten

1. Installieren Sie SEO Spider von der offiziellen Website. Fügen Sie die Startseiten-URL in das Feld Enter URL to spider und klicken Sie auf Start.
2. Warten Sie auf das Ende des Crawls. Wird das Limit von 500 URLs der kostenlosen Version erreicht, ist der Bericht nicht vollständig. Für größere Projekte benötigen Sie ein Tool ohne diese Begrenzung.
3. Öffnen Sie den Reiter Response Codes und suchen Sie nach 4xx- und 5xx-Antworten. Wählen Sie eine betroffene URL und prüfen Sie Inlinks, um die darauf verlinkenden Seiten zu finden.
4. Exportieren Sie die Ergebnisse und übermitteln Sie Paare aus „verlinkender Seite → defektem Link“ an den Dienstleister.

Ein linkbasierter Crawl findet nicht zwingend jede Seite: Eine verwaiste Seite ohne eingehende Links kann unentdeckt bleiben. Vergleichen Sie den Export mit Sitemap, CMS-Verzeichnis und vereinbarter Struktur. Klären Sie bei skriptgenerierten Inhalten den Rendering-Modus. Einstellungen und Grenzen beschreibt die Anleitung für den ersten Crawl.

Was Sie in den Ergebnissen prüfen sollten

Namen und Aufgaben der Reiter finden Sie im SEO-Spider-Handbuch. Eine automatische Markierung ist Anlass, die Seite zu prüfen. Identische Titles bei einem bewussten Duplikat und bei zehn unterschiedlichen Leistungen erfordern verschiedene Entscheidungen.

Strukturierte Daten prüfen

Öffnen Sie Rich Results Test, wählen Sie den URL-Test, fügen Sie die Adresse ein und starten Sie die Prüfung. Öffnen Sie den erkannten Typ und die Fehler. Das Tool prüft von Google unterstützte Rich Results: Ein fehlendes geeignetes Ergebnis bedeutet nicht, dass jedes Schema.org-Markup falsch ist.

Öffnen Sie ergänzend Schema Markup Validator und prüfen Sie dieselbe URL. Gleichen Sie Titel, Autor, Organisation, Bild, URL und Datum mit dem Inhalt ab. Ein Artikel braucht eine passende Illustration, eine Leistung aktuelle Angaben. Ein grünes Prüfergebnis erkennt weder einen erfundenen Autor noch ein themenfremdes Foto, wenn der Code formal korrekt ist.

Prüfen Sie außerdem die Linkvorschau im Messenger und die Metadaten og:title, og:description, og:image. Derselbe alte Banner für alle Beiträge ist Anlass, seitenspezifische Bilder einzurichten. Beachten Sie den Messenger-Cache: Er kann nach einer Korrektur noch die alte Vorschau zeigen.

Texte und Bilder manuell prüfen

Gleichen Sie Preise, Unternehmensangaben, Telefon, E-Mail, Namen, Beschriftungen und Schaltflächen mit den tatsächlichen Daten ab. Öffnen Sie verschiedene Branchenseiten: In wiederverwendeten Vorlagen bleiben leicht fremde Überschriften oder unpassende Bildschirmansichten zurück. Das Handy-Mockup einer Autowerkstatt darf keine Massagen anbieten. Prüfen Sie Dokument- und Dateilinks: Ein richtiger Buttontext garantiert nicht die richtige Datei.

Für die Suche nach HTML-Fehlern eignet sich Nu Html Checker: Geben Sie die URL ein und analysieren Sie die Strukturfehler. Der Entwickler muss deren Auswirkungen bewerten; eine Warnungszahl ersetzt keine Websiteprüfung. Eine umfassende Prüfung der Sucheinstellungen gehört zu einem technischen SEO-Audit.

Oberfläche auf verschiedenen Bildschirmen prüfen

Vergleichen Sie Blockreihenfolge, Schriften, Farben, Bilder und Buttontexte mit den freigegebenen Entwürfen. Prüfen Sie auch Zustände, die im schönen Mockup fehlen können: lange Überschrift, leere Suche, offenes Menü, Formularfehler und eingeblendete Handytastatur.

Schneller Breitentest in Chrome

1. Öffnen Sie die Seite und anschließend die Entwicklertools über das Browsermenü oder mit F12.
2. Aktivieren Sie die Geräteleiste über das Symbol mit Telefon und Tablet. Im Modus Responsive können Sie die Breite manuell einstellen.
3. Prüfen Sie zunächst 320, 390, 768 und 1440 Pixel. Das sind praktische Testbreiten, keine vollständige Liste aller Geräte.
4. Scrollen Sie bei jeder Breite durch die gesamte Seite und öffnen Sie Menüs, Tabellen, Tabs und Formulare. Notieren Sie URL, Breite und einen Screenshot des Problems.

Device Mode hilft bei der Prüfung responsiver Darstellung, bildet ein physisches Telefon aber nicht vollständig nach. Wiederholen Sie den Hauptablauf auf einem echten Android-Gerät und iPhone, sofern diese zur Zielgruppe gehören.

Was als Mangel zählt

• Die gesamte Seite verschiebt sich seitlich, eine Überschrift ist abgeschnitten oder ein Button ragt aus dem Bildschirm. Eine breite Tabelle darf separat horizontal scrollen, ohne die gesamte Seite zu verbreitern.
• Ein wichtiges Bild oder Textteil verschwindet auf Mobilgeräten, ohne dass dies vereinbart wurde.
• Ein geöffnetes Menü lässt sich nicht schließen, eine lange Liste nicht scrollen oder die Seite nicht wieder erreichen.
• Die Tastatur verdeckt Eingabefeld und Button, ohne dass sie erreichbar bleiben.
• Der Telefonlink wählt eine falsche Nummer, der E-Mail-Link ist fehlerhaft oder die Erfolgsmeldung ist unlesbar.

Navigieren Sie außerdem durch die Bedienelemente mit Tab. Der Fokus muss sichtbar sein, Buttons und Felder müssen erreichbar sein und Fehler textlich erklärt werden. Prüfen Sie bei 200 % Browserzoom, ob Inhalt und Hauptaktion nutzbar bleiben. Vereinbarte Barrierefreiheitsanforderungen prüfen Sie mit einer eigenen Liste.

Prüfen Sie, ob die Anfrage beim Empfänger ankommt

Eine Dankesmeldung belegt nur, dass eine Meldung angezeigt wurde. Die Formularabnahme endet dort, wo ein Mitarbeiter die Anfrage bearbeitet: im E-Mail-Postfach, CRM oder Bestellsystem. Informieren Sie den Verantwortlichen vorab, damit der Test nicht als echte Kundenanfrage behandelt wird.

Jedes Formular Schritt für Schritt prüfen

1. Listen Sie alle Formulartypen auf: Anfrage am Seitenende, Rückruf, Popup, Briefing und Datei-Upload. Gleich aussehende Formulare können unterschiedliche Handler nutzen.
2. Öffnen Sie die gewünschte Seite. Für den Herkunftstest können Sie vereinbarte Testparameter hinzufügen: ?utm_source=acceptance&utm_medium=test&utm_campaign=site_handover.
3. Verwenden Sie eine erkennbare Kennzeichnung, etwa „ABNAHMETEST — Leistungsformular — 14:35“, und Ihre vereinbarten Kontaktdaten. Geben Sie in jedes Feld einen eigenen Wert ein, damit Datenverluste auffallen.
4. Senden Sie das Formular einmal ab. Notieren Sie Uhrzeit und Bildschirmergebnis.
5. Suchen Sie die E-Mail im Posteingang und prüfen Sie Spam. Ist eine Speicherung im CMS vorgesehen, suchen Sie dort den Eintrag. Prüfen Sie im CRM Datensatz, Pipeline, Zuständigkeit, Telefon, Kommentar und Quelle.
6. Vergleichen Sie die Daten mit der Eingabe. Anhänge müssen sich öffnen lassen, Links zu den richtigen Inhalten führen und Kampagnenparameter in den vorgesehenen Feldern landen.

Erwartetes Ergebnis: Die Anfrage ist gespeichert und über den vereinbarten Weg zugestellt, alle Felder sind erhalten und ihre Herkunft ist erkennbar. Fehlt die E-Mail trotz CMS-Eintrag, sind das unterschiedliche Ergebnisse: Speicherung erfolgreich, Benachrichtigung nicht bestätigt.

Fehler und erneutes Absenden testen

Shop, Zahlung und Kundenkonto

Prüfen Sie im Shop Preis, Menge, Rabatt, Versand, Gesamtsumme und Bestand. Vereinbaren Sie den Testmodus des Zahlungsanbieters: erfolgreiche Zahlung, Ablehnung, Abbruch, Rückkehr zur Website und Statuswechsel. Testen Sie keine echten Abbuchungen mit irgendeiner Karte. Kennung, Betrag und Status müssen in Bestellung und Zahlungssystem übereinstimmen.

Legen Sie zwei Testkonten mit unterschiedlichen Rollen an. Prüfen Sie Anmeldung, Abmeldung, Wiederherstellung und erlaubte Aktionen. Nutzer dürfen über eine URL keine fremden Bestellungen oder Dokumente sehen. Verwenden Sie ausschließlich vereinbarte Testdaten. Fehler bei Feldübertragung und Anfragezuordnung klären Sie mit einem Spezialisten für CRM-Integration.

Metrica-Ziele nach einer tatsächlichen Aktion prüfen

Melden Sie sich zunächst bei Yandex Metrica mit dem Konto des Auftraggebers an. Prüfen Sie Domain und Zähler-ID sowie Zugriff auf Einstellungen und benötigte Berichte. Fordern Sie die Zielliste an: Was zählt als Anfrage, Telefonklick, Download oder Kauf?

Debugger aktivieren

1. Öffnen Sie die Seite mit dem Parameter ?_ym_debug=2. Enthält die URL bereits ein Fragezeichen, ergänzen Sie &_ym_debug=2.
2. Führen Sie die Zielaktion aus und öffnen Sie das Debug-Panel unten auf der Seite.
3. Prüfen Sie in den Reitern Events und Console die Zähler-ID und das Ereignis. Gleichen Sie diese mit dem vereinbarten Ziel ab.
4. Suchen Sie die Zielerreichung anschließend im Bericht. Berücksichtigen Sie Aktualisierungsverzögerungen und Filter für eigene Besuche.

Der Modus _ym_debug=2 ist für den neuen Zählercode vorgesehen. Erscheint das Panel nicht, nutzen Sie die von Yandex beschriebene Alternative mit _ym_debug=1 und der Browserkonsole. Genaue Schritte und Ursachen für fehlende Ereignisse stehen in der offiziellen Anleitung zur Zielprüfung.

Falsch konfigurierte Ziele erkennen

Vergleichen Sie drei Aktionen: Formular öffnen, mit leeren Feldern absenden und ausgefülltes Formular erfolgreich senden. Erhöhen alle drei das Ziel „Anfrage eingegangen“, wird das Ergebnis überhöht. Ein eigenes Ziel „Buttonklick“ darf Klicks erfassen; benennen Sie es korrekt und stellen Sie es nicht als eingegangene Anfrage dar.

Sichern Sie Testzeit, Zielname, Ereignis-Screenshot und eingegangene Anfrage. Laden Sie nach erfolgreichem Versand neu: Ohne neue Anfrage darf das Ereignis nicht erneut auftreten, sofern dies nicht ausdrücklich vorgesehen ist. Gleichen Sie bei Google Analytics 4 ebenso Debug- oder Echtzeitereignisse mit der tatsächlichen Aktion ab; Konto und Rechte gehören ebenfalls zur Übergabe.

PageSpeed prüfen und Verbesserungen ableiten

Jede URL einzeln testen

1. Öffnen Sie PageSpeed Insights, fügen Sie die vollständige URL ein und starten Sie die Analyse.
2. Warten Sie auf den Bericht. Prüfen Sie Mobilgeräte und Desktop: Bewertungen und Testbedingungen unterscheiden sich.
3. Speichern Sie Berichtslink, Datum, URL und Gerät. Dokumentieren Sie bei Wiederholungen die Änderungen zwischen den Läufen.
4. Sehen Sie zuerst verfügbare reale Nutzerdaten an, dann die Labordiagnose. Prüfen Sie, ob sich die Nutzerdaten auf diese URL oder den gesamten Ursprung beziehen.
5. Öffnen Sie die Empfehlungen und ermitteln Sie konkrete Bilder, Skripte, Schriften oder Anfragen. Senden Sie deren URLs und Problembeschreibung mit dem Bericht an den Entwickler.

Umfasst die Abnahme alle Seiten, führen Sie ein Verzeichnis aller URLs mit jeweils zwei Berichten. Startseite, eine Leistung und ein Artikel helfen, Vorlagenfehler zu finden, bestätigen aber nicht die übrigen Seiten.

Core-Web-Vitals-Grenzwerte gelten für das 75. Perzentil realer Besuche, getrennt nach Gerätetyp. Bei neuen oder wenig besuchten Websites können Daten fehlen. Das bedeutet weder Geschwindigkeit null noch automatisch ein Durchfallen. Definitionen und Bedingungen stehen in der Web-Vitals-Dokumentation.

Beispiel einer Berichtsauswertung

Anderes Beispiel: Hoher CLS, weil ein Bild beim Laden Text verschiebt. Lassen Sie Platz durch Abmessungen oder Seitenverhältnis reservieren und prüfen Sie erneut. Bei langsamer Serverantwort sind Server, Cache und Anwendung zu untersuchen. Ein einzelner Zeitwert beweist keine Schuld von Datenbank oder Hosting.

Muss es unbedingt 100 sein?

Der Lighthouse-Wert stammt aus einem bestimmten Labordurchlauf und hängt von den Messbedingungen ab. Berechnung und Schwankungen erklärt Google in der Dokumentation zur Leistungsbewertung. Steht 100 in den Anforderungen, dokumentieren Sie Kennzahl, Gerät und Bedingungen und prüfen Sie das reale Ergebnis. Ein Screenshot belegt nicht „100 auf der gesamten Website“.

Prüfen Sie nach der Optimierung Anfragen, Menü, Analyse und mobile Darstellung erneut. Entfernte Bilder oder abgeschaltete benötigte Tracker zugunsten der Punktzahl sind Funktionsänderungen und brauchen eine eigene Entscheidung. Auch Barrierefreiheit, SEO und Best Practices sind nützlich, decken aber nicht alle Abnahmeanforderungen ab.

Backup durch Wiederherstellung prüfen

Lassen Sie Datum, Inhalt, Speicherort, Häufigkeit und Aufbewahrung der letzten Sicherung zeigen. Bei Websites mit Datenbank reicht ein einzelner Ordner meist nicht: Benötigt werden Datenbank, Dateien, Uploads und Einstellungen. Klären Sie bei Baukästen das Wiederherstellungsverfahren und seine Grenzen.

Kontrollierter Wiederherstellungstest

1. Wählen Sie eine konkrete Sicherung und notieren Sie ihr Datum. Klären Sie den erwarteten Wiederherstellungsumfang.
2. Lassen Sie sie in einer isolierten Testumgebung wiederherstellen. Ersetzen Sie die produktive Website nicht für ein Experiment.
3. Deaktivieren Sie vor dem Start echte Zahlungen, Aussendungen, Benachrichtigungen und externe Aktionen. Schützen Sie die Testumgebung mit geeigneten Mitteln vor fremdem Zugriff und Suchrobotern.
4. Öffnen Sie Seiten, melden Sie sich im CMS an und prüfen Sie Bilder, Daten und Hauptablauf mit Testempfängern.
5. Dokumentieren Sie Dauer, fehlende Teile und Anleitung. Der Verantwortliche muss die Sicherung auch bei Verlust des Hauptservers erreichen können.

Erwartetes Ergebnis: Die wiederherstellbare Version und der Zeitbedarf sind bekannt; die Wiederherstellung wurde tatsächlich ausgeführt. „Der Hoster sichert alles“ bleibt ohne Test unbestätigt.

Grundlegende Sicherheitsprüfung bei Übergabe

Ordnen Sie CMS-Nutzer Verantwortlichen zu und prüfen Sie unnötige Testkonten sowie Dienstleisterrechte. Klären Sie Updates von CMS und Erweiterungen. Sicherungen und Konfigurationsdateien dürfen nicht öffentlich verlinkt sein; Testdaten dürfen nicht im Produktivsystem landen. WordPress bietet offizielle Sicherheitsempfehlungen.

Diese Schritte ersetzen kein vollständiges Sicherheitsaudit. Komplexe Kundenbereiche, Zahlungen oder sensible Daten brauchen einen gesondert vereinbarten Testumfang. Sicherungen und regelmäßige Updates benötigen klare Zuständigkeit im Rahmen der technischen Betreuung.

Prüfen Sie, ob Sie die Website selbst pflegen können

Fordern Sie eine Anleitung an und erledigen Sie ohne Entwicklerhilfe eine typische Aufgabe: Artikelentwurf, Bild mit Alt-Text, Suchtitel, interner Link und Vorschau. Ändern Sie anschließend einen Preis in einem Testeintrag und setzen Sie ihn zurück. Nutzen Sie zum Üben nicht die öffentliche Startseite.

Erfordert eine wichtige Aktion manuelle Codeänderungen, muss das als Projektgrenze bekannt sein und darf nach der Übergabe nicht überraschen. Die Anleitung muss zur tatsächlichen Verwaltung, Redakteursrolle und aktuellen Version passen.

• Vereinbarte Quelltexte, Entwürfe, Lizenzen und Materialien übernehmen.
• Verfahren für Veröffentlichung, Rücknahme und Abhängigkeitsupdates dokumentieren.
• Verantwortliche für Domain, Hosting, Sicherungen und Störungsmeldungen bestimmen.
• Supportkanal, vereinbarte Reaktionszeiten und Betreuungsumfang festhalten.
• Gleichen Sie die Übergabe mit dem Vertrag ab: Eine technische Checkliste allein regelt weder Zahlung noch Gewährleistung oder rechtliche Folgen unterschriebener Dokumente.

Fehler melden und Korrekturen prüfen

Jede Meldung sollte ein reproduzierbares Problem beschreiben. Nennen Sie statt „Website langsam“ URL, Gerät, Zeitpunkt und Bericht. Beschreiben Sie statt „Formular kaputt“ die Schritte und den Zielort, an dem die Anfrage fehlt. So kann der Entwickler den Fehler nachstellen und der Auftraggeber das Ergebnis prüfen.

Prioritäten der Korrekturen

Verhindert den Start: Hauptablauf funktioniert nicht, Bestellungen gehen verloren, vereinbarte Zugänge fehlen, fremde Daten werden offengelegt oder wichtige Seiten sind unerreichbar. Vor Abschluss der Abnahme beheben: Falsche Sucheinstellungen, zahlreiche defekte Links und kritische mobile Mängel. Geplante Nachbesserung: Kleine optische Abweichung ohne Inhalts- oder Funktionsverlust. Stimmen Sie die Priorität auf Geschäftsauswirkungen und Projektanforderungen ab.

Wiederholen Sie nach „behoben“ die ursprünglichen Schritte in der aktualisierten Version. Sichern Sie neue Nachweise, Datum und Ergebnis. Prüfen Sie bei Vorlagenfehlern alle betroffenen URLs automatisch und verschiedene Zustände manuell. Eine korrigierte Karte beweist keinen fehlerfreien Gesamtkatalog.

Dokumentieren Sie, was geprüft, behoben oder offen ist, wer verantwortlich ist und welche Frist gilt. Erstellen Sie Abschlussunterlagen entsprechend Ihrem Vertrag.

Checkliste vor Abschluss der Abnahme

Haken Sie Punkte erst nach Prüfung ab. Diese Häkchen sind nur vorübergehend und werden beim Neuladen zurückgesetzt. Übertragen Sie Ergebnisse und Nachweislinks in Ihr Protokoll.

Häufige Fragen zur Website-Abnahme