Alle Artikel

Die Website eines Kunden übernehmen: Was Sie vor dem Angebot prüfen

Eine Checkliste für Agenturen und Freelancer, die eine Website von einem anderen Entwickler übernehmen: was Sie von außen und im Backend prüfen und wie Sie aus den Befunden ein Angebot machen, das der Kunde versteht.

Radek, ENSOMEDIAVeröffentlicht 7 Min. LesezeitIn EnglishPo polskuEn españolEn français中文بالعربية

Ein neuer Kunde hat sich von seinem bisherigen Entwickler getrennt und sucht jemanden, der die Website übernimmt. Er fragt, was die monatliche Wartung kostet. Es ist verlockend, mit Ihrem Standardsatz zu antworten. Das Problem: Sie wissen noch nicht, worauf Sie sich einlassen.

Eine Website, die den Besitzer gewechselt hat, kann Dutzende Plugins mitbringen, manche davon lange nicht angefasst, einen Datenbank-Dump in einem öffentlichen Ordner und ein Administratorkonto von jemandem, an den sich niemand erinnert. Kalkulieren Sie sie wie eine gepflegte Website, sind Ihre ersten Wochen Wartung unbezahlt. Und ist die Website bereits kompromittiert, sieht es ab dem Tag der Übernahme nach Ihrem Problem aus.

Im Folgenden eine Checkliste in zwei Teilen: was Sie von außen prüfen können, bevor der Kunde Ihnen Passwörter gibt, und was Sie sich im Backend ansehen, sobald er es tut. Am Ende, wie Sie aus den Befunden ein Angebot machen.

Holen Sie zuerst die Zustimmung des Kunden ein

Eine Website so anzusehen, wie es jeder Besucher tut, braucht niemandes Erlaubnis. Scan-Tools darauf loszulassen ist etwas anderes: Der Hoster oder der bisherige Entwickler reagiert womöglich schlecht auf Datenverkehr, mit dem er nicht gerechnet hat. Eine Zeile vom Kunden per E-Mail, „Ich bin einverstanden, dass Sie die Website vor dem Angebot prüfen“, sichert Sie ab.

Von außen, ohne Passwörter

All das können Sie vor dem ersten Treffen erledigen. Es dauert etwa eine halbe Stunde und reicht oft, um zu erkennen, ob das ein Standardangebot wird.

Zertifikat und Weiterleitungen. Läuft die Website nur über HTTPS? Landen http:// sowie die Versionen mit und ohne www alle auf einer sicheren Adresse? Wann läuft das Zertifikat ab, und akzeptiert der Server noch die ausgemusterten Versionen TLS 1.0 und 1.1? Der SSL certificate checker (auf Englisch) beantwortet das alles in Sekunden.

E-Mail auf der Domain. Die Einträge MX, SPF, DKIM und DMARC. Kein DMARC oder DMARC mit p=none ist eine Position für Ihr Angebot und ein Hinweis, dass sich schon länger niemand das DNS angesehen hat. Notieren Sie auch, wo die E-Mails des Kunden liegen, denn jede DNS-Änderung, die Sie später vornehmen, muss darauf Rücksicht nehmen. Der SPF, DKIM and DMARC check (auf Englisch) zeigt den aktuellen Stand.

Plattform und Versionen. Worauf die Website läuft, in welcher Version, welche Plugins im Seitencode auftauchen und ob sie ihre Versionsnummern verraten. Das Meta-Tag generator und die Parameter ?ver= an Skript-URLs sagen viel. Gleichen Sie das Gefundene mit einer Schwachstellendatenbank wie WPScan oder Patchstack ab.

Dateien, die nicht öffentlich sein sollten. backup.zip, .sql-Dumps, wp-config.php.bak, ein Ordner .git, eine Datei .env, phpinfo.php. Raten Sie die Adressen nicht von Hand, ein Tool prüft sie schneller und gründlicher. Finden Sie etwas, laden Sie es nicht herunter. Notieren Sie die Adresse und sagen Sie es dem Kunden sofort. Die vergessene Sicherung auf dem Server erklärt, warum das nicht warten kann.

Formulare. Wird jedes Formular über HTTPS abgeschickt, gibt es Spamschutz, und steht ein Datenschutzhinweis daneben? Schicken Sie eine Testanfrage und fragen Sie den Kunden, ob sie angekommen ist und in welchem Postfach. Es kommt vor, dass ein Kontaktformular seit Monaten Anfragen an die Adresse eines ehemaligen Mitarbeiters schickt.

Header und Subdomains. Fehlende Sicherheitsheader zu ergänzen ist meist eine kleine Aufgabe, gehört aber ins Angebot. Vergessene Subdomains wie test. oder old. können riskanter sein als die Hauptseite, weil sie niemand aktualisiert.

Anzeichen eines Hacks. Suchen Sie bei Google nach site:kundendomain.de und scrollen Sie durch die Ergebnisse. Seiten auf Japanisch oder über Apotheken oder Casinos bedeuten, dass Sie mit einer Bereinigung beginnen, nicht mit der Wartung.

Im Backend, sobald Sie Zugang haben

Sicherungen. Wo sie liegen, wie oft sie laufen, wie weit sie zurückreichen und wer darauf zugreifen kann. Fragen Sie, ob die Website schon einmal aus einer Sicherung wiederhergestellt wurde. Bevor Sie etwas ändern, erstellen Sie eine eigene vollständige Sicherung und legen Sie sie außerhalb des Servers ab. Sie ist Ihre Versicherung, falls sich zeigt, dass etwas schon vor Ihrer Zeit kaputt war.

