Was ist Website-Proofing? Unser Freigabe-Albtraum, gelöst

Post is also avalible in:

Letzte Aktualisierung: Juli 2026

Marketing ist nichts für schwache Nerven. Besonders wenn es sich um digitales Marketing handelt und Sie Ihre eigene Website pflegen müssen. Man sagte früher, das Internet vergisst nie, aber für kleinere Unternehmen war das kein großes Problem. Wenn man nicht gerade viral ging, bemerkten die wenigsten überhaupt, dass man da war.

Im letzten Jahr hat sich dieser Satz jedoch etwas verändert, da KI die klassischen Suchmaschinen zunehmend verdrängt (egal wie sehr sich manche dagegen wehren). Auch KI vergisst nie; schlimmer noch, sie bestraft Sie für Fehler auf eine Weise, die Sie sich nicht hätten vorstellen können. Und das trägt erheblich zur Komplexität des digitalen Marketings bei. Warum erzähle ich Ihnen das? Nun, weil ich Ihnen heute, liebe Leute, die Geschichte der Höhen und Tiefen der Website-Erstellung und meine eigenen Erfahrungen damit erzählen werde.

Das Projekt, das das Problem offenlegte

Die Veröffentlichung einer einzigen Feature-Seite zeigte uns genau, wie kaputt unser Website-Review-Prozess war. Hören Sie zu: Was ist das Schlimmste, das passieren kann, nachdem eine Website mit einem Fehler live gegangen ist? Ein Kollege (oder mehrere) weist darauf hin? Ein freundlicher Nutzer weist darauf hin? Ein weniger freundlicher Nutzer beschwert sich über irreführende Informationen? Eine KI-Übersicht greift es auf und behandelt es als Wahrheit? Suchen Sie sich Ihr Gift aus. 

Sicher, das sind völlig unterschiedliche Fehler, und Sie sind sich sicher, dass Ihnen das nie passieren würde. So dachte ich früher auch… Bis zu dem einen Tag, der alles veränderte. 

Als Marketingperson müssen Sie manchmal Themen erklären, in denen Sie selbst nur durchschnittlich bewandert sind. Trotzdem müssen Sie sich dieses Thema vornehmen, es in diese grundlegenden „coolen“ Konzepte zerlegen und sie präsentieren. Das Problem ist, dass Sie selbst immer noch nicht wirklich verstehen, worum es geht. Für unser Team war es ein entwicklerorientiertes Feature, das die gesamte Herangehensweise daran, wie wir Websites freigeben, veränderte. 

Die Aufgabe bestand darin, eine Feature-Seite über dieses großartige Ding zu erstellen, das Entwickler lieben würden, weil es ihre Arbeit erleichtert; sie müssen kaum etwas einrichten, aber das Ergebnis sieht wie eine sehr professionelle und fast unmögliche Aufgabe aus, gelöst im Handumdrehen. Das Geräusch dieses Fingerschnippens kam tatsächlich von meinem Schreibtisch, als ich versuchte, alle Korrekturen innerhalb einer Stunde vorzunehmen und sie von drei verschiedenen Personen genehmigen zu lassen, die keinen Zugang zur Entwicklungsumgebung hatten. Zweimal.

Was das alles gekostet hat 

Falls noch Zweifel bestehen, was passiert ist, sage ich es Ihnen ganz offen: Wir mussten die gesamte Feature-Seite zweimal überarbeiten, und zwar nach ihrer Veröffentlichung. Ja, Sie haben richtig gehört. Wir haben dieselbe Seite dreimal geprüft und veröffentlicht. Und nur weil wir Glück mit den Prüfern hatten, die ihr Feedback bei der frühestmöglichen Gelegenheit gaben, dauerte der gesamte Prozess nur einen Monat. Ganze 31 Tage, um eine Seite fertigzustellen, die aus 4 statischen und 1 interaktiven Block besteht, das ist wirklich nicht viel…  Zum Vergleich: Heute schaffen wir 3-4 Seiten in derselben Zeit.

Stellen Sie sich nun vor, Sie hätten mit Ihren Prüfern nicht so viel Glück. Jeder Schritt des Prozesses braucht 3-4 Tage bis zur Genehmigung, und am Ende bleibt Ihnen ein Berg an Korrekturen, die bis zum Ende der Woche erledigt sein müssen, damit der neue Freigabezyklus am Montag beginnen kann. 

Was wir (und Sie) wahrscheinlich falsch gemacht haben

