WordPress-Wartung wird oft als der „Goldene Gral“ unter den WordPress-Dienstleistungen gesehen: regelmäßige, planbare Einnahmen bei vermeintlich wenig Aufwand. Doch stimmt dieses Bild wirklich?
In dieser Episode sprechen wir mit Marc Nilius (Gründer und Geschäftsführer von WP-Wartung24) darüber, was eine wirklich gute WordPress-Wartung ausmacht. Denn der Mythos vom Goldenen Gral endet spätestens dann, wenn eine Website crasht oder gehackt wird. Wie beugt man solchen Fällen vor und wie schützt man sich und seine Kund*innen am besten?
Außerdem sprechen wir darüber, wie man Wartungspakete erfolgreich verkauft, sodass sowohl Du als auch Deine Kunden langfristig zufrieden sind.
Unser Gespräch deckt folgende Themen ab:
00:00 Intro & Wer ist Marc?
06:10 WP Wartung 24: Agentur oder technischer Dienstleister?
15:24 Probleme, wenn man zu viele Websites betreut
22:06 Challenges bei guter Wartung
46:06 Kann man als eine Person gute Wartung anbieten?
53:42 Wartungs-Pakete erfolgreich verkaufen
01:20:36 Bullet Fragen
https://wp-wartung24.de
https://www.linkedin.com/in/marc-nilius-a692aa65/
#wordpress #wordpresspodcast
// WP Office Newsletter //
https://www.daswpoffice.com/
// Frage oder mögliche Zusammenarbeit? //
Du kannst mich jederzeit über meine Website erreichen:
https://dominikliss.com/
Host
Gast
Die WordPress-Wartung wird oft so als der goldene Gral in der WordPress-Welt gesehen.
Also, in der Theorie klingt das mal ganz nett.
Du schickst dem Kunden monatliche Rechnungen und klickst zweimal auf Updates und Erledigt und Auf Wiedersehen.
Aber wenn du jetzt deinen Kunden langfristig erfolgreich betreuen möchtest und wirklich gesunde WordPress-Websites betreuen möchtest, auf die lange Zeit gesehen, steckt dann noch viel mehr dahinter.
weil das ist dann die Qualität der Wartung, die du lieferst und da passieren solche Sachen manchmal, hey, Websites funktionieren nicht oder Website wurde gehackt, was passiert dann? Sollte man sich rechtlich absichern? Was passiert in Bezug auf die DSGVO? Was ist mit der IT Security? Und all das gehört dazu, wenn man dann auch wirklich eine qualitativ hochwertige WordPress Wartung anbieten möchte.
Und genau über dieses Thema werden wir uns in dieser Episode unterhalten.
Herzlich willkommen bei der 79. Episode der Dominik Liss Show.
Auf diesem Podcast gibt's WordPress und Business Talks.
Das heißt, wenn du WordPress in deinem Business verwendest, dann bist du hier genau richtig.
Weil in jeder Episode entpacken wir dir Skills, Stories und Geheimnisse der besten Experten aus der WordPress-Branche.
Und das Ziel des Podcasts ist dir dabei zu helfen, ein besserer Professional in der WordPress-Welt zu werden.
Und heute unterhalten wir uns mit Marc Nilius.
Marc ist Gründer und Geschäftsführer von WP-Wartung 24. Und da werden wir als erstes mal reden, wie ist es zu WP-Wartung 24 gekommen, weil da gab es ja irgendwo den Anfang und dann gab es irgendwann den Zeitpunkt, dass Web Hoster WP-Wartung 24 geblockt haben, weil zu viele WordPress-Websites da betreut wurden.
Und insgesamt ist es schon bei 800 plus Websites, wenn ich das richtig aus dem Vorgespräch in Erinnerungen habe und Marc.
Herzlich willkommen.
Bevor ich da zu viel herumrede, kannst du dich selbst auch kurz vorstellen und sagen, wie ist es überhaupt zu WP Wartung 24 gekommen und was war da so diese Entstehungsgeschichte? Ja, hallo Dominik, vielen Dank für die Einladung zum Podcast.
Wie ist es zu WP Wartung 24 gekommen? Ja, das ist eine ganz lustige Geschichte.
Ich habe ursprünglich Diplom-Informatik studiert, hab mich, das ist schon ein bisschen her, in den Anfang der 2000er, hab mich aber immer um das Web gekümmert, immer Interesse an Internet, Websites und allem Möglichen gehabt.
Hab früh eine Medienagentur mit ein paar Kollegen zusammen gehabt, bin dann aber wieder in die Festanstellung gegangen, hab als Entwickler gearbeitet und Irgendwann gab es aber wieder irgendeine Idee und ein Projekt und es gab wieder ein paar Kollegen, mit denen man was zusammen gemacht hat.
Wir haben Software entwickelt im Tourismusbereich und ja, irgendwann haben wir auch einfach eine WordPress-Webseite gehabt, um unser Unternehmen zu bewerben.
Und zu dem Zeitpunkt hatte ich keinerlei Ahnung von WordPress und es war sogar ein externer Dienstleister, der uns die Webseite erstellt hat, auf unserem Server.
Und ich bekam am Ende des Monats irgendwie die Abrechnung des Datentransfers, beziehungsweise die Statistik des Datentransfers und der war maximal in die Höhe gegangen.
Und ich habe mich gewundert, was denn da los ist, habe mir den Server angeguckt, mir das Verzeichnis mit der WordPress-Installation angeguckt und habe entdeckt, dass da ganz viele komische Dateien drin liegen, die ich nicht kannte, mit denen ich nichts anfangen konnte.
Und am Ende war es so, die Webseite war gehackt, weil sie zu lange keine Updates bekommen hat, keine Sicherheitsmaßnahmen hatte.
Und am Ende ist da eine Phishing-Attacke gelaufen.
Das heißt, über unseren Server sind E-Mails verschickt worden für eine Steuerrückerstattung in den USA.
Und da war dann auch ein Link zu unserer Webseite drin, also so einer gefakten Unterseite, auf der dann so ein lustiges Steuerrückerstattungsformular war.
Wir haben dann in der nächsten Zeit auch diverse E-Mails von amerikanischen Bürgern bekommen, die sich darüber beschwert haben, dass sie ja ihre Steuerrückerstattung noch gar nicht bekommen hätten.
Das war also ein ganz, ganz großer Fail an dieser Stelle und habe mich dann in dem Zusammenhang darum gekümmert, das alles wieder rückgängig zu machen, alles sauber zu machen, alles wieder neu zu installieren, alles zu reparieren.
Ich habe da wirklich viel Zeit reingesteckt und mich in dem Zuge dann erstmalig mit dem Thema beschäftigt.
Eine Anekdote ist, dass zum Beispiel unsere E-Mail-Adressen noch jahrelang bei bestimmten Behörden auf dem internen Spam-Filter standen und wir keine Mails an bestimmte Behörden schicken konnten von unserer Standard-E-Mail-Adresse aus.
Das hat mich doch schon deutlich mitgenommen.
Da habe ich das erste mal sehr tief in dieses Thema der Website-Sicherheit reingeblickt.
Und seit dem Zeitpunkt habe ich mich damit beschäftigt.
Und seit dem Zeitpunkt habe ich ganz, ganz viel gelernt.
Also das war 2011. Und irgendwann im Jahre 2015, also vor etwas mehr als zehn Jahren, war es dann soweit, dass ich mich entschieden habe, das dann tatsächlich professionell anzubieten.
Und auch da ist es eingestiegen erst mal mit der Reparatur gehackter Webseiten.
Das war eigentlich der Einstiegspunkt, der mich auch immer am meisten interessiert hat und auch immer noch interessiert.
Das mache ich immer noch ganz, ganz gerne.
Und daraus ist eigentlich entstanden die Idee, die Webseiten auch dauerhaft zu betreuen und zu warten, weil auch die Kunden auf mich zugekommen sind und das angefragt haben.
Nachdem ich die Webseiten enthackt und repariert habe, haben sie gesagt, ey, kannst du nicht auch dauerhaft bei meiner Seite gucken, damit das nicht mehr passiert? Und daraus ist dieser Service WP Wartung 24 entstanden.
Und ja, das war 2015. Seit 2019 dann mit den ersten Mitarbeitenden.
Und jetzt stehen wir bei zwölf Mitarbeitenden.
Und die eben von dir schon richtig erwähnten, etwas mehr als 800 Seiten in der Betreuung, in der regelmäßigen Wartung, auf die wir ein Auge haben? Ja, weil das, was für mich so auf den ersten Blick so mega bemerkenswert war, war, okay, die WP Wartung 24 steckt im Namen.
Es ist halt eine mega, mega, mega zielgerichtete Spezialisierung, so okay, wir machen das und wenn du das brauchst, dann ruf uns an und dann kontaktiere uns.
Ist es wo du dann aktiv, wenn es im Namen drin steht, hast du dann die Entscheidung schon aktiv getroffen, so in die Richtung, sie weiterzuentwickeln.
Aber du hast dann immer so diese Grenzen, also so, okay, es ist dann doch ein bisschen technischer, aber wollen wir das dann so als eine Leistung anbieten, zum Beispiel dann, hey, wir machen auch zusätzlich Entwicklung und wir machen vielleicht auch zusätzlich Grafik oder die Kunden melden sich dann mit allen möglichen Sachen, aber dann präsentierst du dich dann mehr als eine Agentur.
Was waren so deine Entscheidungswege oder deine Gedanken, wo du dann die Entscheidung getroffen hast, okay, kompletter Fokus auf WordPress-Wartung und wie bist du dann damit umgegangen, wenn die Kunden dann doch angefragt haben, so hey, macht sie auch das oder macht sie auch das? Hast du dir neue Gedanken darüber gemacht? Eigentlich sollten wir das auch auf der Website kommunizieren, dass wir das machen, damit die Kunden das wissen, aber dann würde halt diese zielgerichtete Spezialisierung wegfallen.
Und das ist so, du hast entweder deinen Nachteil oder deinen Vorteil, aber so eine wirklich 100% richtige Lösung oder eine richtige Antwort gibt es eigentlich nicht.
Richtig, das ist und bleibt auch ein Spannungsfeld.
Also die Entscheidung damals vor zehn Jahren quasi ausschließlich Wartung anzubieten war relativ einfach.
Ich bin nun mal Informatiker und auch im Herzen Informatiker und was ich wirklich nicht gut kann, ist alles, was mit Grafik und Design zu tun hat.
Das heißt, als Webdesigner war ich relativ schlecht geeignet, weil den kreativen Prozess einer schönen Gestaltung von einer Webseite, da bin ich nicht so richtig für zu gebrauchen.
Ich kann gute Websites von außen erkennen und beurteilen, ich bin aber gar nicht so gut drin gewesen, in der Vergangenheit das selbst zu machen.
Deswegen war für mich klar, dass es immer technisch sein muss, was ich persönlich tue.
Und vor zehn Jahren war es ja jetzt auch erstmal noch eine One-Man-Show, also da ging es wirklich auch ausschließlich um mich.
Das ist aber trotzdem so ein Ding, weil natürlich der Außenstehende, der Website-Betreiber, der Kunde das gar nicht immer so eindeutig erkennen kann und so eindeutig verstehen kann, in welche Richtung man denn da läuft und was jetzt Teil des Angebots ist und was nicht.
Also das hat ja schon angefangen damit, ich habe die gehackte Webseite repariert und das war meine Leistung und mehr habe ich eigentlich nicht angeboten.
Aber der Kunde oder die Kunden sind von alleine auf mich zugekommen, haben gesagt, du kannst du mir bitte auch noch mehr machen.
Dazu gehörte dann die Wartung, also das, was wir heute klassisch auch als Wartung verstehen, mit Updates und Backups und Sicherheitsüberwachung.
Aber natürlich kamen die Kunden dann auch schon mit den ersten weiteren wünschen.
Also ich brauche hier eine Lösung in meiner Webseite für Funktion XY.
Kannst du mir mein Kontaktformular anpassen? Kannst du das ran programmieren? Kannst du mir hier die Erweiterung installieren? Kannst du mir dieses Plugin konfigurieren? Das ist natürlich immer dazu gekommen.
Und das ist auch etwas, was wir heute tun.
Also grundsätzlich verstehen wir uns als technischer Dienstleister und in dem Sinne nicht als Agentur, weil wir in aller Regel keine kompletten Website-Projekte übernehmen.
Wir machen also in aller Regel keine neuen Websites, sondern arbeiten fast ausschließlich im Bestand, also in Websites, die irgendwer anders mal irgendwann erstellt hat und führen daran Änderungen durch, Erweiterungen durch, Anpassungen durch.
Und das wiederum ist trotzdem sehr hart vernetzt mit der Wartung.
Also die Wartung ist immer unser Hauptthema, unser Kernthema.
Wir kümmern uns um den, wir nennen das gerne schon mal Applikationsbetrieb, also darum, dass die Webseite sauber und technisch gesund und vernünftig läuft und funktioniert.
Das ist unser Kernthema.
Wenn der Kunde aber dann drumherum noch weitere Anforderungen hat zur Erweiterung und zur Bestandssicherung der Webseite in irgendeinem Themenbereich, dann stehen wir da gerne zur Verfügung und machen das dann auch.
Also eben, das fängt an bei, kannst du mir das Bild tauschen, weil ich nicht weiß, wie das geht in diesem Editor und geht natürlich auch schon mal zum Anlegen von irgendwelchen Unterseiten oder eben Behebung technischer Probleme oder Installation und Konfiguration irgendeines Plugins mit irgendeinem Zusatz nutzen und endet dann häufig trotzdem auch bei Individualentwicklung.
Also wenn es wirklich irgendwelche komplexen Dinge sind, dann stehen wir auch dazu zur Verfügung, Dinge zu programmieren und in die Seite einzubinden.
Das kommt allein schon deswegen, bei 800 Seiten kann man sich das vorstellen, da gibt es auch genügend Seiten, in die ursprünglich, also vom Ersteller auch Individualentwicklung eingeflossen ist und spätestens bei zum Beispiel der Update der PHP-Version oder bei einem Major-Update von WordPress oder WooCommerce sind dann möglicherweise auch schon individual Anpassungen notwendig gewesen, also Korrekturen an den Entwicklungen, die vorher jemand anderes gemacht hat.
Das heißt, für ein sauberes Wartungserlebnis mussten wir die Sachen sowieso von Anfang an auch schon immer mitmachen.
Und deswegen gehört das bei uns grundsätzlich und klassisch dazu.
Es gibt aber trotzdem immer so Bereiche, die so grenzwertig sind.
Das hast du eben so schön gesagt.
Bei uns ist das alles, was mit Suchmaschinenoptimierung zu tun hat.
Jetzt sind wir in der Lage, Technical SEO zu machen und können da natürlich rein technisch gesehen Dinge an der Webseite ändern, damit das sauber funktioniert.
Wir sind aber keine SEO Agentur.
Also wir wollen im Allgemeinen nicht in die Analyse von Suchmaschinen-Listings einsteigen.
Wir heben da kein Optimierungspotenzial, insbesondere nicht, wenn es um Offsite-SEO geht.
Das heißt, in aller Regel ist es so, dass der Kunde mit einer SEO-Agentur zusammenarbeitet und dann möglicherweise mit einem Projektbericht, mit einem Dokument auf uns zukommt, mit Anweisungen aus der SEO-Agentur, wie denn das Technical SEO umzusetzen sei auf der Webseite.
Dann machen wir das natürlich gerne, aber es gibt in aller Regel jemand anderes, der das vorher mal analysiert hat.
Ähnlich grenzwertig alles, was so im Bereich Google Analytics Online Marketing ist.
Natürlich ist Anforderung der Kunden, dass wir uns um so eine Konfiguration wie und Erstellung eines Cookie Banners kümmern.
Das machen wir.
Cookie Banner ist quasi ein initialer und elementarer Bestandteil einer Webseite, dass das sauber geladen wird.
Alle externen Daten und so.
Das müssen wir natürlich machen.
Wenn es dann aber um erweiterte Konfigurationen geht, also quasi auch um die andere Seite, Google Analytics Einrichtung per se, das ist nicht unser Thema, weil das hat jetzt nichts mehr konkret mit der einzelnen Webseite zu tun.
Aber das sind immer so Spannungsfelder, wo sich die Grenzen da schon mal berühren und das auch nicht immer so eindeutig ist und es auch nicht immer sauber funktioniert, das hart zu trennen, wer denn da genau jetzt was macht.
Das kennen wir schon und das bleibt auch so.
Obwohl wir uns natürlich sehr eindeutig auf das Wort Wartung fokussiert haben.
Ja, die 24 im Namen ist so eine Sache.
Das habe ich mir vor zehn Jahren ausgedacht, würde ich vielleicht jetzt heute nicht mehr tun.
Aber wir decken da eine breite Palette ab, aber natürlich hast du irgendwo Limitationen, weil wir sonst tatsächlich ins Agenturgeschäft gehen würden.
Die eine Entscheidung, die ich getroffen habe, ist, dass wir keine Webagentur sind, sondern tatsächlich positioniert sind in der Technik als technischer Dienstleister.
Je mehr wir da quatschen, desto mehr habe ich das Gefühl, okay, wir machen schon was sehr, sehr Ähnliches.
Ich bin in der Freelancer-Schiene und du machst das schon mit deinem Team.
Deswegen kann ich das mega gut nachvollziehen, was du erzählst, weil die gleichen Fragen habe ich mir auch selbst gestellt über die Zeit und so weiter, wenn du halt ungefähr das gleiche machst, wirst du mit den gleichen Challenges dann auch konfrontiert und das ist halt genauso, auch wie du sagst, okay, bei Custom-Entwicklungen Updates einspielen im WordPress-Dashboard sind schon nett, aber da gibt's auch irgendwie Composer-Packages oder NPM-Packages, die da eingespielt sind bei den Plugins und bei Custom-Plugins wird das natürlich nicht gewartet, der Code so in Richtung, wenn dein Entwickler nicht aktiv dran sitzt und das ganze Zeit weiter pflegt.
Deswegen ist das dann auch so eine Sache und spätestens macht sich das bemerkbar beim Update der PHP-Version, wenn da die alten Pakete drinnen sind und die sind nicht mehr mit der neuen PHP-Version kompatibel.
Und dann hast du halt ein Problem, weil ja, das ist dann meistens ja dann auch mit einem höheren Aufwand verbunden und da würden wir dann schon so langsam, ich mein, da hätte ich noch Frage davor, aber das ist dann schon dieses Thema, was sollte man überhaupt in die Wartung mit einfließen lassen, welche Leistungen und wo sollte man dann eher so Ausnahmen setzen und das vertraglich natürlich vereinbaren, weil das ist so ein Klassiker, da muss ein Entwickler ran und dann den Code anpassen, da entstehen Aufwände, mehrere Stunden und so weiter und das ist dann natürlich mit einem Fixpreis von einem monatlichen Fixpreis, ich sag jetzt mal irgendwas zwischen 50 und 100 Euro wahrscheinlich in der Wartung, wird das nicht gut abdeckbar sein.
Aber bevor wir dann in das Thema eintauchen, hey, was sind so die professionellen Wartungsdienstleistungen und wie sollte man das alles abdecken, gibt es ja dann auch diese eine Story, dass ihr von, also so viele Websites betreut habt, dass Hostinganbieter gesagt haben, so okay, die IP-Adresse müssen wir sperren, weil da loggen sich zu viele Leute über die IP-Adresse Und kannst du die Story da noch mit einfließen lassen, was da genau die Sache war? Ja, das ist relativ einfach.
Also wir haben natürlich ein Uptime Monitoring.
Das heißt, wir haben einen Server, der ein Uptimetool laufen hat und alle fünf Minuten prüft, ob die Seite noch erreichbar ist.
Also einfach den HTTP-Statuscode prüft, ob da 200 zurückkommt.
Wie du schon gesagt hast, also wir haben etwas mehr als 800 Seiten in der Wartung und dieses Tool macht halt alle fünf Minuten eine Anfrage an alle 800 Seiten.
Jetzt liegen natürlich nicht alle 800 Seiten bei einem und demselben Hosting-Anbieter.
Wir sind da also querbeet verteilt über alle Hosting-Anbieter, die man sich so vorstellen kann und auch nicht vorstellen kann.
Aber natürlich sind Hosting-Anbieter, die in der Masse bekannt und auch beliebt sind, natürlich auch bei uns in entsprechender Menge vertreten.
Was dazu geführt hat, dass neben diesen Uptime-Requests wir natürlich auch noch sonst Connects auf die Webseiten haben.
Also wir haben ja noch ein eigenes Client-Plugin, mit dem wir unsere Wartung organisieren.
auch das kommuniziert mit unserem Management Server.
Das macht es jetzt nicht im Fünf-Minuten-Takt, aber natürlich werden da auch Daten ausgetauscht, sodass da im Laufe eines Tages über unsere ein, zwei, drei IPs, die wir da haben, doch eine ganze Menge an Abfragen zusammenkommen und ja bei beliebten Hostern dann auch in deutlicher Menge.
Und wir haben dann, wir haben ein Live ein Live-Dashboard an unserem Management-Tool, also unsere Management-Software, die nennen wir MOMAS, Monitoring and Management Server, heißt die.
Und das MOMAS ist bei uns quasi das zentrale Tool, mit dem wir alles überwachen und managen und organisieren.
Das ist eine eigenentwickelte Software.
Und die hat ein Live-Dashboard.
Bei uns im Büro hier hängt ein riesen Monitor, wo wir das die ganze Zeit drauf sehen.
Und die Kollegen, die remote unterwegs sind, haben da auch meistens einen eigenen Monitor mit diesem Bildschirm offen.
Und da sehen wir halt, wenn irgendwas passiert, wenn irgendeine Warnung eingeht, wenn irgendein Alarm ist.
Und einer der Alarme ist natürlich Website offline.
Und ja, also die Vorgeschichte zur Geschichte ist, wir sehen natürlich sehr, sehr schnell, wenn wirklich ein Hosting-Anbieter mal einen kurzen Schluck auf hat, dann knallen bei uns irgendwie 30, 40, 50 Webseiten auf offline und dann gucken wir uns das an, sehen, ah, hier sind alle der gleiche Anbieter, alles klar.
Der hat da wohl gerade ein Problem und meistens ist es ja dann ein paar Minuten später auch wieder gut.
Und in dem Fall war das auch so.
Wir sahen eine ganze Menge an Websites, die uns als offline angezeigt worden sind in unserem Live-Dashboard.
Wir haben darauf natürlich reagiert, gucken uns dann an, sagen, was ist denn das? Okay, die sind alle beim selben Anbieter.
Dann hat der Anbieter wohl Schluck auf.
Dann haben wir die Seiten in unseren Browsern per Hand aufgerufen und kamen problemlos drauf und hatten überhaupt kein Problem.
Haben uns schon gewundert, haben wir noch fünf Minuten abgewartet, aber der Offline-Status ging nicht weg.
Da haben wir uns gefragt, okay, was passiert hier? Und ja, Ende vom Lied war, unsere IP-Adressen waren bei diesem Hosting-Anbieter auf der Blocklist gelandet, weil wir zu viele Requests hatten auf diese einzelnen Seiten und auf die Gesamtheit der Seiten, auf die Gesamtheit seiner Server.
Dann habe ich da mal freundlich mit dem Support telefoniert, mal noch ein, zwei E-Mails hin und her geschickt, habe erklärt, wie wir sind und was wir tun.
Und seit diesem Tag sind wir da jetzt auch ganz offiziell auf der Whitelist, sodass das idealerweise nicht mehr passiert.
Aber das war dann schon ein spannender Fall für mich, auch in der Erkenntnis, okay, wir haben jetzt eine gewisse Relevanz irgendwie entwickelt, dass wir da schon irgendwo auffallen und sagen wir mal Luxusprobleme haben, nämlich das Luxusproblem, dass wir zu viele Seiten in der Betreuung haben von diesem Anbieter.
Ja, das habe ich auch einmal bei einer Agentur erlebt, wo oft ist ja diese Sicherheitsmaßnahme, die empfohlen wird, ihr ändert die Login-URL von deinem WordPress-Backend.
Und bei einer Agentur wird zum Beispiel oft dann der Agenturname genommen, zum Beispiel, ich weiß nicht, sagen wir mal, die Agentur heißt, äh, weiß nicht, WPAgentur24, sag ich jedes Mal, hab ich jetzt mal erfunden, und dann wird das einfach als Domainname und anstatt wp-admin wird dann zum Beispiel slash WPAgentur24 genommen und so können sich dann die Leute einloggen.
Und bei manchen Agenturen hab ich dann auch erlebt, dass das in diese Liste der Bots mit aufgenommen wurde, wo diese Brute-Force-Attacken passieren regelmäßig, dass das schon so oft bei Websites eingebunden wurde und das dann über Umwege kann man da natürlich dann rankommen, hey, was ist das dann für eine URL.
Aber da wurde das schon von den Bots mit aufgenommen und die Bots haben versucht, bei dem Website sogar über diese Login-URL automatisch diese Brute-Force-Attacken durchzuführen.
Und das sind auch solche Probleme, wo du du dir denkst, okay, es ist nett solche Probleme zu haben, weil dann hast du schon eine große Menge an Kunden und Websites, die du betreust, aber es sind trotzdem solche Probleme, an die man am Anfang halt gar nicht denkt und dann wirst du später damit konfrontiert und dafür kannst du auch nicht planen.
Und das ist ein gutes Beispiel, finde ich, für Sachen, für Challenges, die dann auf dich zukommen, von denen man immer wieder dazulernt.
Und wenn wir jetzt ein paar Schritte zurückgehen in Bezug auf die Wartungsdienstleistung, ist Und das finde ich so ähnlich, weil du entwickelst dich ja dann immer als Dienstleister weiter und du weißt nichts alles im Vorhinein, außer du hast jetzt zum Beispiel zwei Jahre bei WP Wartung 24 gearbeitet und das ganze Wissen aufgesogen und dann so, ja, jetzt kann ich selbst die Dienstleistung anbieten.
Was dann glaube ich dann am meisten der Fall ist, ist so IT Security, dass man sich dann um die Backups erst zu spät Gedanken macht, danach kommt, okay, dann hat man das abgehakt, Danach kommt zum Beispiel die Sache, okay, die Kunden rufen mich immer wieder an, dass die E-Mails bei den Formularen nicht verschickt werden können.
Okay, vielleicht sollte man ein SMTP-Plugin einrichten.
Danach kommt, hey, die E-Mails landen aber im Spam, okay, dann sollte man vielleicht ein E-Mail-Sending-Service verwenden und über die Subdomain verschicken und solche Sachen.
Also das sind solche Stufen, wo du halt immer wieder mitlernst und deswegen mache ich mir da immer wieder Sorgen, wenn es jetzt zum Beispiel, ich mag da jetzt niemanden auf die Füße treten.
Also jeder macht da, finde ich, einen Top-Job und jeder hat auch seine Professionalität im eigenen Rahmen.
Aber wenn jetzt zum Beispiel Webdesigner, die technisch, sag ich jetzt mal, weniger versiert sind als Developer, auch ein Wartungspaket anbieten mit, hey Kunde, ich kann dir auch die Website weiterhin betreuen, wo ich sie erstellt habe, zum Beispiel mit Elementor und dann kann ich dir die Website weiterhin betreuen und ich das als Wartungspaket an.
Das ist dann so, da mache ich mir immer so, okay, was passiert, wenn was schief geht? Weil früher oder später wird irgendwas schief gehen und hat man dann auch die Skills, um, keine Ahnung, den Debug-Modus in WordPress einzuschalten, um nachzusehen, hey, was ist da jetzt eigentlich los? Und da, um auf den Punkt zu kommen, was ist dann für dich, oder du kannst das auch in der Form zusammenfassen, wie ihr dann die Stufen durchgemacht habt, Oder einfach zu sagen, hey, was ist dann die Basic-Leistung, wo du siehst, okay, das wird auf dem Markt angeboten, dadurch, dass WordPress so verbreitet ist, gibt es auch relativ viel Angebot, manches ist besser, manches ist schlechter und was macht dann auch wirklich diese ganzheitliche, professionelle WordPress-Wartung aus und wie definierst du das für dich oder wie definierst ihr das für euch, wenn ein Kunde dann daherkommt und so, wieso musst du jetzt für die Wartung zahlen so quasi und das ist dann ja ich lasse dich mal auf das Thema los.
Kurze Unterbrechung in eigener Sache, weil falls dir die Podcast Episode der du jetzt gerade zuschaust oder zuhörst gefällt und du keine andere Podcast Episode mehr verpassen möchtest, weil mit den Algorithmen weiß man ja nie, manchmal spielen die einem ein Video aus und manchmal verschwindet das im Internet ether, dann würde ich dich herzlichst zu dem WP Office Newsletter einladen, weil In dem WP Office Newsletter bekommst du Recaps aus den letzten Wochen und da gibt's Zusammenfassungen von den letzten Podcast Episoden, Livestreams, Tutorials und Vlogs und ich verspreche dir eine totale Unregelmäßigkeit, weil ich bin kein Roboter, ich werde maximal eine E-Mail im Monat verschicken, wenn nicht weniger, aber dafür ist das alles schön kompakt in einer E-Mail zusammengefasst und dadurch wirst du natürlich die weiteren mega interessanten Podcast Episoden in den Postfach bekommen und keine weiteren Episode verpassen.
Falls du aber nicht so oft von mir hören möchtest, aber mich trotzdem unterstützen möchtest, dann wäre ich dir extrem dankbar, wenn du den Podcast in deiner Podcast-App deiner Wahl bewerten könntest, wenn du mir so ein Review abgeben könntest, ich weiß bei manchen Podcast-Apps ist das ziemlich versteckt, aber das wird mir enorm viel weiterhelfen um einfach neue Leute zu erreichen und wenn du jetzt z.
B.
zuschaust auf YouTube und nicht den Podcast hörst, dann hinterlass bitte einen Like, einen Kommentar und das wird mir um Welten weiterhelfen.
Den Link findest du natürlich unten in der Beschreibung.
Vielen Dank dafür und jetzt geht's weiter mit der Podcast-Episode.
Ja, also wir haben den Vorteil im Gegensatz zu einer Agentur oder einem Webdesigner, dass bei uns ganz offensichtlich ist, dass man für die Wartung bezahlen muss, weil wir halt nichts anderes anbieten.
Also bei uns kommt man nicht auf die Idee, dass wir das in irgendeiner Form mitmachen zu dem eigentlichen Angebot, sondern bei uns landet man ja in aller Regel, wenn man sich ganz bewusst dafür entschieden hat, dass man so eine Dienstleistung braucht.
Tatsächlich ist die Dienstleistung aber in den letzten, ja, also zehn Jahren wirklich, hat sich gewandelt und hat sich weiterentwickelt.
Denn also vor zehn Jahren habe ich angefangen, da habe ich erzählt, mit den gehackten Websites, da war das Hauptthema und das vordergründige Thema war Security.
Es ging also darum, die Webseite sicher zu halten.
Ich habe also gewisse Security-Best Practices in die Webseite eingebaut, habe die Backups organisiert, habe regelmäßig Updates gemacht und habe die Sicherheit überwacht.
Da sind aber schon so zwei Fallstricke drin fürs Wachstum.
Das eine sind die Backups.
Irgendwann kommt man mal auf die Idee, dass es natürlich zielführend ist, dass die Backups auf einem externen Server liegen, also nicht auf demselben Server, nicht in der Webseiteninstallation selbst, sondern wirklich extern liegen.
Ich würde jetzt sagen, für uns immer Serverstandort Deutschland oder mindestens EU.
Und wenn sich die Anzahl der Webseiten sammelt, die man da betreut, dann hat man irgendwann auch so ein Thema mit dem Speicherplatz, wo man das alles hinlegt.
Und wir sind mittlerweile bei irgendeiner zweistelligen Terabyte-Anzahl, die wir an Backup-Speicher vorhalten, weil wir natürlich auch eine gewisse Anzahl Backups für alle Seiten speichern.
Und da sind auch ein paar größere Seiten bei.
Also irgendwann hat man mal so die erste Seite, die die 20 Gigabyte überschreitet in Gesamtvolumen.
Und wenn man da dann recht häufig Backups von macht und auch noch welche vorhält, dann braucht man allein für diese Webseite irgendwie ein halbes Terabyte Backup Storage.
Da kalkuliert man am Anfang nicht mit.
Das fängt dann später an, dass man solche Baustellen hat.
Und dasselbe ist diese Sicherheitsüberwachung, das war mir immer sehr wichtig.
Klar, täglicher Malware-Scan, das bieten ganz viele an.
Was wir zusätzlich tun, ist, wir überwachen Dateiänderungen.
Das heißt, wir lassen uns jeden Tag von jeder Webseite eine Liste geben aller Dateien, die sich seit dem Vortag geändert haben, also geändert, neu hinzugekommen oder gelöscht worden sind.
Und wir analysieren diese Liste.
Und am Anfang, bei 25, 50 Seiten, habe ich das tatsächlich per Hand gemacht.
Da habe ich mir ein kleines Tool geschrieben, habe das ausgewertet und bin da jede Liste jeden Tag per Hand durchgegangen.
Es ist offensichtlich vorstellbar, dass bei 800 Seiten das nicht mehr so sonderlich gut funktioniert.
Deswegen läuft das mittlerweile halbautomatisch.
Wir haben also in unserem MOMAS, in unserem Verwaltungstool Regeln, die automatische Dinge erkennen.
Wir erkennen automatisch, wenn Updates gemacht worden sind, vergleichen das automatisch mit den Hashes, die von den Plugins zur Verfügung gestellt werden und sortieren dann also ganz vieles aus, was offensichtlich fein ist und haben dann am Ende nur eine deutlich kleinere Liste von Dateiänderungen, die tatsächlich per Hand gecheckt werden, ob es da ein Problem geben könnte oder nicht.
Aber auch das ist ein Thema, das habe ich am Anfang gemacht, weil ich es gut fand.
Ich finde es auch immer noch gut, aber man muss plötzlich mit einer komplett anderen Technik da drauf schießen, wenn man es für mehrere hundert Seiten machen will.
Und natürlich braucht man eine gewisse Erfahrung im Erkennen von Problemen, Dateiänderungen.
Also das muss man natürlich so ein bisschen irgendwie erkennen.
Ist das jetzt ein Dateiname, der für eine Schadcode-Datei steht, üblicherweise? Oder ist das jetzt, wenn die htaccess geändert ist, ist das ein Problem oder nicht? oder wenn jetzt in WP-Admin eine Datei geändert worden ist, ohne dass es ein WordPress-Core-Update gab.
Macht das Sinn? Macht das keinen Sinn? Da muss man ein bisschen Erfahrung mitbringen und ein bisschen drauf gucken können und das machen wir jeden Tag in unserem Wartungsteam.
Mittlerweile arbeiten wir da an dem Thema ganz offensichtlich und logisch mit KI-Unterstützung.
Das macht die Sache dann nochmal ein bisschen einfacher, aber das unterschätzt man am Anfang, wie sich das entwickelt.
Und ansonsten ganz grundsätzlich haben sich auch die Erwartungen gedreht.
Das heißt, vor zehn Jahren haben die Kunden tatsächlich auch eben genau nur diese Security-Themen als Wartungsbetreuung erwartet.
Heute, das hatten wir eben schon mal so kurz, sind deutlich mehr Dinge in der Betreuung im Applikationsbetrieb enthalten, nicht nur was wir anbieten, sondern was Kunden auch erwarten oder gerne als Leistung mitnehmen.
Natürlich haben wir also, wenn wir Backups machen, auch irgendein Restore-Management und wissen, ob unsere Backups auch wieder wiederherstellbar sind.
Natürlich betreuen wir Webseiten mit Staging-Systemen, wo also erst auf Staging-Systemen Updates gemacht werden, das dann abgeglichen wird und dann erst auf dem Live-System gemacht wird.
Natürlich haben wir ein Monitoring für Uptime, das habe ich eben schon erzählt.
Und natürlich überwachen wir mittlerweile auch SSL-Zertifikate und deren Gültigkeit, sodass man frühzeitig reagieren kann, wenn da irgendwie eine automatische Verlängerung nicht funktioniert oder wenn es doch noch irgendein Hosting-Anbieter ist, bei dem das doch noch irgendwie manuell passieren muss.
Da gucken wir natürlich auch drauf.
Ansonsten nennt man das im Allgemeinen ja dann Incident-Management, was wir tun.
Also wenn irgendwas auf der Webseite nicht so läuft, wie es soll, sind wir da und reagieren und das in aller Regel in relativ kurzer Zeit.
Und was wir dafür tun, ist halt unglaublich viele Dinge überwachen.
Also das ist ein Thema, das haben wir in den letzten Wochen auch sehr intensiv bearbeitet.
Also natürlich kannst du Updates überwachen und siehst, ob Updates zur Verfügung stehen.
Du hast aber natürlich auch Plugins, lizenzpflichtige Plugins, die dir das Update nicht anzeigen, wenn die Lizenz nicht gültig ist.
Also musst du auch die Lizenzen deiner Kunden Systeme überwachen und wissen, ob Plugin-Lizenzen verlängert worden sind oder verlängert werden müssen.
Wenn der Kunde die selber betreut und nicht durch uns verwalten lässt, die Lizenzen, dann sind wir halt darauf angewiesen, dass der Kunde seine Lizenzen auch sauber verwaltet und sauber erneuert und wir im Zweifel reagieren und sagen, hey, wir haben gesehen, diese Lizenz ist nicht mehr gültig, wir können aber kein Update machen, beziehungsweise wir können nicht mehr überprüfen, ob es ein Update gibt.
Oder meistens wissen wir dann logischerweise aus anderer Quelle von einer anderen Webseite oder so, dass es schon Updates gibt.
Insofern wissen wir, dass dann da irgendein Problem besteht.
Riesenthema Closed Plugins, also Plugins aus dem WordPress Repository, die mal installierbar waren und danach irgendwie geschlossen worden sind, entweder weil der Autor das so wollte oder weil es ein Sicherheitsproblem darin gab.
Ist ja immer noch ein leidiges Thema in WordPress, dass WordPress in der Installation das nicht anzeigt.
Also natürlich, wenn man ins Repository geht, ins Plugin Repository, da nach dem Plugin sucht, sieht man, dass es geschlossen worden ist und nicht mehr zur Verfügung steht.
Aber in der eigenen WordPress-Installation nicht.
Das heißt, wenn man Pech hat, hat man da so ein Plugin installiert, das es schon seit irgendwie Monaten oder Jahren nicht mehr gibt und man weiß es nicht und man kriegt es nicht mit und potenziell ist das einfach auch eine Sicherheitslücke.
Also überwachen wir das WordPress Repository und die genutzten Plugins darauf, ob das geschlossen worden ist und müssen dann mit dem Kunden darüber reden, was wir dann mit dem Plugin machen.
Selbiges gilt für deaktivierte Plugins oder Plugins, die längere Zeit kein Update erhalten haben.
Bei uns ist die Grenze immer so zwei Jahre, maximal drei Jahre.
Plugins, die länger als zwei, drei Jahre kein Update bekommen haben, muss man darauf reagieren und muss man austauschen.
Auch das überwachen wir und reagieren darauf.
Und also da gibt es noch so viele andere Kleinigkeiten, wo man dann drauf achten muss, um eine Seite eben sauber in Betrieb zu halten und wirklich regelmäßig dabei zu sein.
Über die Custom Plugins haben wir ja eben schon ganz kurz gesprochen.
Also wenn da Individualentwicklung drin ist, dass man dann da zusätzlich drauf achten muss.
Und das ist natürlich, also das sammelt sich.
Und da hat plötzlich ganz viele verschiedene Listen, die man sich anguckt und jeden Tag prüfen muss, ob da nicht irgendwas dazugekommen ist.
Ganz viele APIs, die man abfragen muss.
Wir haben auch eine Sicherheitslücken-Datenbank, die wir abfragen, also so eine Vulnerability-Database, Patch-Stack in unserem Fall, mit denen wir zusammenarbeiten, sodass wir auch immer mitkriegen, wenn irgendwo Sicherheitslücken, möglicherweise sogar Zero-Day-Lücken in eine Liste kommen und das bei uns installiert ist, auf irgendeiner Webseite, dann reagieren wir da drauf.
Wir haben, ich glaube irgendwas um die 2000 verschiedene Plugins auf den Seiten insgesamt installiert, die also in dieser Form irgendeine Form der Überwachung von uns bekommen.
Und natürlich kommen die Kunden auch auf die Idee, dass Seiten immer komplexer werden und natürlich ein Update nichts kaputt machen soll.
Und natürlich ist das unser Anspruch, auch nichts kaputt zu machen.
Bei immer komplexer werdenden Websites, ist aber auch das immer ein immer komplexeres System.
Also, wie stellen wir denn fest, dass alles auf der Webseite noch korrekt funktioniert, nachdem wir irgendwelche Updates gemacht haben? Klar, wir überwachen PHP-Fehler und sehen, wenn irgendwo ein 500er auftaucht und können darauf reagieren.
Aber wenn es jetzt nicht irgendwie sowas fatal error mäßiges ist, wird es plötzlich schwierig.
Und was haben wir gemacht? ist noch gar nicht so lange her.
Wir machen jetzt Screenshots von jeder Webseite und täglich und haben dann also ein Archiv von Screenshots von der Webseite, meistens Startseite oder irgendwelche relevanten Unterseiten, nicht alle Seiten, das schaffen wir nicht, und können so also wie so ein bisschen wie so ein Webarchiv zurück in die Vergangenheit gehen und gucken, wie sah die Seite denn aus, wie sieht sie jetzt aus und haben natürlich eine automatische Differenzerkennung drin, die anschlägt, wenn eine Differenz von mehr als x Prozent drin ist, sodass die Kollegen sich das dann angucken und sagen, naja, ist das jetzt gewollt, ist das nicht gewollt, ist da was kaputt gegangen, soll das so sein, weil es könnte ja auch eine gewollte Änderung sein.
Also auch da haben wir aufgerüstet, auch da darf man nicht vergessen, wenn man von 800 Seiten mehrere Screenshots am Tag macht und die 30 Tage lang lagert, dann hat man auch da plötzlich wieder so ein Storage-Thema.
Also da kommen auch einige Gigabyte bis Terabyte zusammen, die man da an Screenshots irgendwie verwaltet.
Man braucht natürlich auch irgendein System, um die wieder zu finden.
Und insgesamt ist dieses System total hilfreich.
Dominik, das wirst du kennen.
Es gibt auch schon mal den einen oder anderen Kunden, der auf die Idee kommt, dass jetzt auf der Seite was kaputt ist und das definitiv ein Update gewesen sein muss und wir da definitiv was kaputt gemacht haben und am Ende kommt halt raus, dass es irgendeine Änderung war, die der Kunde selbst durchgeführt hat, die dann in einem Seiteneffekt zu irgendeiner Fehldarstellung auf einer anderen Seite führt oder so.
Dafür haben wir einen Activity-Log.
Wir tracken also komplett die Webseiten und die Änderungen, die auf den Webseiten durchgeführt werden, damit auch wir da wissen, wann wer was getan hat.
Wir haben das Update-Log.
Das heißt, wir stellen also auch fest, wenn der Kunde schon mal selber ein Update macht, ein Plugin installiert, ein Plugin entfernt oder sonstige Dinge tut, die eigentlich unser Job sind.
Aber manchmal passiert das so parallel.
Dann haben wir aber auch das in einer Liste drin und können das nachvollziehen, wann ist hier was passiert.
Und der neueste heiße Scheiß ist jetzt, dass wir nicht nur Screenshots machen, sondern auch Funktionstests.
Also der ein oder andere wird Playwright kennen.
Das ist ein ein Tool, mit dem man Oberflächentests machen kann, also quasi einen Browser steuern kann und Tests durchführen kann.
Auch das tun wir in verschiedenen Fällen, um Fehlerquellen auszuschließen, Funktionalitäten zu testen und Settings zu testen.
Also da hat sich der Umfang dessen, was wir tun, um festzustellen, dass eine Webseite immer noch funktioniert und nichts kaputt ist, in den letzten Jahren doch deutlich erweitert, weil es auch immer komplizierter wird, das ganze Thema zu verwalten und betreuen.
Webseiten werden immer komplizierter, die Ansprüche werden immer höher und die Notwendigkeiten, also Story von heute Morgen oder auch aus letzter Woche.
Wir haben über unsere Security Tools diverses abgeschaltet auf Webseiten, insbesondere auch mit einer bestimmten htaccess-Konfiguration, wo wir sicherstellen, dass bestimmte Aufrufe nicht möglich sind.
Unter anderem blockieren wir alle Aufrufe von TXT-Dateien im Docroot der Webseite, bis natürlich auf die robots.
txt.
Und jetzt kamen die Kunden um die Ecke und hatten das Problem, dass sie eine LLMs.
txt, dieses neue Format für Steuerung von Large-Language-Models in eine Dockroot gelegt hat, aber diese URL nicht aufrufen konnten oder nicht aufrufbar war, eben weil sie durch unsere htaccess-Einstellung blockiert wurde.
Und ja, jetzt steht seit gestern in unserer Doku drin, dass wir bei allen neuen Wartungseinrichtungen diese Datei dann auch ausschließen, so dass sie jederzeit aufrufbar ist.
Haben aber jetzt eine Liste von mehreren hundert Websites, die bei uns in der Betreuung sind, wo wir dieses eine Feature jetzt in den nächsten Tagen und Wochen nachziehen müssen, dass auch da eine LLMs.
txt erlaubt ist und möglich ist.
Und so wird es immer wieder neue Anforderungen geben und immer neue Themen geben, auf die wir reagieren müssen und wo wir unseren Wartungsservice im Prinzip erweitern, ergänzen und anpassen müssen.
Andere Themen ist natürlich sowas wie Performance, Google PageSpeed, Performanceentwicklung.
Wie sieht das aus, wie entwickelt sich die Performance, überwachen wir mittlerweile auch, messen also die Werte und können darauf reagieren, wenn der Wert also plötzlich oder nach und nach schlechter wird, ohne dass da jetzt Contentänderungen stattgefunden haben, sodass wir auch darauf reagieren können.
Wichtig für uns ist immer, das ist natürlich nicht zwingend alles im Standardwartungstarif enthalten, insbesondere nicht die Behebung dieser Probleme.
Für uns ist aber wichtig, dass wir die sind, die das alles überwachen, die die Webseite im Blick haben.
Wir erkennen das alles, wir sehen das idealerweise, können dann mit dem Kunden in Kontakt treten und dann individuelle Lösungen vereinbaren, je nachdem, was da gerade Sinn macht und wie das aussieht.
Im Idealfall sage ich, weil natürlich je nachdem, was es für einen Fehler gibt und welches Problem es gibt, rutscht uns das natürlich auch durch, weil das etwas ist, was man mit den Standardmethoden irgendwie dann doch nicht so richtig erkennen kann und nur in einem ganz besonderen Spezialfall auftritt, nur unter einem bestimmten Browser oder sonst irgendwas, dann wird es natürlich für uns auch schwierig.
Dann kriegen wir vielleicht auch nicht jede kleinste Änderung ganz korrekt mit, aber wir versuchen es.
Und gerade mit diesen Funktionstests, also mit diesen Playwright-Tests, haben wir eine Chance, dann auch wirklich komplexere Spezialfälle an Analysen abzudecken, sodass man sagt, okay, da ist bei einem Update schon mal was schiefgegangen, danach war das Problem so und so und ab jetzt testen wir das regelmäßig bei dieser Webseite nach diesem Update, dass diese Funktion, dieses Kontaktformular, in unserem Fall ganz häufig diese Shop-Funktionalität dieser Warenkorb weiterhin funktioniert.
Ja, da waren jetzt ziemlich viele Sachen dabei und das können wir uns ein bisschen entpacken und da ist mir jetzt irgendwie bewusst geworden, also das, woran du halt am Anfang nicht denkst, so hier, es klingt mega cool, ihr betreut 800 plus Websites, aber wenn das stimmt, wenn dann irgendwas in der htaccess geändert gehört, dann muss man das halt bei 800 plus Websites nachziehen, wenn das alles überall eingespielt werden soll und das ist halt etwas, was man nicht an einem Vormittag machen kann einfach und erledigt, sondern da muss sich wirklich jemand da hinsetzen, das machen und das ist wahrscheinlich auch nicht so eine super amüsante Aufgabe, da jetzt immer Datei aufzumachen, eine Zeile zu ändern, nächste Website.
Datei aufzumachen, eine Zeile zu ändern, eine Zeile zu ändern, nächste Website.
Die Entwickler unter den Zuhörern werden sich jetzt beschweren und sagen, naja mit einem ordentlichen Deployment ist das alles überhaupt gar kein Problem.
Und das würde auch stimmen, wenn wir dazu die Chance haben.
Aber das Entscheidende bei uns ist, dass wir tatsächlich mit vielen modernen Entwicklermethoden nicht gut arbeiten können, weil wir in aller Regel auf das Hosting des Kunden keinen Einfluss nehmen.
Das heißt, der Kunde hostet da, wo er hostet und wenn es nicht das Allerschlimmste ist, dann belassen wir es auch da.
Das heißt, wir müssen aber in aller Regel mit den Möglichkeiten leben, die uns der Kunde zur Verfügung stellt, wie wir Zugriff auf die Webseite haben.
Ganz klassisch, irgendwie eine FTP-Verbindung.
Das heißt, die allerwenigsten Kunden sind bei uns selbst direkt gehostet, sodass wir irgendwie serverseitig wirklich einen Zugriff hätten, der uns einen klassischen Deployment-Ablauf irgendwie zulässt.
Wenn man das hätte, könnte man sagen, ja gut, dann musst du jetzt einfach nur für alle Seiten die neue htaccess-Version ausrollen oder so.
die Chance hätte man dann.
Bei uns geht das tatsächlich nicht, weil wir unter Umständen wirklich sehr limitiert sind in der Art und Weise, wie wir auf die Webseiten zugreifen.
Und ja, dann musst du das genauso tun, wie du das beschrieben hast.
Das ist nicht wirklich spannend, das macht nicht wirklich Spaß, ist jetzt aber auch selten in dieser Art und Weise, dass es wirklich so dann ausrollst.
Also auch diese LLMs.
txt, das ist jetzt kein Beinbrecher, wenn es jetzt nicht auf allen 800 Seiten nächste Woche ausgerollt ist, weil im Zweifel meldet sich der Kunde ja und sagt, hey, ich will die installieren.
Könnt ihr mir dabei helfen? Und dann ist es natürlich ein 5-Minüter.
Also das gilt übrigens ganz genauso für die PHP-Version, die wir natürlich regelmäßig aktualisieren und immer auf einen aktuellen Stand halten, damit wir keine veralteten PHP-Versionen in den Systemen haben.
Kann man aber mal ausrechnen.
Also wir haben 365 Tage im Jahr.
Wir haben 800 Websites, die alle bei irgendeinem Hoster gehostet sind.
Jeder Hoster hat irgendwie ein anders geartetes Backend, wo man die PHP-Version auf eine andere Art und Weise einstellt.
Das heißt, wenn wir innerhalb eines Jahres alle unsere Kundenwebsiten überprüfen wollen und die PHP-Version auf den richtigen Stand bringen wollen, dann müssen wir quasi jeden Tag zwei, drei Webseiten uns anschauen und da die PHP-Version schon korrigieren, weil wir sonst innerhalb eines Jahres den Turnus gar nicht schaffen, um alle Seiten immer auf den guten Stand zu halten.
Ja, na voll.
Und auch solche Sachen, die nicht funktionieren einfach weil WordPress so in die Richtung, also dadurch, dass es auf verschiedenen Hosting-Anbietern liegt, dadurch, dass jede Website individuell ist, schaut auch unter der Haube jede htaccess-Datei anders aus.
Manchmal gibt es irgendwelche Redirects, manchmal irgendwelche Caching-Regeln, manchmal gibt es ein Apache, manchmal einen Nginx mit einem Proxy oder was auch immer dann dabei ist und so weiter und wenn du da einfach stur auf allen Websites eine generische htaccess-Datei reinklatscht oder eine aktualisiert, dann wird garantiert bei den meisten Websites irgendwas schief gehen.
Und wenn das irgendwer zuhört und sich denkt so, boah ihr macht ja so viel, also ihr habt so viele Monitoring-Systeme, habt so viele Prozesse, die sich schon etabliert haben, ihr habt das entwickelt, ihr habt diese Schnittstelle eingebunden, das, das, das und so weiter.
Das haben ja nicht mal Agenturen so in die Richtung, also meisten Agenturen, die haben das nicht, weil das ist auch nicht deren Hauptfokus.
Und das ist halt euer Privileg, dass ihr euch da wirklich zu 100% darauf fokussieren könnt und das so weit optimieren könnt oder so weit ausreizen könnt, die Prozesse oder die Qualität und so weiter, dass es dann schon wirklich Sinn macht, solche Tools zu entwickeln, weil das ist ja eure interne Entwicklung, wo ihr dann die Zeit reingesteckt habt, damit das halt einfach so rund läuft mit Monitoring und wenn da jetzt jemand zuhört und so weiter, das ist nicht, ich sag jetzt mal, Standard bei den meisten Agenturen, so viele Monitoring-Geschichten einzubauen.
Die meisten haben ein Uptime-Monitoring, vielleicht dann auch, wenn es gut geht, ein Frontend-Monitoring-Tool, aber das schon, wenn das wirklich schon fortgeschritten ist, das Ganze.
Und bei den meisten Seiten war es das, bei den meisten Agenturen.
Also ich sage jedes Mal als Zuhörer, Zuhörerin, fühlt es euch da nicht schlecht, wenn ihr das nicht in dem Ausmaß bei euch implementiert oder integriert habt, das überhaupt nicht.
Das war mega interessant zu hören, wie ihr das macht, weil ihr habt da wirklich die Möglichkeiten, da wirklich solche Systeme euch zu bauen und das einmal so zu implementieren, wie das im Idealfall existieren sollte, so in Richtung.
Und da mag ich mich auch nicht aus dieser Gruppe rausnehmen, also ihr habt dabei viel fortgeschrittenere Monitoring-Systeme, als ich das bei mir habe intern, einfach weil ich als eine Person oder jetzt zwei Personen halt nicht die Manpower habe, um das zu entwickeln, so in die Richtung und das ist dann immer so die Realität mit denen halt viele konfrontiert werden, so ich würde gerne da so diese Prozesse etablieren oder ich würde diese Prozesse da irgendwie implementieren und das Ganze, aber dann fehlt einfach einem oft die Zeit und ich nehme an bei euch hat sich das dann entwickelt, wo dann mehr Mitarbeiter dazugekommen sind, wo halt wirklich die Manpower dazu da war, wo sich einer wirklich da fokussieren konnte und da auch immer die meisten Mitarbeiter, die betreuen wahrscheinlich die regulären Kunden und die Anfragen und so weiter, aber dadurch, dass schon so viele Leute dabei sind, gibt es natürlich prozentual gesehen, sagen wir mal, 10% von 10 Mitarbeitern ist ein Vollzeit-Mitarbeiter, der sich dann darum kümmern kann.
10% der Zeit von einem Freelancer sind, ich weiß nicht, vier Stunden die Woche, wenn es gut geht.
Und da kannst du halt nicht so viel machen.
Und ich nehme an, das hat sich bei euch halt alles etabliert halt über die letzten Jahre, wo halt wirklich mehr Mitarbeiter dazugekommen sind.
Ja, auf jeden Fall.
Also das ist jetzt, also so habe ich auch vor zehn Jahren nicht angefangen.
Also da habe ich auch mit dem angefangen, was wir alle irgendwie so ein bisschen erwarten.
Da habe ich am Anfang noch nicht mal ein Management Tool gehabt, um jetzt irgendwie die Updates zu verwalten.
Das kam dann relativ schnell, aber natürlich entwickelt sich das.
Und auch bei uns gab es Situationen, in denen die Qualität der Wartung eben dann nicht so war, weil wir dann auch erst mal nachsteuern mussten.
Also es gab auch Zeitpunkte, wo man feststellte, auf die Art und Weise, wie wir das im Moment machen oder mit der, mit dem Überwachungsapparat, den wir da im Moment haben, reicht es jetzt bei der Anzahl von Webseiten, die wir in der Betreuung haben, nicht mehr aus.
Da müssen wir jetzt nachsteuern, da müssen wir uns mal was Neues überlegen.
Das war so, ja, 2019, 2020 rum, wo eben die erste Entwicklung für dieses MOMAS entstanden ist, also für unser eigenes Management Tool, weil die bis dahin laufenden Prozesse, die ich da so als Einzelkämpfer hatte, auch schon an ihre Grenzen kamen.
Und mit diesem Tool, das ist eine Eigenentwicklung auf Laravel-Basis, da bauen wir mittlerweile ganz wild alle möglichen Features ein.
Und auch das Ding hat sich in den letzten knapp zwei Jahren nochmal deutlich entwickelt.
Also all die Sachen, von denen ich eben erzählt habe, die wir jetzt überwachen, da ist das Allermeiste von den letzten zwei, drei, vier Jahren auch hinzugekommen erst.
Als sich das bei uns in Größenordnung entwickelt hat, wo man eben mit ein, zwei, drei Mitarbeitern das auch per Hand nicht mehr überblicken kann und auch gar keine Chance mehr hat, das sauber zu finden und zu erkennen und wo dann immer häufiger Kunden um die Ecke kamen und die Probleme auf ihrer Webseite quasi selber gefunden haben und wie sie nur noch behoben haben, aber wir unseren Job nicht mehr erfüllt haben, proaktiv die Sachen zu sehen und uns darum zu kümmern, dass die Webseiten funktionieren.
Und am Ende ist das immer noch ein Prozess, also wir sind da nicht fertig mit.
Wir haben letzte Woche einen internen Workshop gehabt, wo wir über die nächsten Features unserer Wartung gesprochen haben und da gibt es immer Ideen, da gibt es immer Möglichkeiten, es gibt auch immer wieder neue Themen, die irgendwie auffallen und da wird es immer weitergehen.
Also ganz spannend aktuell ist, wir haben häufiger das Problem, dass wir vom Kunden FTP Zugangsdaten zur Verfügung gestellt bekommen, die dann unter Umständen über einen längeren Zeitraum nicht benötigen, weil alles funktioniert und wir nicht auf Dateiebene eingreifen müssen und dann gibt ein Problem auf der Webseite, wir wollen uns einloggen und die Daten stimmen nicht mehr und dann haben wir keinen Zugriff und dann verzögert sich die Zeit zwischen Problemerkennung und Problembehebung, weil wir jetzt erstmal mit dem Kunden in Kontakt treten müssen, neue Zugangsdaten anfordern müssen und dann uns neuen Zugriff zum Server verschaffen müssen.
Und daraus ist jetzt ganz konkret letzte Woche die Idee entstanden, dass wir mit unserem Tool jetzt eine Funktion einbauen werden, wo wir die FTP-Zugangsdaten dann im System hinterlegt haben.
Das haben wir sowieso.
Aber dann das regelmäßig, einmal pro Woche oder so, den FTP-Zugang testen werden, damit wir wissen, dass der weiterhin für uns funktioniert und dass, wenn dann ein konkreter Fall eintritt, ein Notfall, dass wir dann eben keine Zeit verlieren, sondern wissen, unsere Zugangsdaten auf Dateiebene zum Server, also FTP oder SSH oder was auch immer, sind funktionstüchtig und laufen noch so und wir können sie spontan nutzen, damit wir keine Zeit verlieren.
Also neue Features fallen uns auch immer wieder ein, die auch aus dem Tagesgeschäft kommen.
Also das ist ein ganz konkretes Problem, dass diese FTP-Zugangstaten ganz häufig plötzlich nicht mehr stimmen oder der User gelöscht ist oder sonst irgendwas.
Und dass wir da dann darauf reagieren und sagen, okay, lass uns da was einbauen und ja, natürlich jetzt in der aktuellen Konstellation haben wir eben die Chance zu sagen, okay, wir haben da ein Problem erkannt, das würden wir gerne optimieren, da bauen wir uns jetzt selber was ein und haben dann logischerweise auch zumindest auf absehbare Zeit dann irgendwie die Ressourcen dazu, das dann auch zu tun und dadurch dann wieder den nächsten Schritt zu machen, um dann wieder zu sagen, okay, Wenn das nächste Mal so ein Problem auftritt, dann wissen wir wenigstens, dass der FTP-Zugang sofort zur Verfügung steht und dann geht da nicht der Tag verloren in der Kommunikation mit dem Kunden.
Und wenn das System vorher mal anschlägt, dann haben wir halt außerhalb eines Notfalls die Möglichkeit, mit dem Kunden zu sprechen und den FTP-Zugang wiederherzustellen.
Ja, und das, was ich finde ich auch interessant finden würde zu dem Ganzen ist halt das Verkaufen von den Wartungspaketen, weil das ist glaube ich auch so ein eigenes Ding für sich.
Was sind dann so die Preise und wie sollte man das überhaupt bepreisen, weil da, was ich da für mich herausgefunden habe, ist einfach man sollte so den eigenen Stärken spielen so in Richtung, weil das haben wir, das hast du vorher auch erwähnt, so hey, was passiert, wenn irgendwas schief geht, Fehlerbehebung, Problembehebung, ist das dabei oder ist das nicht dabei, weil das sind auch zusätzliche Kosten, die entstehen können, Plugin-Lizenzen, will man das dem Kunden auch mit anbieten im Paket oder soll sich der Kunde selbst um die Lizenzen kümmern und vor allem bei WooCommerce-Shops, wenn dann irgendwelche Buchungssysteme im Einsatz sind und so weiter, das sind so Einzellizenzen, die dann schon teuer werden können und schon ein paar Monate von dem Wartungsumsatz auch in Anspruch nehmen können, wenn man das nicht eingeplant hat und das was ich halt für mich herausgefunden habe, dass man einfach die eigenen Stärken damit einbeziehen soll, ist, hey, wenn du zum Beispiel jetzt viele Agentur-Lizenzen hast von einem Plugin, kannst du zum Beispiel eine Liste machen von Standard-Lizenzen, die inkludiert sind und schon ist es ein Benefit, den du dann auch zu dem Preis dazu rechnen kannst.
Bei mir ist es zum Beispiel so, ich bin relativ schnell und gut im schnellen Fehlerbeheben in WordPress.
Deswegen, wenn dann irgendwas nicht gut verläuft oder irgendwas schief geht oder irgendwas kaputt geht, kann ich das bei mir mit relativ wenig Aufwand beheben.
Deswegen habe ich dann zum Beispiel bei mir die Fehlerbehebung mit dabei und dadurch kurble ich halt den Preis nach oben, weil dann mehr einfach dabei ist, also so quasi so ein Fehlerbehebungsschutz und so weiter.
Muss nicht dabei sein, weil wenn zum Beispiel jemand diese Skills nicht hat, wäre es irgendwie sinnlos, das anzubieten, weil dann musst du das auf eigene Kosten decken, halt einen Developer irgendwie anschreiben, das verzögert sich in der Zeit, wie du jetzt gesagt hast, mit dem Serverzugang.
Dann muss der Developer halt sagen, hey, ich brauche da einen Serverzugang und dann kann das zwei Tage später noch immer nicht behoben sein und die Website funktioniert nicht.
Und in Bezug jetzt auf halt das Verkaufen von Wartungspaketen, auf die Bepreisung von Wartungspaketen, welchen Zugang hast du zu dem Ganzen und was würdest du den Leuten Ah, das ist ein großes Fass, was du aufmachst.
Das ist nämlich ganz kompliziert.
Es hängt halt damit zusammen, dass die Abgrenzung gar nicht immer so einfach ist.
Wo hört die Leistung auf, wo fängt sie an? Also wir zum Beispiel sagen, wenn eine Webseite, die bei uns in der Wartung ist, gehackt wird, dann geht das auf unsere Kosten.
Also die Reparatur der Seite ist unser Ding, weil wir ja quasi ein Sicherheitsversprechen geben mit unserer Überwachung und unseren Maßnahmen, dass Webseiten nicht gehackt werden können sollen.
Jetzt wird mir jeder, der davon Ahnung hat, sagen, dass natürlich ein 100%-Schutz niemals besteht und das ist auch vollkommen richtig.
Das heißt, ein Restrisiko für uns bleibt immer, dass trotzdem irgendwie eine Webseite gehackt wird.
Das gehen wir aber ein.
Jetzt gibt es aber natürlich so einen Sonderfall, auch ein Klassiker.
Wir haben eine Webseite bei uns in der Wartung und im selben Webspace, im selben Account befindet sich noch eine zweite Webseite.
Diese zweite Webseite ist nicht bei uns in der Wartung und diese zweite Webseite ist schlecht betreut und die wird gehackt und aus dieser Webseite greift Schadcode auf Dateiebene, also nicht von außen über einen HTTP-Zugriff oder so, sondern auf Dateiebene, greift der Schadcode auf die anderen Installationen, also auf den kompletten Account über und plötzlich befindet sich auch Schadcode in der Seite, die wir betreuen.
Durch unsere Dateiüberwachung finden wir den relativ zügig und erkennen den, dass er da ist, können natürlich im allerersten Schritt trotzdem nicht sagen, woher er herkommt und haben erstmal einen Schadcode im System.
Wir würden jetzt grundsätzlich sagen, naja, Schadcode im System ist unser Problem, beheben wir auf unsere Kosten.
Wenn wir dann aber feststellen, dass es aus dem Zweitsystem kommt, was irgendwie daneben lag, was nicht unter unserer Betreuung ist, dann hatten wir keine Chance, das zu verhindern.
Und dann ist es schon wieder so ein Grenzfall.
Dann ist es schon wieder schwierig.
Dann müssen wir eigentlich sagen, ja, es liegt an diesem zweiten System, das ist Schuld, da hatten wir jetzt keinen Einfluss drauf.
Also können wir das natürlich alles hier gerne reparieren und natürlich auch dieses zweite System irgendwie reparieren, weil wenn das da gehackt rumliegt, ist die von uns betreute Seite im Tagesrhythmus wieder neu infiziert.
Aber das muss man dann im Individualfall mit dem Kunden besprechen.
Und übrigens als Schwenk an dieser Stelle, dringender Rat, eine Webseite pro Account, nicht mehrere Webseiten in einem Account liegen lassen, weil dann kann sowas nicht passieren.
Wir haben schon Kunden gehabt mit 10, 12, bitte? Ja, aber da muss man sich ja zusätzlich Hosting-Pakete buchen.
Das geht ja nicht.
Ja, oder ein Haus der Wellen, bei dem man Subaccounts erstellen kann, sodass man das trotz eines Pakets dann trotzdem aufteilen kann.
Die gibt es ja auch.
Wir haben schon einen Kunden gehabt mit zehn, zwölf Webseiten in einem Paket, in einem Account.
Davon ist eine gehackt worden, dann waren aber alle zwölf gehackt.
Und ich meine, zwölf Webseiten enthacken, wenn es keine sauberen Backups gibt, man nämlich nicht weiß, wann der Hack ursächlich entstanden ist und deswegen auf die Backups nicht zurückgreifen kann.
Hast du Spaß? Also das kostet auch richtig Geld.
Da sind die zusätzlichen Hosting-Kosten nicht so entscheidend.
Aber gut, das ist ein anderes Thema.
Also quasi, wenn irgendwer günstig kauft, kauft er zweimal und in dem Fall war es zwölfmal.
Ja, genau.
Ja, das stimmt.
Man muss natürlich darauf achten.
Das ist vielleicht auch nicht so einfach und wenn man in mehreren Accounts arbeitet, ist das vielleicht ein bisschen umständlicher.
Aber im Nachhinein ist es für alle Beteiligten zielführender.
Aber da gibt es solche Grenzfälle natürlich.
Wir machen das an verschiedenen Stellen jetzt so, also diese Fehlerbehebung ist auch immer dann in unserem Wartungstarif inkludiert, wenn wir den Fehler quasi selber verursacht haben.
Also wir garantieren das, wenn wir Updates machen, dass die Seite danach noch funktioniert.
Sollte sie da nicht funktionieren oder irgendwelche Fehler entstehen, dann beheben wir die.
Und entweder ist das irgendeine Kleinigkeit, die man wirklich genauso beheben kann, so wie du es eben auch geschildert hast.
Oder im schlechtesten Fall rollen wir das Update zurück.
Das heißt, wir spielen das Backup ein des Plugins, sodass wir das Plugin wieder auf die alte Version zurückstellen, dass mindestens das wieder hergestellt ist und sauber funktioniert, so wie es vorher auch funktionierte.
Und dann muss man sich mit dem Kunden unterhalten und feststellen, okay, also warum funktioniert es denn jetzt nicht mehr? An was hängt es denn? Ist das zum Beispiel irgendwas im Custom-Theme, im Custom-Plugin, irgendwas, was da parallel quer schießt oder war das ein Major Update von dem Plugin und das Plugin hat ganz viele Funktionalitäten geändert oder sind andere Plugins noch installiert, die mit diesem neuen Version dieses Plugins jetzt noch nicht kompatibel sind und wir müssen einfach nur eine Woche warten, bis alle anderen Add-on Plugins sich auch aktualisiert haben.
Das muss man dann klären.
Je nachdem, wie das dann ausgeht, ist das dann aber eine Individualanpassung, dass man es gerade wieder hinbiegt.
Und dann ist das halt auch nicht im Wartungsvertrag inklusive.
Aber was wir immer garantieren, ist, dass wir die Seite nicht kaputt stehen lassen.
Also wir machen immer irgendwas, damit die Seite weiter funktioniert.
Und im allerschlechtesten Fall ist es halt dieser Rollback.
Was die Lizenzen angeht, Lizenzen ist ein unendliches Thema, Das führt andauernd zu Problemen.
Ich bin ein großer Freund davon, dass die Kunden Zugriff auf ihre eigenen Lizenzen haben.
Das heißt, selbst wenn wir im Namen der Kunden Lizenzen erwerben, was wir tun, wir betreuen und verwalten Lizenzen für Kunden, dann ist das nicht so, dass ich irgendwie eine Agenturlizenz irgendwo liegen habe und dann Anteile dieser Agenturlizenz an einzelne Kunden weiterverkaufe, was möglicherweise sowieso gar nicht erlaubt ist, sondern jeder Kunde.
.
.
das stimmt.
Danke, dass du das erwähnt hast, weil das habe ich mir dann auch gedacht, so, ok, da sollte man bei den Verträgen der Lizenzen nachschauen, ob das dann wirklich so in Ordnung ist oder nicht.
Ja, genau.
Also wir kaufen tatsächlich einzelne Lizenzen für jeden Kunden und jeder Kunde hat seine eigene einzelne Lizenz, führt dazu, dass wenn der Kunde sagt, ich habe keinen Bock mehr auf euch, ich möchte woanders hingehen, dass es überhaupt gar kein Problem ist, ihm die Lizenz auszuhändigen, indem wir einfach nur die E-Mail-Adresse des Accounts auf den Kunden umstellen, dann hat er Vollzugriff, dann ist es seine Lizenz.
Das heißt, wir verwalten die tatsächlich rechtlich gesehen ausschließlich und es ist eine Lizenz, auf die der Kunde voll Zugriff hat.
Trotzdem ist es so, dass wir in unserem Plus-Tarif tatsächlich Lizenzen mit anbieten, die quasi im Tarif inkludiert sind.
Also sie werden nicht einzeln verkauft, sondern sie sind quasi inkludiert im Tarif.
Das sind bei uns dann auch Agenturlizenzen.
Da steht aber dann quasi vertraglich schon von Anfang an fest, dass im Rahmen unseres Plus-Tarifs diese Lizenzen genutzt werden dürfen und natürlich in dem Augenblick, wo eine Wartung mit uns dann beendet wird oder eben dieser Tarif nicht mehr genutzt wird, dann auch die Lizenzen nicht mehr zur Verfügung stehen.
Das managen wir dann tatsächlich auch über Agenturlizenzen.
Das ist einfach ein schönes Goodie, was man dazugeben kann, wenn man die Lizenzen als Agentur sowieso schon hat, dann kann man da sagen, komm, die können wir jetzt mit anbieten, da muss man jetzt dem Kunden nicht noch mal extra was in Rechnung stellen.
Was jetzt sonst Fehlerbehebung oder allgemeine Arbeiten angeht, bieten wir auch so Monatskontingente an, haben das auch in einem Tarif direkt mit drin, also auch in diesem Plus-Tarif.
Da sind einfach 30 Minuten beliebiger Arbeiten pro Monat inkludiert, egal was.
Also das muss jetzt nicht mal eine Fehlerbehebung sein, das kann jetzt auch, tauschen wir mal das Bild sein oder installieren wir mal das Plugin, machen wir mal folgende Konfiguration.
Solange das in 30 Minuten passt, übernehmen wir das und dann ist das inkludiert, ohne dass da irgendwas an zusätzlichem Geld fließen muss.
Ansonsten versuchen wir mit unserem Basistarif wirklich die Basisleistung abzudecken.
Also das ist wirklich der Kern der Wartung, Security, Updates, Backups, Sicherheitsüberwachung.
Das ist quasi das zentrale Element, ohne dass eine eigentlich nicht funktioniert.
Das ist quasi dann die Basisleistung im Basistarif und dann gibt es halt ergänzende Tarife bei uns, die dann noch ein bisschen mehr Richtung Performance und sonstige weitere Überwachung enthalten, die wir dann ergänzen.
Diese ganzen Überwachungsthemen, die ich eben erwähnt habe, also was wir alles kontrollieren, damit eine Webseite korrekt funktioniert, das ist im Allgemeinen auch im Basistarif enthalten.
Wenn wir Richtung Screenshots und Playwright Tests gehen das natürlich nicht, weil das teilweise dann auch sehr individuelle Entwicklungen sind, die auch angefertigt werden müssen.
Also wenn wir über individuelle Playwright Tests für spezifische Funktionen von Webseiten reden, dann geht das nicht, ohne das auch noch vorher wirklich individuell für die einzelnen Webseite abzustimmen und zu programmieren.
Und dann ist das natürlich noch mal eine Extraleistung, mindestens jetzt, was die Initialeinrichtung angeht.
Das muss man dann trotzdem unterscheiden.
Aber unser Ziel ist schon, denn nennen wir ihn Applikationsbetrieb, das ist so ein Begriff, den wir so intern dafür haben, dass der in aller Regel und zwar vollständig und ohne weitere Zusatzleistungen mit unseren Wartungstarifen abgedeckt ist, weil alles andere würde keinen Sinn machen.
Wir wollen dem Kunden ja eine Sicherheit geben, dass er jetzt nicht nochmal hier nochmal 50 Euro und hier nochmal 100 Euro und da nochmal 5 Euro bezahlen muss, sondern das ist dann eindeutig gepackt.
Also alles, was man dafür braucht, dass wir uns darum kümmern, dass die Webseite sauber funktioniert und nicht kaputt geht und was so regelmäßig getan werden muss an Aufräumarbeiten an einer Webseite, dass das wirklich in der Wartung inkludiert ist und als Komplettpaket da steht.
Also so zusammenfassend, sollte sich jeder mal logisch mal darüber Gedanken machen, was kann ich anbieten, welche Skills habe ich, welche Agenturdizenzen habe ich vielleicht, oder welche, sage ich jetzt mal, unfaire Vorteile habe ich gegenüber der Konkurrenz, die sich dann auch gut eignen würden, um das jetzt in ein monatliches Paket dann auch mit einfließen zu lassen.
Und das ist dann für jede Person halt wirklich individuell und deswegen gibt es da auch kein Rezept so, mach das, mach das, mach das und dann ist das abgeschlossen, sondern je nachdem, wer welche Voraussetzungen hat, sollte man sich darüber Gedanken machen und das andere Thema ist dann natürlich der Preis, weil jeder will natürlich so viel wie möglich monatlich verdienen und die Kunden wollen so wenig wie möglich monatlich zahlen, weil Fixkosten, das ist so wie reagieren die meisten Kunden halt allergisch, so hey wieso soll ich jetzt jeden Monat einen Fixpreis zahlen und so weiter und ja da ist einerseits dieser Gedanke, den ich persönlich habe, also je mehr im Paket drinnen ist, je mehr Wert der Kunde bekommt, desto mehr kann man dann auch dafür verlangen, wenn der Kunde natürlich das alles wert sieht und nicht da ist irgendwas anderes, was er sowieso nicht braucht, aber bezüglich Preise und ich habe dann auf eurer Website mal durchgestöbert, was ihr halt so für Preise habt, also ich persönlich bin mega großer Fan auch von Preise einfach öffentlich anzeigen und anschreiben, hey so viel kostet das, das inkludiert, weil das erleichtert dann natürlich auch die Verkaufsgespräche.
Und ihr habt sehr, sehr faire Preise, wenn ich das jetzt mal so sagen kann.
Ist das deswegen, weil ihr halt da wirklich spezialisiert seid, ihr habt da wirklich die Masse von Websites, deswegen könnt ihr dann den Preis ein bisschen senken, sag ich jetzt mal.
Ich mag jetzt nicht sagen, dass es ein billiges Produkt ist oder so, sondern der Preis ist einfach wirklich fair.
Vor allem, wenn man dann auch mit einbezieht Alles, was du jetzt erwähnt hast von den Technologien, die ihr im Einsatz habt, von den Systemen, die im Einsatz sind und so weiter, um individuell die Kosten pro Website zu berechnen, ist das wahrscheinlich eine sehr knappe Kalkulation, wenn da nicht die Masse von Websites dabei wäre.
Also wenn das jetzt nur 50 Websites wären, dann würde einfach die Instanzhaltung des Server, des Speichers und so weiter, da würden sich die Kosten wahrscheinlich nicht decken.
Und da habt ihr auch wiederum so einen, ich sag jetzt mal, unfairen Vorteil, dadurch, dass ihr schon die Menge an Websites habt, könnt ihr dementsprechend dann auch das aufteilen und die Kosten dann auch auf die einzelnen Server, größere Server kaufen und das mehr aufteilen und so weiter, das macht dann natürlich schon Sinn.
Aber in Bezug auf Preis, was würdest du sagen sind vernünftige Preise, sag ich jetzt mal in dem Fall, also bei euch kann sich das jeder nachschauen, was dann die Preise sind, aber wenn sich jemand jetzt überlegt ein Wartungspaket anzubieten, wo sollte man dann überhaupt anfangen? Weil, klar, ein Wartungspaket, 1000€ im Monat wäre geil, aber der Kunde zahlt halt für Updates halt nicht so viel und die meisten Kunden denken sich so, ok, 10, 20€ im Monat kann ich mir schon leisten, sind in Richtung, aber dann zahlt es sich nicht mal aus, auf den Button zu klicken, Updates einzuspielen, meistens.
Und wo liegt da dieser goldene Schnitt, also diesen Mittelweg, wo man sich da, wo man das gut einem Kunden verkaufen kann, den Preis klingt vielleicht ein bisschen negativ, aber gut argumentieren, damit man dann auch selbst sich nicht ausgenutzt gefühlt und dann auch einen guten Umsatz generieren kann.
Ja, also ich freue mich, dass du findest, dass wir faire Preise haben.
Das finde ich persönlich auch, ist mir auch ein Anliegen.
Aber natürlich hast du recht, das funktioniert über die Masse und ist natürlich eine reine Mischkalkulation, ist ganz klar.
Also wir haben IT-Serverkosten irgendwie vierstellig im Monat, was wir da im Background liegen haben.
Mit 50 Webseiten wird das logischerweise nicht funktionieren.
Also ja, das ist ganz klar und eindeutig der Menge geschuldet, die wir da betreuen.
Für diese Menge müssen wir viel tun, viel Server vorhalten, viel Technik vorhalten, viele Überwachungsmaßnahmen vorhalten, weil es eben nicht mehr manuell geht, aber im Umkehrschluss trotzdem, dadurch, dass wir das so haben, haben wir auch die Möglichkeit, in der Kalkulation da entsprechende faire Preise anzunehmen.
Grundsätzlich glaube ich, das Allerwichtigste an dieser Stelle ist, dem Kunden den Mehrwert klarzumachen.
Also es gibt dieses Spannungsfeld, denn wenn wir darüber reden, was ist denn Wartung und was machst du denn in der Wartung und am Ende kommt raus, ich mache Updates, dann mag der Kunde sagen, ja aber Moment, das ist in WordPress so einfach Updates zu klicken, das kann ich auch gerade selber machen, dafür will ich dir gar kein Geld geben oder eben nicht die Summe geben, die du dafür aufrufst.
Es ist also entscheidend eigentlich dem Kunden zu kommunizieren, was das denn alles bedeutet.
Also a warum sollte man überhaupt Updates machen? Klassiker, also never change a running system ist eine schlechte Idee und ich habe da immer Geschichten, die ich erzählen kann mit Sicherheitslücken, die ein paar Stunden alt waren und dann waren Seiten schon gehackt.
Weswegen man bei dem Thema immer unterwegs sein sollte, regelmäßig Updates machen sollte, regelmäßig Backups machen sollte und da auch eine gewisse Überwachung haben sollte, wenn da irgendwas mit Sicherheitslücken passiert.
Das muss man einem Kunden schon mal ganz klar so kommunizieren, dass das Teil der Leistung ist, dass man da ein Auge drauf hat, sollte man natürlich dann auch haben, um die Sicherheit der Webseite zu erhöhen, weil Sicherheitsprobleme sind in der heutigen Zeit relativ schnell teuer.
IT-Sicherheitsgesetz, DSGVO, all die Themen, die da reinspielen, wenn mal was passiert, also bei einem Shop insbesondere mit Kundendaten und alle möglichen.
Da möchte man eigentlich kein Sicherheitsproblem haben, deswegen da muss man dem Kunden schon mal ganz klar kommunizieren, da achten wir drauf, das machen wir.
Das ist wichtig und das zweite ist, dass man natürlich die, ich nenne sie jetzt mal Bonusleistungen, also die Sachen, die man zusätzlich zu diesen Basis-Sicherheitsfeaturen anbietet, dass man die auch klar kommuniziert und auch klar kommuniziert, was das denn alles bedeutet.
Also wenn man sagt, wir machen eine Performance Überwachung.
Ja, was bedeutet das denn? Hast du da einmal im Monat, fragst du einmal die Google PageSpeed API ab und hast eine Zahl oder machst du da mehr als das? Und das ist, glaube ich, ganz, ganz wichtig, dass es dem Kunden auch klar ist, welche Leistung dahinter steht an Überwachung, an Kontrolle, an Sicherstellung von Funktionen.
Und wenn man das macht, dann kann man auch irgendeinen Preis sauber vertreten, der jetzt nicht einfach nur irgendein Fantasiepreis ist.
Ich bin ein großer Freund von anständiger Kalkulation, dass ich auch argumentieren kann, warum ich Preise für was, warum auch habe.
Mal als konkretes Beispiel, unsere Preise für Installationen mit WooCommerce sind quasi, sind teurer als die für normale WordPress-Installationen ohne WooCommerce.
Es ist relativ einfach zu begründen.
Sobald du ein WooCommerce hast, ist ein Update komplexer.
Du hast irgendwelche Zusatzplugins noch dabei im WooCommerce-Umfeld, die die Sache schwieriger machen.
E-Mail-Templates.
Bitte? Die PHP-E-Mail-Templates von WooCommerce.
Ja, genau.
Du hast mehr Templates, die du regelmäßig im Child-Theme anpassen musst.
Du hast mehr Dinge, die schiefgehen können.
Du hast einen Shop, der ausfallrelevanter ist.
Also jetzt mal ganz böse und ohne das gemein sagen zu wollen, aber wenn die Webseite des Kaninchenzuchtvereins mal eine halbe Stunde oder eine Stunde offline ist, dann ist das vielleicht nicht ganz so dramatisch, wie wenn der Shop offline ist, bei dem wirklich jeden Tag ein paar tausend Euro Umsatz gedreht werden.
Das heißt, deswegen müssen wir bei Websites mit WooCommerce andere Maßnahmen beim Update durchführen, genauer gucken, noch mehr machen, noch mehr Vorabkontrolle haben, noch mehr Changelog lesen, noch mehr prüfen und deswegen ist das einfach teurer, als wenn du sowas nicht hast.
Da geht gar kein Weg dran vorbei und das muss dann auch klar sein.
Und wenn wir zum Beispiel mit Staging-Systemen unterwegs sind und Freigabeprozesse implementieren.
Also tatsächlich sagen, wir haben ein Testsystem, auf dem machen wir die Updates, dann führen wir per Hand manuelle Funktionstests durch, also Sachen, die sich jetzt nicht per Playwright abdecken lassen.
Wir führen Testkäufe durch in der Sandboxumgebung und dann geben wir dem Kunden diese Information weiter.
Der Kunde guckt auch noch mal auf die Seite und wenn der Kunde dann die schriftliche Freigabe gibt, dann gehen wir her und machen genau diese Updates auf dem Live-System, aber auch nicht ein weiteres, selbst wenn noch ein weiteres in der Zwischenzeit dazugekommen wäre.
Wir machen genau das.
Das dokumentiert in einem Reporting, was der Kunde dann auch so zur Verfügung gestellt bekommt.
Da steckt manueller Aufwand drin, also wirklich nichts, was wir automatisieren können oder nur sehr wenig.
Dann ist das etwas, was wir in der Kalkulation, in diesem Fall dann wirklich mit einem individuellen Tarif auch nach Stundensatz kalkuliert definieren müssen.
Wir sagen also, wir brauchen da pro Woche eine halbe Stunde für, die muss da einkalkuliert werden.
Und dann entsteht daraus eine Kalkulation und damit natürlich ein höherer Preis.
Also wir haben auch Wartungssysteme, die wir betreuen, die liegen im mittleren dreistelligen Bereich, also deutlich über den Tarifen, so wie man sie bei uns auf der Webseite findet, weil es dann dort entsprechende individuelle Vereinbarungen gibt, zu weiteren notwendigen Schritten zur Sicherstellung der Applikation und dem, was dahinter hängt.
Das muss so sein, da muss man sauber kalkulieren.
Ich glaube aber, du hast eben mal so eine Price Range genannt, alles zwischen 50 und 100 Euro ist für eine normale Webseite, die jetzt kein Staging-System hat, die jetzt nicht tausend andere Sachen hat, die man überwacht, ein solider Rahmen, indem man sich bewegt.
Natürlich eher die untere Grenze 50, wenn man wirklich nicht viel mehr macht als nur Security und Updates und Backups und natürlich die obere Range, wenn man noch ein bisschen mehr anbietet.
Also da muss man natürlich bei gucken.
Wir starten glaube ich bei, also wirklich Basistarif WordPress sind bei uns 33 Euro im Moment.
Das ist natürlich der wirklich einfachster Einstieg auch bei uns, wo zwar die ganze Überwachung mit dabei ist, aber jetzt kein Performance-Check und kein Shop und keine Screenshots, kein Playwright-Test und solche Sachen natürlich nicht zur Verfügung stehen.
Ja und vor allem, wo du das jetzt auch erwähnt hast mit der Ladezeit und so weiter, dann ist finde ich auch, je mehr du dich zum Beispiel dann in das Thema vertiefst, desto mehr denkst du dir, okay, so ein API-Call zu einem Google PageSpeed Insights-Test ist eigentlich ein nettes Gimmick, aber in Wirklichkeit nutzen dir dann zum Beispiel die Real-User-Metrics dann viel mehr, wenn du dann diese Core-Web-Vitals trackst, wo du dann zum Beispiel ein, das wird jetzt sehr technisch, aber zum Beispiel so ein JavaScript-Package von Google dann integrieren kannst auf der Website und dadurch misst du halt die ganzen Daten, die dann wirklich was aussagen.
Sonst ist es eigentlich nur so ein simulierter Test, eine Momentaufnahme über die API, wo es halt eher zwar nett ist, weil man halt dem Kunden irgendwelche Daten schicken kann und dann das dastehen kann im Dashboard, aber wenn man sich wirklich dann auch in das Thema vertieft, das ist dann so ein Subthema von dem Ganzen, da kann man schon unendlich viele Stunden reinstecken, um da mal so ein Monitoring System aufzubauen und das Ganze.
Und wenn du dann mal nachschaust, okay, wie viel kosten dann diese Real-User-Metrics-Monitoring-Systeme im Internet? Die kosten gar nicht mal so wenig.
Also das ist so ähnlich wie Ahrefs zum Beispiel, ein Tool zum Crawlen von Websites.
Klingt ja easy, einfach Crawlen von Websites, aber das kostet dann im Monat mehrere hundert Euro, damit du da überhaupt Zugang hast zu dem Tool.
Und das sind dann schon so spezielle Tools, spezielle Leistungen, wo man dann relativ schwierig dann noch zu dem Punkt kommen kann, dass man solche Services überhaupt einem Kunden anbieten kann, die man selbst in-house entwickelt.
Und das ist dann wiederum ein komplett anderes Thema, wo wir sicher noch lange drüber reden können, aber jetzt haben wir schon ein bisschen lange drüber gequatscht und dann nähern wir uns schon dem Ende der Podcast-Episode.
Da würde ich dir am Ende gerne noch den Spotlight geben, also falls du irgendwas promoten möchtest, bewerben möchtest, dann wäre jetzt der perfekte Zeitpunkt dafür.
Ja, also ich habe ja jetzt schon die letzten einigen Minuten über unsere Produkte gesprochen, insofern muss ich da jetzt vielleicht gar nicht mehr so viel zu sagen.
Ich glaube, Wartung und Betreuung von Websites ist ein extrem wichtiges Thema.
Das sollte man niemals vernachlässigen.
Wenn ich ein bisschen Spotlight legen darf, dann kann ich natürlich sagen, Wenn jetzt ein Agenturinhaber, ein Freelancer uns zugehört hat und vielleicht doch irgendwie der Meinung ist, hupsi, da hängt dann ja doch schon ganz schön viel dran und vielleicht will ich das am Ende dann doch gar nicht so anbieten, weil ich diese Abhängigkeit gar nicht haben will, diese Verantwortung vielleicht gar nicht so dauerhaft tragen will, dann kann ich natürlich sagen, und das wäre dann in diesem Fall mein Spotlight, dass wir alle unsere Leistungen natürlich auch White Label anbieten und im Zweifel mit jedem gerne darüber sprechen, wie wir die Leistungen im Hintergrund erbringen und man dem Kunden es also quasi trotzdem verkaufen kann, aber selber keine Arbeit mit hat und natürlich gerne dann unsere Infrastruktur nutzen kann mit all den Überwachung, die wir dann im Zweifel anstarten können.
Vielleicht ist das das Spotlight an der Stelle, das ich dann nutze, um zu sagen, also wer sich das nicht zutraut oder wer eben diese Intensität selber da auch zeitlich vielleicht einfach überhaupt nicht leisten kann oder will, kann man das natürlich dann auch nicht nur für Einzelkunden, sondern auch eben im Agenturbetrieb und im Freelancer-Betrieb mit uns zusammen machen.
Passt, das wird natürlich alles unten verlinkt sein und jetzt am Ende stehe ich nach noch nur so drei Bullet-Fragen, das heißt einfach das erste, was dir in den Kopf schießt und dann haben wir es geschafft.
Wenn es WP-Wartung 24 nicht gebe, WordPress, Leistungen und alles, was ihr so anbietet, gibt es nicht.
Was wäre dein Alternativberuf? Ich bin ein großer Freund der Logistik.
Ich befürchte, ich würde irgendeine Lagerverwaltung machen oder irgendwie sowas.
Also was komplett anderes ohne Computer.
Ich habe da einfach immer großen Spaß dran, Verwaltung, Dinge zu verwalten.
Möglicherweise hat das damit zu tun, dass ich auch gerne Webseiten verwalte oder so.
Keine Ahnung.
Aber ich glaube, ich würde irgendwas im Logistikbereich machen.
Also du bist ein Prozessmensch.
Scheinbar.
Im Bezug auf WordPress, was ist das nervigste WordPress Feature? Das nervigste WordPress Feature? Mir fallen ganz viele fehlende Features ein.
Also das ist tatsächlich etwas, was mich stört.
Also ich habe das eben schon mal kurz erwähnt.
Sowas wie das Closed Plugins nicht in der Liste der Plugins angezeigt werden.
Also dass WordPress da selber keine Warnung ausgibt oder so.
Also da, dass dieses Feature nicht existiert, das stört mich schon seit Jahren und wundert mich, dass es augenscheinlich so einfach sein müsste, es einzubauen und es trotzdem nicht eingebaut wird.
Wenn wir darüber reden, was wirklich an existentem Feature schwierig ist, kann ich aus der letzten Woche berichten, weil wir über die Notifications von WordPress daran gearbeitet haben, die bei uns in unser Überwachungssystem zu integrieren, also das, was so im Dashboard und so und von Plugins an Notifications ausgegeben wird, da habe ich festgestellt oder haben wir festgestellt, dass es überhaupt nicht einfach ist, das sauber abzugreifen, weil das WordPress einfach standardmäßig nicht so anbietet, wie man sich das vorstellt.
Und ich glaube, eines der nervigsten WordPress-Features ist, dass da noch an einigen Stellen ein bisschen alter Code und ein bisschen alte Schnittstellen lagern und ein bisschen Technical Depth existiert.
Und ich glaube, das ist das, was uns Wartungsmenschen immer noch am meisten stört an dieser Stelle.
Ja, also dann diese Black-Friday-Angebote in den Notifications und so weiter.
Ja zum Beispiel, genau.
Die interessieren uns natürlich am wenigsten.
Uns interessieren dann mehr so die Meldungen.
Hier ist ein Fehler aufgetreten oder die Lizenz ist abgelaufen oder sowas.
Aber ja, die Black Friday Angebote kommen natürlich leider dann auch durch.
Die müssen wir dann aussortieren.
Ja, aber ich habe gehört, dass angeblich darin gearbeitet wird und dass das überarbeitet wird.
Also da bin ich schon sehr gespannt, wie sich das dann auswirken wird.
Bis dann aber alle Plugins das dann auch brav implementiert haben und das dann sauber ist, dass man es wirklich nutzen kann, das dauert halt dann leider immer noch, relativ lange denke ich.
Da muss man die alte Methode abdrehen, dann können die die Black Friday Angebote nicht mehr darstellen, dann sind die ganz rasch, um das nachzuziehen.
Das ist aber, das ist nicht WordPress-Style, alte Dinge abdrehen, Rückwärtskompatibilität abschalten.
Das ist nicht so das Ding von WordPress.
Und ja, kann manchmal ganz schön nervig sein.
Also andere CMS sind da etwas forscher.
Das mag auch schon mal das eine oder andere Problem verursachen, aber an manchen Stellen ist es hilfreicher, wenn es einfach mit neuen Versionen alte Features auch einfach nicht mehr gibt.
Wenn ich das kurz ergänze, weil es mir so als Zweitgedanke reinkommt, also ich bin sehr froh über HPOS, also über das High-Performance-Order-Storage von WooCommerce, also die WooCommerce-Datenbank-Tabellen-Organisation jetzt besser geworden ist.
Aber auch da existiert weiterhin Rückwärtskompatibilität und wir werden sehen, ab wann das irgendwie zielführend wird für alle.
Aber das ist, glaube ich, eines der größeren Probleme von WordPress, dass zu lange an den alten Zöpfen festgehalten wird und zwar neue Dinge existieren, die alten aber immer noch parallel existieren.
Ja, damit meintest du jetzt bei WooCommerce die optimierte Datenbankstruktur, oder? Ja, korrekt, genau.
Stimmt ja, weil da haben die das erst, glaube ich, so gemacht, also bei bestehenden WooCommerce-Shops ist das abgedreht per Default, aber bei neuen ist das eingeschalten.
Genau, neue Installationen laufen direkt auf dieser neuen Datenbankstruktur, alte Systeme nicht.
die kannst du migrieren.
Das ist nicht immer einfach, je nachdem, wie groß der Shop ist und wenn du Pech hast, hast halt das ein oder andere Plugin, was leider immer noch nicht kompatibel damit ist, weil das muss natürlich jedes Plugin, was irgendwas mit WooCommerce-Datenbank-Tabellen, mit WooCommerce-Bestellungen handelt, irgendwie dann auch umsetzen.
Und natürlich müssen die Plugins im Moment immer beides handeln.
Also du musst immer alte Funktionsweise und neue funktionsweise parallel betreiben und parallel irgendwie hinkriegen und klar sowas umzustellen und zu sagen so pass auf auf der nächsten Version unterstützen wir das nicht mehr.
Das birgt natürlich auch Fehler, Potenzial und Probleme, aber es über lange Zeit parallel zu betreiben ist natürlich genauso nicht zielführend.
Wir schauen mal wie sich das entwickelt.
Ja und auf dem anderen Spektrum was ist dein Lieblings-WordPress-Feature? Mein Lieblings-WordPress-Feature.
Ich mache mir jetzt glaube ich ganz wenig Freunde, wenn ich sage der Gutenberg-Editor.
Ah, da gibt es viele Freunde, Da gibt es viele Freunde, die das mögen.
Also ganz am Anfang war wirklich ziemlich grauselig.
Das hat sich mittlerweile gelegt.
Ich finde, man kann mittlerweile ganz anständig damit arbeiten.
Wenn wir uns das aussuchen können, tun wir das auch.
Wir können uns das seltenst aussuchen, deswegen nutzen wir auch jeden beliebigen anderen Page-Builder oder was es sonst gibt.
Technisch gesehen ist der Gutenberg-Editor natürlich unter der Haube auch mit fragwürdigen Entscheidungen gebaut und installiert.
Das ist jetzt auch nicht wirklich die schönste Art und Weise, wie das implementiert ist.
Also Datenbankhaltung von Content und solche Sachen.
Aber wenn wir jetzt über die reine Benutzung reden, also ich denke, WordPress hat schon einen deutlichen Sprung damit gemacht, dass es einen eigenen Blockeditor hat, der mehr kann als dieser Classic Editor, also mehr als nur so ein Eingabefeld ist und deutlich flexibler ist und da jetzt nicht ausschließlich auf Page Builder Plugins angewiesen ist.
Wir bauen eigentlich alles, was wir selber bauen.
Wie gesagt, kommt nicht so häufig vor, aber wenn wir die Chance haben, bauen wir das alles mit Blockeditor und kommen da in aller Regel mit den meisten Sachen auch gut zurecht.
Deswegen Blockeditor ist für mich auf jeden Fall ein gutes Feature.
Na, da kann ich mich nur anschließen.
Nein, also das haben wir in letzter Zeit ziemlich oft.
Also bei dieser Frage, was ist dein Lieblings- WordPress-Feature, da kommt oft eben der Block-Editor Gutenberg und so weiter.
Also die Popularität, die steigt langsam, weil der Block-Editor an sich ist ja schon ziemlich ausgereift.
Das, was jetzt noch mangelhaft ist, ist das mit dem, ich sag jetzt mal, Full-Site-Editing.
der alte Begriff, aber ich glaube, jeder weiß, was damit gemeint ist.
Da merke ich schon einen sehr positiven Aufschwung, was Gutenberg angeht.
Hast du noch eine finale Message, die du an die Zuschauer, Zuschauerinnen, Zuhörerinnen und Zuhörer weitergeben möchtest? Ja, das ist, auch wenn es langweilig ist, ich weiß, dass der Website-Sicherheits- und Wartungstyp ist am Ende für die langweiligen Botschaften da, aber die langweiligen Botschaften müssen lauten, Wartung ist wichtig, Updates, Backups, Sicherheit ist ein zentrales Thema für WordPress, auch das größte Kritikthema irgendwie immer an WordPress.
WordPress ist total unsicher.
Das kommt immer daher, dass es so viele nicht gut betreute Webseiten gibt, also Webseiten niemals liegen lassen, mindestens einmal die Woche beischauen.
Websites müssen betreut werden, Updates gemacht werden, man muss dabei gucken.
Wenn man das tut, kriegt man auch sichere WordPress-Websites hin, die den schlechten Ruf in keinster Weise rechtfertigen.
Dann ist alles fein, aber man muss sich darum kümmern, man darf das nicht vernachlässigen und ich kann das, so langweilig es ist, immer nur wieder erwähnen, macht Updates, macht Backups, kontrolliert, was ihr da tut, lasst das nicht liegen und dann kann man auch ein WordPress super schön und super fein und super gesund und super sicher betreiben und das ist quasi mein persönliches Ziel.
Das ist das, was ich seit über zehn Jahren, seit fast 15 Jahren irgendwie mache, mich mit beschäftige.
Sichere WordPress-Websites ist ein Anliegen und wir kriegen das hin.
Sehr cool.
Also es wird auf jeden Fall alles in der Beschreibung verlinkt sein.
Also das, was du erwähnt hast, auch mit den Kontaktdaten zu dir.
Also falls jetzt irgendein Freelancer oder ein Agenturinhaber zuhört, so bitte meldet euch, weil da habt ihr einen Zugang zu einer ganz, einer extrem ausgereiften Infrastruktur, was Wartung angeht und Security angeht.
Und ja, da bin ich schon sehr gespannt auf die Rückmeldungen, Kommentare und so weiter.
Falls ihr da noch Fragen an den Marc habt, auch bitte gerne in den Kommentaren oder schreibt uns direkt an und dann können wir euch alle Fragen beantworten.
Und ja, dann vielen, vielen Dank für deine Zeit, Marc.
Hat mich sehr gefreut, dass wir jetzt gequatscht haben.
Vielen Dank, dass ich hier sein durfte.
Hat Spaß gemacht.
Danke dir.
Wir sehen uns dann vielleicht irgendwann auf einem WordCamp.
Das machen wir.
Passt.
Tschüss.
Ciao.
.