Die neue Kita-Website ist online. Zwei Tage später fällt das Kontaktformular aus – und die Leitung, der Träger und die Webbetreuung warten jeweils darauf, dass jemand anderes reagiert.
Damit euch genau das nicht passiert, empfehle ich zwei getrennte Schritte: Bei der Abnahme prüft ihr sichtbare Funktionen. Bei der Übergabe haltet ihr fest, wer danach verantwortlich ist, welcher Nachweis vorliegt und wer im Störungsfall entscheidet. Die folgende Vorlage begleitet euch von der Freigabe bis zum geregelten Betrieb.
Das findet ihr in diesem Artikel
Der Relaunch ist erst mit einer betriebsfähigen Übergabe fertig
Eine mündliche Freigabe sagt noch nicht, wer am nächsten Morgen das Formular kontrolliert oder bei einem Fehler handeln darf. Teilt den Abschluss deshalb in zwei Protokolle:
- Abnahme: Ihr prüft, ob vereinbarte Seiten, Links und Funktionen arbeiten.
- Übergabe: Ihr ordnet Verantwortung, Zugänge, Nachweise, Prüftermine und den Störungsweg zu.
Benannt werden Rollen, nicht nur einzelne Personen. Statt „Frau Müller“ schreibt ihr zum Beispiel „Kita-Leitung, vertreten durch stellvertretende Leitung“. So bleibt die Vereinbarung auch bei Urlaub oder einem Personalwechsel verständlich.
Ein Prüfpunkt ist erst erledigt, wenn ein sichtbares Ergebnis eingetragen ist. „Formular geprüft“ ist zu vage. „Testanfrage am 05.10.2026 um 10:15 Uhr im Funktionspostfach angekommen“ lässt sich nachvollziehen.
Die Übergabe-Checkliste zum Kopieren
Kopiert diese Tabelle in euer gemeinsames Projektdokument. Die verantwortliche Rolle entscheidet und kontrolliert. Die ausführende Stelle erledigt die technische oder redaktionelle Aufgabe. Beim Nachweis notiert ihr das Ergebnis, nicht nur ein Häkchen. Der Ablageort führt zu Protokollen und Vertragsunterlagen – Passwörter gehören nicht in diese Tabelle.
| Bereich | Verantwortliche Rolle | Ausführende Stelle | Geprüfter Nachweis | Ablageort | Nächster Prüftermin | Notfallkontakt |
|---|---|---|---|---|---|---|
| Domain und Hosting | Trägerverwaltung | Hosting-Betreuung | Eigener Hauptzugang getestet; Vertragsinhaber geprüft | Vertragsablage | Datum eintragen | Name, Vertretung, Kontaktweg |
| CMS | Kita-Leitung | Webbetreuung | Eigener Zugang kann Inhalte bearbeiten und Rechte verwalten | Zugangsverwaltung | Datum eintragen | Name, Vertretung, Kontaktweg |
| Kontaktformular und E-Mail-Eingang | Kita-Leitung | Büro oder Webbetreuung | Testanfrage mit Datum und Eingang dokumentiert | Abnahmeprotokoll | Datum eintragen | Name, Vertretung, Kontaktweg |
| Search Console | Träger oder zuständige Webrolle | Webbetreuung | Bestätigter Inhaber und benötigte Nutzerrollen geprüft | Zugangsverwaltung | Datum eintragen | Name, Vertretung, Kontaktweg |
| Weiterleitungen | Projektverantwortung | Webbetreuung | Stichprobe alter wichtiger URLs mit richtigem Ziel dokumentiert | Weiterleitungsliste | Datum eintragen | Name, Vertretung, Kontaktweg |
| Sicherung und Wiederherstellung | Träger oder technische Verantwortung | Hosting- oder Webbetreuung | Dateien und Datenbank gesichert; Wiederherstellung protokolliert | Sicherungsdokumentation | Datum eintragen | Name, Vertretung, Kontaktweg |
| Updates | Technische Verantwortung | Webbetreuung | Updateweg, Sicherung davor und Funktionstest danach vereinbart | Wartungsvereinbarung | Datum eintragen | Name, Vertretung, Kontaktweg |
| Inhaltsfreigabe | Kita-Leitung | Redaktion oder Webbetreuung | Melde-, Freigabe- und Einpflegeweg festgehalten | Redaktionsplan | Datum eintragen | Name, Vertretung, Kontaktweg |
| Störungsmeldung | Träger oder Kita-Leitung | Webbetreuung | Annahme, Entscheidung und Rückmeldung vereinbart | Notfallblatt | Datum eintragen | Name, Vertretung, Kontaktweg |
Zugänge so übergeben, dass eure Kita handlungsfähig bleibt
Lasst euch nicht nur bestätigen, dass „ein Zugang vorhanden“ ist. Meldet euch mit einem eigenen Hauptzugang der Kita oder des Trägers an und prüft die benötigten Rechte. Klärt außerdem, welche Rolle weitere Nutzer hinzufügen oder entfernen darf. Zugangsdaten bewahrt ihr in eurer vorgesehenen sicheren Zugangsverwaltung auf, nicht im Übergabeprotokoll.
Bei der Google Search Console gibt es Inhaber sowie uneingeschränkte und eingeschränkte Nutzer. Diese Rollen dürfen nicht dasselbe. Nur Inhaber können andere Nutzer hinzufügen oder entfernen; mindestens ein bestätigter Inhaber muss bestehen bleiben. Ich würde deshalb zuerst den eigenen Inhaberzugang und die zugehörige Bestätigung prüfen. Erst danach entfernt ihr ausgeschiedene Projektbeteiligte und nicht mehr benötigte Bestätigungstokens.
Geht nach demselben Muster bei Domain, Hosting und CMS vor:
- Eigenen Zugang anmelden.
- Benötigte Rechte mit einer harmlosen Aufgabe prüfen.
- Vertretung und Wiederherstellungsweg festhalten.
- Nicht mehr berechtigte Personen anschließend entfernen lassen.
Fünf Abnahmetests mit sichtbarem Ergebnis
Nehmt für die Abnahme ein Smartphone und das gemeinsame Protokoll zur Hand. Für jeden Test tragt ihr Datum, Ergebnis und gegebenenfalls einen offenen Fehler ein.
- Alte Adresse öffnen: Ruft eine wichtige alte Unterseite auf. Sie muss auf das passende neue Ziel führen, nicht pauschal auf die Startseite.
- Formular wirklich absenden: Sendet am Smartphone eine eindeutig benannte Testanfrage. Prüft die Bestätigung auf der Website und den tatsächlichen Eingang im vorgesehenen Postfach.
- Kontakt und Downloads testen: Öffnet auf zentralen Seiten Telefon-, E-Mail- und Downloadlinks. Eine kleine, bewusst gewählte Stichprobe ist hilfreicher als ein undokumentiertes „alles geprüft“.
- Öffentliche Erreichbarkeit prüfen: Ruft wichtige neue URLs ohne Anmeldung auf. Lasst außerdem kontrollieren, dass die veröffentlichte Website nicht versehentlich für Suchmaschinen gesperrt ist.
- Wiederherstellung belegen lassen: Lasst euch eine dokumentierte Sicherung von Dateien und Datenbank sowie den Nachweis einer bereits durchgeführten Wiederherstellung zeigen. Eine vorhandene Sicherungsdatei allein beweist noch nicht, dass der Rückweg funktioniert.
Google empfiehlt bei geänderten Adressen eine Zuordnung alter und neuer URLs, passende Weiterleitungen und die Beobachtung beider URL-Bestände nach dem Umzug. Genau deshalb gehört die Weiterleitungsstichprobe ins Abnahmeprotokoll.
Pflege nach dem Start verbindlich verteilen
Technische Wartung und Inhaltspflege sind zwei verschiedene Aufgaben. Haltet beide getrennt fest.
Für eine WordPress-Website sollte klar sein, wer WordPress selbst, Plugins und Themes aktualisiert, vorher sichert und danach Startseite, Navigation, Formular und einen Download stichprobenartig testet. WordPress empfiehlt eine Sicherung vor Updates. Eine vollständige typische Sicherung umfasst dabei Dateien und Datenbank. Bei einem anderen CMS lasst ihr euch den entsprechenden Update- und Sicherungsweg zeigen.
Für Inhalte braucht ihr eine kurze Meldekette: Wer meldet geänderte Öffnungs- oder Schließzeiten, Teamangaben, Stellen und Downloads? Wer gibt die Änderung frei? Wer pflegt sie ein und bestätigt die Veröffentlichung?
Mein Vorschlag für den Übergang in den Regelbetrieb:
- Nach 24 Stunden: Formulareingang, Startseite und zentrale Links kontrollieren.
- Nach sieben Tagen: offene Abnahmepunkte und Weiterleitungen nachfassen.
- Nach 30 Tagen: reguläre Pflege, Prüftermine und Ansprechpartner endgültig übernehmen.
Diese Abstände sind ein praktischer Redaktionsvorschlag. Passt sie an eure Vereinbarung und die Dringlichkeit eurer Website an.
Ein Störungsweg, der im Ernstfall funktioniert
Für den Störungsweg genügen vier klare Antworten: Was gilt als Störung? Wer nimmt sie an? Wer entscheidet über Reparatur oder Rücknahme? Wie erfährt die Kita den aktuellen Stand? Ergänzt Notfallkontakt, Vertretung, vereinbarten Kontaktweg und den Ablageort des letzten nachweislich funktionierenden Sicherungsstands.
So könnte ein Eintrag aussehen. Das folgende Beispiel ist fiktiv:
Kita Sonnenbogen – Kontaktformular: Verantwortlich ist die Kita-Leitung, vertreten durch die stellvertretende Leitung. Ausführende Stelle ist die Webbetreuung. Nachweis: „Testanfrage RELAUNCH-0510 am 05.10.2026 um 10:15 Uhr im Funktionspostfach eingegangen; Bestätigungsseite am Smartphone sichtbar.“ Das Protokoll liegt im Projektordner „Website/Abnahme“. Die nächste Prüfung ist für den 12.10.2026 eingetragen. Als Störung gilt, wenn keine Nachricht eingeht oder eine Fehlermeldung erscheint. Gemeldet wird sie über den vereinbarten Supportweg. Über Reparatur oder Rücknahme entscheidet die technische Projektverantwortung des Trägers. Die Leitung erhält dort eine Statusmeldung.
Der Eintrag bleibt kurz, nennt aber für jede Rückfrage eine zuständige Rolle und einen prüfbaren Beleg. Genau daran erkennt ihr eine brauchbare Übergabe.
Einmal kurz prüfen
- Für Domain, Hosting, CMS und Search Console einen eigenen Zugang der Kita oder des Trägers testen
- Für jeden Bereich verantwortliche Rolle, Vertretung und ausführende Stelle eintragen
- Formular am Smartphone absenden und den tatsächlichen E-Mail-Eingang dokumentieren
- Wichtige alte URLs öffnen und ihre passenden neuen Ziele festhalten
- Sicherung von Dateien und Datenbank sowie einen Wiederherstellungsnachweis ablegen
- Update-, Inhaltspflege- und Störungsweg mit nächsten Prüfterminen vereinbaren
Quellen & weiterführende Informationen
Das könnte euch auch helfen
Der vollständige Leitfaden für eure Kita-Website verbindet diesen Schritt mit Orientierung, Anfragewegen und lokaler Sichtbarkeit.
Website für Kita-Träger: zwei Standortseiten im Direktvergleich
Vergleicht zwei Kita-Standortseiten Zeile für Zeile. Mit sechs Prüfpunkten, fiktivem Beispiel und klaren Aufgaben für Träger, Leitung und Webbetreuung.
Anleitung lesen →PRAXISRATGEBERSpam im Kita-Kontaktformular stoppen, ohne echte Anfragen zu verlieren
So grenzt ihr Formularspam von Zustellfehlern ab, beauftragt passende Schutzstufen und prüft mit drei Tests, ob echte Kita-Anfragen weiter ankommen.
Anleitung lesen →PRAXISRATGEBERKita-Platzanfrage vereinfachen: vom ersten Klick zur Rückmeldung
Ein kurzes Anfrageformular für eure Kita: passende Felder, direkte Links, verständliche Bestätigungen und Hilfe bei typischen Fehlern – Schritt für Schritt.
Anleitung lesen →