Es gibt einen Grund, warum manche Website-Review-Prozesse länger dauern als andere, und bei uns gab es vier sehr große und offensichtliche Fehler:

Wir haben nie wirklich die Website geprüft

Das Hauptproblem beim Website-Proofing war für uns, dass wir nie wirklich eine Website geprüft haben. Manchmal war es ein Screenshot eines Ausschnitts eines Blocks mit einer roten Linie um ein fehlerhaftes Element. 

Manchmal war es eine Momentaufnahme einer Seite, gespeichert als PDF. Das ist doch nicht schlimm, könnten Sie denken; Adobe erlaubt schließlich das Anmerken. Falsch! 10 % der Seite fehlten wegen der natürlichen Aufteilung zwischen PDF-Seiten, sodass wir Textzeilen verloren oder ein Element in der Mitte durchgeschnitten sahen, nur weil es genau auf einem Seitenumbruch landete. 

Die dritte Option war die beste; man exportiert die Website einfach als JPEG und lädt sie in ein Online-Proofing-Tool hoch, in der Hoffnung, dass die Qualität ausreicht, damit jeder den Text lesen kann. Und dann verbringt man die nächsten 3 Werktage damit, hineinzuzoomen, damit es wie eine Website-Seite aussieht. Aber immerhin fehlten keine Teile, und das Feedback wurde nicht abgeschnitten.

Wir konnten interaktive Elemente nie genehmigen

Ein weiteres Problem war, dass wir interaktive Elemente, Schaltflächen und verschiedene Funktionen nie genehmigen konnten. Ein Screenshot zeigt nicht, was passiert, wenn man mit der Maus über eine Karte fährt, wie ein Dropdown-Menü geöffnet statt geschlossen aussieht, oder ob ein Formular tatsächlich abgeschickt wird, statt einfach nur hübsch dazustehen. Alles fühlte sich wie eine Grafik an, nicht wie eine Seite. Wir genehmigten, wie eine Website eingefroren aussah, nicht, was sie tatsächlich tat, sobald jemand sie berührte.

Und weil nichts davon anhand eines statischen Exports beurteilt werden konnte, musste eine weitere Person alle Schaltflächen, Animationen und Funktionen separat von Hand durchgehen und jedes einzelne Element auf der Live-Seite anklicken, um zu bestätigen, dass es tatsächlich funktionierte. Keine schöne Aufgabe, und auch keine schnelle. Es half nicht, dass dies immer erst nach der „offiziellen“ Freigabe geschah, sodass es sich weniger wie Qualitätssicherung anfühlte als vielmehr wie die Entdeckung, im ungünstigsten Moment, dass das, was gerade eben abgesegnet worden war, insgeheim kaputt war. Und irgendetwas ging immer schief. Also verbrachte ich jede zweite Woche eine halbe Stunde damit, eine traurige E-Mail zu schreiben, um zu erklären, warum sich die Veröffentlichung erneut verzögerte.

Feedback existierte gleichzeitig an drei verschiedenen Orten

Jedes Format, das wir für das Website-Proofing verwendeten, wurde zu seinem eigenen, separaten Feedback-Kanal. Drei verschiedene Website-„Formate“ bedeuteten also automatisch auch drei verschiedene Feedback-Quellen. Wir hatten Anmerkungen im Tool, ein paar mehr aus dem PDF, und dann noch einige mehr in privaten Chats und ein paar in Gruppen. 

Was wir also meistens getan haben: Ich machte einen Screenshot von jedem einzelnen Feedback und übertrug ihn dann in ein Google-Dokument als Checkliste. Und jedes Mal, wenn eine Änderung vorgenommen wurde, kam ich zu diesem Dokument zurück und hakte einen weiteren Punkt ab. Ziemlich praktisch, aber ein Albtraum zusammenzustellen und kaum funktionsfähig. Wie dieser Laptop, der seit ein paar Jahren die Gesetze der Physik trotzt, indem er einfach weiter funktioniert.

Prüfer konnten nicht nachvollziehen, was sich bereits geändert hatte

Wir hatten auch keine Möglichkeit, Prüfern zu zeigen, was sich seit ihrer letzten Anmerkungsrunde geändert hatte. Und mein liebster Teil des gesamten Prozesses ist die Frage: „Oh, haben Sie das geändert, worum ich vor zwei Runden gebeten hatte?“ Ich weiß, dass es nicht böse gemeint ist, und ich verstehe, dass die Änderung klein und fast unsichtbar war, aber ich habe zwei Stunden dafür gebraucht, und für mich ist sie sehr sichtbar.

