Wenn du als Agentur oder Freelancer WordPress-Seiten betreust, kennst du das Ritual: Montag morgen, zehn Tabs offen, Update-Hinweise, SSL-Ablaufdaten, „hat jemand schon den Cache geleert?“, und irgendwo in Notion oder einer Excel-Datei soll noch stehen, was letzte Woche wirklich passiert ist.

Genau aus diesem Alltag heraus ist WP Shelter entstanden. Nicht als großes Launch-Projekt von Tag eins – sondern weil ich es zuerst für mich selbst gebaut habe. Und wir sind jetzt so weit, dass ich darüber schreiben kann, ohne nur PowerPoint-Visionen zu verkaufen: Wir testen live mit 20 Websites – und das sind nicht irgendwelche Demo-Installationen, sondern die Seiten meiner Kunden.

Was ist WP Shelter eigentlich?

WP Shelter ist eine Plattform zur zentralen Steuerung und Wartung von WordPress-Websites. Nicht „noch ein weiteres Monitoring-Dashboard, das nur grüne Häkchen zeigt“ – sondern ein Werkzeug für den Teil der Arbeit, der bei Agenturen und Freelancern oft unterschätzt wird: die laufende technische Betreuung.

Kurz gesagt: Du verbindest deine WordPress-Sites über einen Agenten mit WP Shelter und steuerst Wartung von einem Ort aus – Updates, Status, Health-Checks, Cache-Themen und vor allem: die Dokumentation davon.

Denn Wartung, die nicht nachvollziehbar dokumentiert ist, ist für Kunden schwer greifbar – und für dich im Streitfall oder beim Monatsreport mühsam zu rekonstruieren.

Warum ich das baue

Ich habe WP Shelter nicht gebaut, weil die Welt zu wenig SaaS-Tools hätte. Ich habe es gebaut, weil mein eigener Wartungsalltag irgendwann so aussah:

• Updates liefen pro Site im WordPress-Backend – oder halb automatisiert, halb „ich mache das später“.
• Was erledigt wurde, landete in Chat-Nachrichten, Tickets oder gar nicht.
• Kunden fragten: „Was habt ihr diesen Monat gemacht?“ – und dann begann die Rekonstruktion.
• Je mehr Sites, desto schneller zerfiel der Überblick.

Irgendwann war klar: Wenn ich das für meine eigenen Kundenprojekte nicht sauber im Griff habe, hilft mir kein weiteres Tab und keine weitere Checkliste. Also habe ich angefangen, das Werkzeug zu bauen, das ich selbst brauchte.

Genau da will WP Shelter ansetzen: eine zentrale Steuerung für Wartung – und parallel eine Spur, die zeigt, was wann passiert ist.

Der Kern: Wartung zentral steuern – und automatisch dokumentieren

Mein Fokus liegt klar auf dem Wartungsbereich. Nicht auf fancy Marketing-Features, sondern auf dem, was Agenturen und Freelancer Woche für Woche brauchen:

• Zentrale Übersicht über mehrere WordPress-Sites
• Wartungsabläufe von einem Dashboard aus anstoßen und nachverfolgen
• Automatische Dokumentation – etwa Arbeitsprotokolle zu Updates und durchgeführten Maßnahmen
• Weniger Hin-und-her zwischen Site-Admin, Notizen und Kundenbericht

Gerade die automatische Dokumentation ist für mich kein „Nice to have“. Wenn ein Update-Lauf oder eine Cache-Aktion durchläuft, soll daraus nachvollziehbar werden, was passiert ist – ohne dass jemand hinterher manuell drei Absätze tippt. Manuelle Einträge bleiben möglich, aber der Grundsatz ist: Wartung erzeugt Spuren.

Für Freelancer heißt das: weniger Admin-Arbeit neben der eigentlichen Arbeit. Für Agenturen: klarere Übergaben im Team und belastbarere Nachweise gegenüber Kunden.

Wo wir gerade stehen: Beta mit 20 Kunden-Websites

Theorie ist billig. Deshalb sind wir jetzt im Beta-Test mit 20 Websites – und das sind die Seiten, die ich ohnehin betreue: Kundenprojekte aus dem echten Alltag.

Das klingt nach einer kleinen Zahl – und genau deshalb ist sie für mich wertvoll. Zwanzig echte Installationen bedeuten zwanzig unterschiedliche Hostings, Plugin-Kombinationen, Cache-Setups und Edge Cases. Kein sauberes Staging-Labor, sondern der Alltag, für den ich WP Shelter ursprünglich gebaut habe.

Genau dort zeigt sich, ob ein Wartungs-Workflow hält oder nur in der Demo gut aussieht. Und genau deshalb ist dieses Beta für mich so wichtig: Wenn etwas hakt, merke ich es nicht erst bei fremden Early Adopters – sondern direkt an den Sites, für die ich verantwortlich bin.

Aktuell geht es vor allem darum:

• wie stabil die Anbindung über den Agenten läuft,
• wie sich Wartungsjobs im Alltag anfühlen,
• wo Dokumentation greift – und wo sie noch zu dünn ist,
• welche Reibung im echten Kundenbetrieb wirklich nervt.

Kein Launch-Feuerwerk. Kein „jetzt alle rein“. Einfach: bauen, an eigenen Kundenprojekten testen, nachschärfen.

Was WP Shelter bewusst nicht sein soll

WP Shelter soll kein Alleskönner werden, der Hosting, Design, SEO und Security in einem Dashboard vermischt. Der Anspruch ist enger – und deshalb hoffentlich nützlicher:

Zentrale Wartungssteuerung für WordPress, mit nachvollziehbarer Dokumentation.

Monitoring und Health-Infos gehören dazu, weil Wartung ohne Sichtbarkeit Blindflug ist. Aber der Produktkern bleibt: Sites steuern, Maßnahmen durchführen, Arbeit sichtbar machen.

Behind the Scenes: so fühlt sich der Bau gerade an

Ehrlich: Solche Produkte entstehen nicht linear. Ein Tag ist Agent-Heartbeat und Update-Pipeline, der nächste ist Arbeitsprotokoll-Logik, der übernächste ist „warum bricht genau diese eine Cache-Plugin-Kombi auf Kundenprojekt X?“.

Was mir in der Beta am meisten hilft, ist genau dieses Dogfooding: WP Shelter muss zuerst in meinem eigenen Wartungsalltag funktionieren. Welche Information brauche ich wirklich vor einem Update? Was muss im Protokoll stehen, damit ein Monatsreport schnell wird? Wo reicht Automatik, und wo will ich bewusst manuell eingreifen?

Genau diese Fragen treiben die nächste Iteration.

Kurzfassung

Ich habe WP Shelter zuerst für mich selbst gebaut – als Werkzeug für die zentrale Wartung meiner WordPress-Kundenprojekte. Der Fokus liegt auf zentraler Steuerung im Wartungsbereich und darauf, dass durchgeführte Arbeiten möglichst automatisch in Arbeitsprotokollen und nachvollziehbarer Dokumentation landen.

Aktuell läuft der Beta-Test mit 20 Websites: den Seiten meiner Kunden. Die öffentliche Seite ist noch nicht „fertig präsentierbar“ – und das ist okay. Erst soll der Kern im Alltag funktionieren. Danach kommt der Rest.

Wenn du selbst WordPress-Wartung machst: Du weißt, warum das Thema zählt. Weniger Chaos zwischen Backends. Mehr Klarheit darüber, was wirklich erledigt wurde.

Genau daran arbeite ich gerade.