Administratorkonten. Gehen Sie jeden Benutzer mit der Rolle Administrator durch. Konten der bisherigen Agentur, ehemaliger Mitarbeiter oder von Personen, die niemand kennt, werden entfernt, sobald der Kunde zustimmt. Behandeln Sie ein Konto, das niemand erklären kann, als mögliches Zeichen einer Kompromittierung, nicht als Unordnung.

Plugins und Theme. Zählen Sie die Plugins und notieren Sie, welche auf Updates warten, welche deaktiviert sind und welche lange keine neue Version bekommen haben. Prüfen Sie die Lizenzen der kostenpflichtigen Plugins: auf wessen Namen sie laufen und ob sie abgelaufen sind. Ein Premium-Plugin ohne Lizenz bekommt keine Updates, und eine Kopie „aus inoffizieller Quelle“ kann zusätzlichen Code enthalten. Sehen Sie nach, ob das Theme direkt bearbeitet wurde statt über ein Child-Theme, denn das nächste Update löscht diese Änderungen. Veraltete WordPress-Plugins beschreibt, was Sie zuerst aktualisieren und was Sie löschen.

PHP-Version und Umgebung. Die Seite Website-Zustand unter Werkzeuge zeigt die Versionen von PHP und Datenbank sowie die Warnungen von WordPress selbst. Eine alte PHP-Version blockiert oft jedes andere Update und bestimmt damit die Reihenfolge der Arbeit.

Hosting, Domain und DNS. Diesen Punkt schiebt man leicht auf, und dann blockiert er alles. Klären Sie, auf wessen Namen die Domain registriert ist und wer sich beim Registrar anmelden kann, auf wessen Konto das Hosting läuft und wer es bezahlt, und wer das DNS ändern kann. Idealerweise gehört alles dem Kunden, und Sie bekommen einen eigenen Zugang, nicht den des bisherigen Entwicklers. Ist die Domain auf die alte Agentur registriert, starten Sie den Transfer, bevor Sie eine Migration planen.

Formulare von innen. Wohin die Einsendungen gehen, ob sie in der Datenbank gespeichert werden und wie lange. Jahre alter Anfragen voller personenbezogener Daten sind eine DSGVO-Frage für den Kunden, nehmen Sie sie also in Ihren Bericht auf, auch wenn die Entscheidung nicht bei Ihnen liegt.

Aus den Befunden ein Angebot machen

Der Kunde sieht den Unterschied zwischen einer gepflegten und einer vernachlässigten Website nicht. Im Browser sehen beide gleich aus. Steht in Ihrem Angebot eine einzige Summe für „Übernahme der Website“ und ist die eines Mitbewerbers niedriger, nimmt der Kunde die niedrigere. Sie müssen zeigen, woher der Unterschied kommt.

Teilen Sie das Angebot in drei Teile:

  1. Ist-Zustand. Eine kurze Liste dessen, was Sie gefunden haben, mit dem Datum der Prüfung. Drei Sätze pro Punkt: was falsch ist, was es das Unternehmen kosten kann, was zu tun ist. Kein Fachjargon. Statt „kein DMARC“ schreiben Sie „jeder kann E-Mails senden, die aussehen, als kämen sie von Ihrem Unternehmen, auch gefälschte Rechnungen“.
  2. Erstbereinigung. Einmalige Arbeiten, die sich aus dem Ist-Zustand ergeben, jede mit eigenem Preis oder Zeitaufwand. Der Kunde sieht genau, wofür er zahlt, und kann Prioritäten setzen, wenn das Budget knapp ist. Markieren Sie dringende Punkte, etwa einen öffentlich sichtbaren Datenbank-Dump, als Bedingung für die Übernahme.
  3. Monatliche Wartung. Eine feste Gebühr dafür, die Website in dem Zustand zu halten, in den Sie sie gebracht haben.

Ergänzen Sie einen Satz zur Verantwortung: Ihre Wartung umfasst die Website ab dem Übergabedatum, und die unter Ist-Zustand aufgeführten Probleme gehen erst auf Sie über, wenn sie behoben sind. Lassen Sie die Formulierung für Ihren Markt von einem Anwalt prüfen, das Prinzip schützt aber beide Seiten. Der Kunde weiß, wofür er zahlt, und Sie haften nicht für die Versäumnisse anderer.

Bewahren Sie die Belege vom Tag der Prüfung auf: den Bericht, Screenshots, die Liste der Konten und Plugins. Taucht drei Monate später eine Infektion aus der Zeit vor Ihnen auf, können Sie das belegen.

Ein Bericht, den der Kunde selbst lesen kann

Eine Liste im Angebot wirkt besser, wenn der Kunde sie an einen Geschäftspartner oder seinen Steuerberater weiterleiten kann, ohne Sie zum Übersetzen anzurufen. Deshalb lohnt es sich, dem Angebot einen Prüfbericht unter Ihrer eigenen Marke beizulegen.

ShieldWave übernimmt die äußere Hälfte dieser Checkliste. Es prüft die Website ohne Plugin und ohne Passwörter, und im Enterprise-Tarif trägt der Bericht das Logo und die Daten Ihrer Agentur. Der Kunde bekommt jedes Problem ohne Fachjargon erklärt und einen nach Dringlichkeit geordneten Plan zur Behebung. Sie bekommen die Befunde mit Adressen, Belegen und geschätztem Arbeitsaufwand, aus denen Sie das Angebot bauen. Enterprise kostet 29 US-Dollar im Monat für unbegrenzt viele Websites, mit einer 7-tägigen Testphase. Einen Blick ins Backend, in die Sicherungen oder in die Zugangsliste nimmt es Ihnen nicht ab, die zweite Hälfte dieser Checkliste bleibt also Ihre Aufgabe.