Aber das passiert nun einmal, wenn man Freigaben von Personen erhält, die selbst jede Menge eigene Arbeit haben, und es keine Erinnerung daran gibt, wie die Seite früher aussah. Und beide Versionen zu senden, ist auch keine Option, es sei denn, man klebt ein großes, fettes „veraltet“-Schild über die ganze Seite, wie ein trauriges Wasserzeichen.

Warum wir uns schließlich entschlossen, das zu lösen

Vor dem Feature-Seiten-Vorfall war dieser gesamte Prozess einfach nur lästig. Manche wollten einfach nur weitermachen und schenkten dem Inhalt der Seite kaum Beachtung. Andere hatten nicht genügend Zugriffsrechte, also baten sie entweder um eine statische Version oder schauten sich die Seite nach der Veröffentlichung gar nicht mehr an. 

Nach dem Feature-Seiten-Vorfall wurden jedoch falsche Informationen eine Zeit lang live angezeigt, und die KI griff sie fast sofort auf; es herrschte Einigkeit darüber, dass etwas unternommen werden musste. Zunächst suchten wir extern nach Plugins, zusätzlichen Tools oder API-Brücken, um die Website in ein Proofing-Tool zu laden. 

Doch dann (eigentlich ziemlich schnell) erkannten wir, dass die Antwort direkt vor uns lag. Wir hatten bereits ein Proofing-Tool zur Hand, mehrere Kunden, die genau das in ihrem Workflow benötigten, und unsere eigene interne Motivation, eine Möglichkeit für Website-Reviews zu schaffen. Also entschieden wir, dass wir es nicht suchen, sondern selbst bauen sollten. 

Was ist Website-Proofing?

Website-Proofing bedeutet, eine Live- oder Staging-Website auf Desktop, Tablet und Mobilgerät zu prüfen, bevor sie veröffentlicht wird, mit Kommentaren, die an der genauen Stelle auf der Seite verankert sind. Es ersetzt Screenshots, PDFs und E-Mail-Verläufe durch einen einzigen Ort, an dem man die Website sehen, durchklicken und so freigeben kann, wie sie tatsächlich funktionieren wird.

Ein Tool, das genau das leistet, nennt man ein Website-Review- (oder Proofing-) Tool. Es handelt sich um eine zentrale Plattform, die es Ihnen ermöglicht, Websites oder einzelne Seiten interaktiv zu prüfen und mit Anmerkungen zu versehen. Das bedeutet, Sie können auf Schaltflächen klicken, Animationen ansehen und über die Website navigieren, während Sie weiterhin verankerte Kommentare hinterlassen können. 

Statt also den ganzen Umweg über den Export und Versand einer statischen Website zu gehen, gebe ich einfach die URL ein, füge die E-Mail-Adressen aller Personen hinzu, die freigeben müssen, und klicke auf Senden. Oder noch einfacher: Ich kopiere einfach den Link und schicke ihn in den Gruppenchat, und jetzt kann jeder sagen, was er von einer Seite hält, an der ich zwei Tage gearbeitet habe! 

Es gibt bereits einige Website-Proofing-Tools auf dem Markt, manche speziell für Websites entwickelt (BugHerd, Pastel), und manche allgemeinen Online-Proofing-Tools mit zusätzlichem Website-Proofing, wie PageProof. Aber keines davon existierte innerhalb unseres eigenen Workflows, als wir es am dringendsten brauchten. Also entschieden wir uns für den einfacheren Weg und bauten stattdessen unser eigenes Tool.

Wie Website-Proofing jedes dieser Probleme löste

Und dieses Website-Proofing-Tool hat einen Großteil unserer internen Missstände hervorragend gelöst, also entschieden wir, dass es gut genug funktioniert, um es Ihnen vorzustellen. Und um keine unbelegten Behauptungen aufzustellen, zeige ich Ihnen, wie ein Website-Review-Tool uns das Leben deutlich erleichtert hat. 

Falls Ihnen das bekannt vorkommt, liegt das daran, dass es sich um eine folgenreichere Variante eines Problems handelt, über das wir bereits geschrieben haben: warum Ihnen die herkömmliche Methode Zeit kostet. Screenshots und E-Mail-Verläufe sind langsam, egal was Sie gerade freigeben.

Was ein Website-Review-Tool haben sollte

Nachdem ich die verschiedenen Spielarten von „Website-Proofing“ durchlebt habe, habe ich klare Vorstellungen davon, was ein echtes Proofing-Tool von einem Workaround unterscheidet, der sich als Proofing-Tool ausgibt. Für mich ging es dabei immer darum, wie schnell man es in die Prüfung schicken kann und wie leicht andere darauf zugreifen können. Hier ist also, was ich für nicht verhandelbar halte, von jemandem, der zunächst jede falsche Herangehensweise ausprobiert hat:

• Lädt die tatsächliche Live- oder Staging-Seite, nicht einen Screenshot, ein PDF oder einen JPEG-Export davon
• Ermöglicht das Wechseln zwischen Desktop-, Tablet- und Mobilansicht, ohne drei separate Tabs zu öffnen
• Ermöglicht das Klicken auf Schaltflächen, das Auslösen von Animationen und die Navigation zu verlinkten Seiten
• Verankert Kommentare an der exakten Stelle auf der Seite, statt sie zu verstreuen
• Verfolgt Versionen, sodass niemand erneut etwas anmerkt, das Sie schon zwei Runden zuvor behoben haben
• Funktioniert über einen einzigen teilbaren Link, sodass jeder mitreden kann, egal ob mit oder ohne Entwicklerzugang
• Erstellt einen Abschlussbericht darüber, was von wem freigegeben wurde, damit bei Rückfragen ein tatsächlicher Nachweis vorliegt

Wenn ein Tool die meisten dieser Punkte nicht erfüllt, prüfen Sie ehrlich gesagt nur ein Gerücht einer Website. Und das ist keine gute Position. 

Wer definitiv ein Website-Proofing-Tool braucht

Aber nicht jedes Team braucht das. Wenn Sie ein einzelner Entwickler sind, der seine eigene Portfolio-Website veröffentlicht, viel Erfolg – Sie brauchen wahrscheinlich nicht, dass Ihre Mutter Kommentare auf Ihrem Hero-Bereich verankert. Aber wenn mehr als eine Person eine Seite freigeben muss, bevor sie live geht, und besonders wenn manche dieser Personen nicht die Geduld eines Entwicklers für Staging-Umgebungen haben, dann ist das genau das Richtige für Sie. Wenn Sie also:

• Ein Marketing- und/oder Kreativteam sind, das eine Website lanciert oder überarbeitet
• Jemand sind, den ein Prüfer ohne jede Erinnerung daran, wie die Seite aussah, schon einmal gefragt hat: „Haben Sie diese Änderungen von November eigentlich gemacht?“
• Teams sind, in denen die Rechtsabteilung, ein Manager oder eine andere Abteilung freigeben muss, bevor etwas live geht, ohne Zugang zu einer Entwicklungsumgebung erwarten zu können
• Agenturen sind, die eine fertige Website an einen Kunden übergeben, der einen sauberen, exportierbaren Nachweis dessen wünscht, was tatsächlich freigegeben wurde
• Entwicklungsteams sind, die es leid sind, die Einzigen zu sein, die den Staging-Link öffnen können, und die es sehr begrüßen würden, nach dem Livegang keine Rückmeldungen mehr zu ihren interaktiven Blöcken zu erhalten

Wenn Sie diese Liste gelesen und bei mehr als einem Punkt genickt haben, wissen Sie bereits, warum wir das entwickelt haben.

Fazit

Nun fragen Sie sich vielleicht, warum ich so viel Zeit und so viele Worte auf meine eigenen Freigabe-Albträume verwendet habe. Das ist eine faire Frage. Die kurze Antwort lautet: Dies ist die Geschichte von Approval Studio, keine hypothetische Geschichte. Wir haben dieses Problem nicht von außen betrachtet. Wir haben es von innen erlebt, dieselbe Seite dreimal überarbeitet, ein Google Doc als unsere einzige verlässliche Quelle geführt, weil nichts anderes zuverlässig genug war, und uns öfter fragen lassen „Haben Sie das übrigens schon geändert?“, als ich hier schriftlich zugeben möchte.

Also haben wir unser eigenes Website-Proofing-Feature entwickelt, um das zu beheben, es intern bei unseren eigenen Launches getestet, bis wir ihm wirklich vertrauten (und nicht nur hofften, dass es funktioniert), und jetzt sind wir bereit, es mehr Menschen zugänglich zu machen. Wenn Sie lieber nicht Ihre eigene Version dieser Geschichte schreiben möchten, tragen Sie sich in die Warteliste ein. Wir benachrichtigen Sie in dem Moment, in dem es live geht, und Sie müssen Ihrem Manager nach einem Launch nie wieder einen kaputten Button erklären.