7BizWorks – Deine eigene Coaching-Plattform mit WordPress

Die Suche nach dem richtigen WordPress Kurs-Plugin endet selten mit einer Antwort, sondern mit einer ganzen Reihe von ihnen: Vergleichstabellen voller Häkchen, Featurelisten mit 40 oder 60 Funktionen, bei manchem Anbieter schlicht allem, was geht. Und dazwischen die Empfehlungen von Leuten, deren Systeme nicht deine sind. Diese Folge dreht die Suche um.

Der Ausgangspunkt ist eine These, die unangenehm klingt: Die Frage nach dem Plugin wird viel zu früh gestellt. Was zuerst stehen muss, ist eine andere Frage — und sie bezieht sich auf dich selbst.

Jede Antwort, die du in Foren oder Gruppen sammelst, passt am besten zu einem System: dem des Menschen, der sie gibt. Seine Anforderungen, sein Stack, seine Teilnehmer — nicht deine. Daran wird die Empfehlung nicht falsch, aber an ihr kommst du nicht weiter. Was in deinem System fehlt und was darin überflüssig wäre, steht in keiner fremden Meinung. Ich habe die Recherche ein paar Runden mitgemacht, bis mir auffiel: Sie beantwortete eigentlich nur eine Frage, die nicht meine war und mir auch nicht wirklich weitergeholfen hat.

Legst du zwei Plugins nebeneinander, hat das eine 40 Funktionen und das andere 60. Ein drittes kann im Zweifel alles dabei haben was Plugin A und B haben. Genau dort, so mein Eindruck, versagen die Vergleiche: Sie zeigen, was ein Plugin kann. Ob du es brauchst, wie gut die Funktion im Alltag läuft und welche Voraussetzungen dein Server mitbringen muss — das steht in der Doku, nicht auf der Liste.

Ein Beispiel aus der Folge: Zertifikatserstellung klingt wunderbar, automatisch generiert mit Namen und Datum. Für meine eigenen Kursteilnehmer zählt sie nichts — in einer zertifizierten Akademie spielt dieser Faktor aber plötzlich ein ganz andere Rolle.

Ob ein Kurs-Plugin zu dir passt, hängt stark davon ab, welche User und Kursteilnehmer du betreust. Ein Solo-Anbieter mit einem klaren Kurslaufwerk — oder ein Team von Dozenten, die eigene Kurse pflegen und unterschiedliche Rechte brauchen. Oder eine komplette Akademie mit Prüfungen, Klassen und Lernpfaden. Das sind drei Systeme, die dasselbe Schlagwort tragen, aber völlig unterschiedliche Anforderungen stellen. Welches davon dein System ist — und ab wann die Rechtevergabe ungemütlich wird: das sortiere ich in dieser Folge.

Ich habe die Variante aus einer Hand lange betrieben: Kursbaukasten, Shop-Anbindung und das Drumherum liefen über einen einzigen Anbieter. Weniger Entscheidungen, weniger Schnittstellen — bis der Hersteller das Plugin verkaufte und die Konditionen wechselten. Mein ganzer Stack passte an einer Stelle nicht mehr, an der Ausrichtung und Gestaltung des neuen Anbieters selbst. Die Neuausrichtung, die daraus für mich folgte, hatte weniger mit fehlenden Funktionen zu tun als mit der Frage, wie tief ein einzelner Hersteller in mein System reichte.

Die andere Seite, die getrennten Module, verlangt am Anfang mehr von dir: mehr Auswahl, mehr Zusammenspiel. Welches der beiden Gewichte sich für deine Situation richtig anfühlt — das wiege ich ab, einschließlich dessen, was mir am eigenen System passiert ist. Und wenn es danach konkret losgehen soll: Viele namhafte Kurs-Tools liegen im WordPress Plugin Repository, sortiert nach Lernmanagement-Systemen, und warten auf genau diese Vorbereitung.

Eine kuratierte Top-Liste? Nein — ohne zu wissen, was dein System kann und soll, wäre jede Empfehlung ein Ratespiel. Stattdessen gibt es die Fragen, mit denen sich aus einer großen Optionsflut eine kleine Handvoll sinnvoller Kandidaten ergibt. Eine davon: „Ob du das System in einem Jahr noch selbst verstehen und managen kannst?“ — habe ich mir früher, wenn überhaupt, auch viel zu spät gestellt. Die anderen Fragen, und wie du auf deine Antworten kommst, sind der Kern dieser Folge.

Die erste Sicherheitslücke einer frischen WordPress-Installation wird nicht in Wochen gefunden. Meistens reichen ein paar Stunden, bevor automatisierte Bots die Standardpfade abklappern. Nicht weil jemand gezielt hinschaut, sondern weil das Internet ständig danach sucht. Wer eine WordPress Kursplattform starten will, kommt an diesem Punkt nicht vorbei: Bevor der erste echte Besucher da ist, war dein System längst im Visier von etwas, das keine Pause macht.

Das ist der Abschluss meiner Miniserie „Was du am Anfang nicht brauchst“. In den letzten vier Folgen ging es um Cache, Statistik, SEO und die Entscheidung zwischen Kurs und Community, alles Dinge, die warten können. Diese Folge dreht den Blick um und fragt: Was darf nicht warten?

90 Prozent aller WordPress-Sicherheitslücken stecken in Plugins, nicht im WordPress-Kern selbst. Klingt nach einem logischen Grund, möglichst wenige davon zu installieren, aber so einfach ist die Rechnung nicht, wie ich in der Folge erkläre. Dazu kommt die Frage nach dem Log-in selbst: Wie lang muss ein Passwort eigentlich sein, damit es tatsächlich schützt, und welche zwei, drei Einstellungen erledigen den Großteil der Arbeit in wenigen Minuten?

Ein Backup ist für mich kein Punkt für später. Wie viele Kopien wirklich reichen und wo sie liegen sollten, ist eine Frage, die ich mir selbst schon gestellt habe, und für die ich mir ein Prinzip aus einer ganz anderen Ecke meines Lebens geliehen habe. Genauso wichtig wie das Backup selbst ist die Frage, ob es im Ernstfall überhaupt funktioniert. Ein Backup, das noch nie wiederhergestellt wurde, ist eine Vermutung, keine Absicherung.

Für wen baust du deine Kursplattform eigentlich? Der erste Besucher muss in Sekunden verstehen, worum es geht. Und sobald jemand kaufen will, entscheidet sich alles Weitere an einer einzigen Stelle. Was dort im Detail schiefgehen kann, und warum ein technischer Fehler an dieser Stelle mehr kostet als nur einen Verkauf – darauf gehe ich ebenfalls ein.

Du bist nicht nur Kurs-Ersteller, sondern auch Betreiber deiner eigenen Plattform. Das bringt eine zweite Rolle mit sich, für die kaum jemand einen Plan hat, bevor die erste Support-Anfrage kommt. Aber sich dem bewusst zu werden, ist der erste Schritt, um damit auch umgehen zu können.

Impressum, Datenschutzerklärung, Cookie-Consent und eine rechtskonforme Rechnungsstellung gehören zu der Basis deiner Kursplattform, nicht zur Kür. Warum ausgerechnet dieser letzte Punkt bei mir zur Wahl meines Shop-Tools geführt hat, erfährst du heute hier in meinem Podcast.

Wenn du dich für WordPress entschieden hast und nach einem Weg suchst, deinen Kurs auszuliefern, landest du früher oder später bei Plugins, die dir eine Kursplattform mit Community als fertiges Paket anbieten. Kursbereich, Forum, Dokumentation, Mitgliederverwaltung. Alles in einer Installation, alles über ein Backend zu steuern.

Ich bin an genau dieser Stelle hängengeblieben. Der Gedanke, zwei Bausteine auf einmal abzuhaken, hatte etwas Verlockendes, und ich habe eine Weile gebraucht, um zu verstehen, was ich da eigentlich vorhatte.

Ein Plugin, das Kurse und Community abdeckt, muss für beides Entscheidungen treffen. Ein Kurssystem braucht Inhaltsstruktur, Fortschrittslogik und eine saubere Zugriffssteuerung. Ein Community-System braucht Feeds, Reaktionen und Moderationswerkzeuge. Das sind unterschiedliche Anforderungen an dieselbe Codebasis.

Irgendwo hat jede dieser Lösungen mit einer Seite angefangen. Auf der liegt der Fokus, die andere kam später dazu. Manche haben das gut gelöst, andere weniger. In der Folge gehe ich darauf ein, warum vollgepackte Systeme selten flexibel sind und woran du das im Vorfeld schon ablesen kannst.

Der Punkt, den ich vorher nicht auf dem Schirm hatte, ist nicht technisch. Es ist der Aufwand, und der verteilt sich bei beiden Systemen völlig unterschiedlich über die Zeit.

Beim Kurs steckt fast alles vorn drin. Du planst die Struktur, überlegst dir was deine Teilnehmer am Ende können sollen, schreibst Skripte, nimmst Videos auf, baust Zusatzmaterial. Danach kommt das technische System mit der gesamten Zugriffslogik, und dann testest du. Am besten nicht allein. Erst danach kann der Kurs überhaupt online gehen.

Das ist viel Arbeit, aber sie ist planbar. Wenn du weißt, dass du fünf Module mit je sechs Sessions baust und eine Session eine halbe Stunde Vorbereitung braucht, kannst du grob rechnen. Steht der Kurs, sinkt der laufende Aufwand deutlich. Nicht auf null, das wäre ein Trugschluss. Rückfragen kommen, Teilnehmer hängen an bestimmten Stellen, manchmal musst du nachbessern. Aber die aktive Zeit ist überschaubar.

Bei der Community läuft es andersherum. Der Aufbau ist schnell erledigt: Ein paar Bereiche anlegen, Startbeiträge schreiben, fertig. Und dann fängt es an. Täglich. Du moderierst, du antwortest, du hältst Gespräche am Laufen und achtest darauf, dass der Ton stimmt.

Ein Aspekt, der in den Feature-Listen der Plugins nicht auftaucht: Sobald in deinem Bereich andere Menschen schreiben, bist du für diesen Raum verantwortlich. Auch dann, wenn du irgendwann Moderatoren hast, die dir einen Teil der Arbeit abnehmen. Die Aufsichtspflicht bleibt bei dir, weil du der Betreiber bist.

Seit dem Digitale-Dienste-Gesetz hat sich der Rahmen dafür geändert. Wer nutzergenerierte Inhalte hostet, hat andere Pflichten als jemand, der eine reine Kursseite betreibt. Das ist kein Grund, keine Community zu bauen. Es ist ein Grund, sie nicht nebenbei mitlaufen zu lassen.

Beide Wege sind möglich. Du kannst aus einem laufenden Kurs heraus eine Community entstehen lassen, oder du kannst aus den Themen einer bestehenden Community deinen Kurs bauen. Das ist deine Entscheidung und hängt davon ab, womit du dich wohler fühlst.

Für mich war der Kurs zuerst dran, weil er mein Kernprodukt ist. Solange ich parallel über die Community nachdenke, leidet die Aufmerksamkeit für das, was eigentlich funktionieren muss.

In der Folge erzähle ich außerdem, woran du merkst, dass der Zeitpunkt für den zweiten Schritt gekommen ist. Es gibt einen Unterschied zwischen der Annahme, dass deine Teilnehmer sich austauschen wollen, und dem Moment, in dem du es an ihren Fragen tatsächlich ablesen kannst. Diesen Unterschied halte ich für den brauchbaren Teil der ganzen Überlegung.

Mehr zum Thema und die Frage, warum sich der Aufwand einer Community so schlecht schätzen lässt, findest du im Blogpost zu dieser Folge.

Es gab eine Phase, da war das SEO-Plugin bei mir eines der ersten Dinge, die auf einer neuen Website landeten. Noch vor dem ersten Beitrag. Einstellungen durchklicken, Keywords recherchieren, verschiedene Plugins vergleichen, herausfinden, welche Einstellung nun die richtige sein soll. Bis mir auffiel, dass ich gerade viel Energie in die Optimierung von etwas gesteckt hatte, das es noch gar nicht gab. Kein Beitrag, keine Seite, keine Grundlage. Die Wirkung war entsprechend.

Deshalb taucht SEO in meinem Kursaufbau nicht auf. Das liegt nicht an fehlender Bedeutung, es liegt am Zeitpunkt. Was in der Aufbauphase dagegen sehr wohl passiert, ist WordPress SEO ohne Plugin: eine Handvoll Punkte, die du ohnehin festlegst, während du deine Seite baust.

Stell dir vor, du eröffnest ein Geschäft in einer Stadt, in der dich niemand kennt. SEO ist in diesem Bild das Straßenschild an der Abfahrt, der Eintrag im Stadtplan, die Empfehlung von jemandem, der gefragt wird. Ohne das steht dein Geschäft trotzdem. Es finden dich nur die, die deine Adresse schon kennen.

In der Folge gehe ich darauf ein, warum sich dieser Aufbau eher wie ein Ruf verhält. Google schaut nicht einmal auf deine Seite und ordnet sie dann für immer ein. Es wird auch bewertet, ob sie gepflegt wird, ob jemand anderes auf dich verweist und wie lange Besucher bleiben. Das dauert. Und du kannst nach ein paar Wochen ohne Bewegung nicht sagen, dass SEO nicht funktioniert, wenn die Grundlage dafür noch fehlt.

Ich nehme mir in dieser Folge auch Zeit für ein Thema, das ich nicht ignorieren möchte, obwohl es den Rahmen fast sprengt. Ein klassischer Crawler liest deine Seite, indexiert sie und packt dich in eine Rangliste. Du bist dann ein Link, auf den jemand klickt oder eben nicht. Ein KI-System interpretiert stattdessen, bewertet Zusammenhänge und Glaubwürdigkeit und formuliert eine eigene Antwort. Du bist dort keine Position in einer Liste, sondern eine zitierte Quelle. Oder du kommst nicht vor.

Was das für dich beim Aufbau bedeutet, ist erfreulich unspektakulär: klare Struktur, eindeutige Überschriften, saubere Architektur, schnelle Ladezeit. Ein KI-Crawler liest den HTML-Code, den dein Server ausliefert. Was per JavaScript nachgeladen wird, sieht er nicht. Wenn du von Anfang an ordentlich baust, machst du das meiste davon schon richtig, ohne dass es dich extra Arbeit kostet.

Der praktische Teil der Folge ist eine Liste, die du abarbeiten kannst, während du ohnehin gerade an deiner Seite sitzt. Die Permalink-Struktur, die du einmal einstellst und danach nicht mehr anfasst. Die WordPress-Einstellung, mit der du Suchmaschinen bittest, deine Baustelle in Ruhe zu lassen, und die dir später gefährlich werden kann, wenn du sie vergisst. Eine saubere Überschriften-Hierarchie mit genau einer H1 pro Seite. Interne Verlinkung als Gewohnheit statt als nachträgliche Aufgabe. Und Alt-Texte für deine Bilder.

Zu jedem Punkt sage ich in der Folge, warum er zählt und woran es in der Praxis scheitert. Die vergessene Sichtbarkeits-Einstellung ist dabei der Punkt, bei dem am wenigsten passiert, wenn etwas schiefgeht. Keine Fehlermeldung, nichts bricht ab. Es kommen einfach keine Besucher, und du merkst es womöglich erst Wochen später.

Am Ende der Folge wird es konkret. Der erste Moment ist der naheliegende: Sobald echter Content auf deiner Seite steht, hast du etwas, womit ein SEO-Plugin arbeiten kann. Vorher gibt es dir vor allem ein Gefühl von Sicherheit, das nichts trägt.

Der zweite Moment hat mit Optimierung nichts zu tun, und er kommt für dich als Kursanbieter früher, als du vielleicht denkst. WordPress bringt von Haus aus keine Möglichkeit mit, eine einzelne Seite gezielt aus dem Index zu nehmen. Genau das brauchst du aber, sobald der erste Kurs live geht und Seiten hinter einer Paywall entstehen. Warum das deinem Ruf bei der Suchmaschine schadet, wenn du es nicht tust, erkläre ich in der Folge.

In meinem Hauptjob bin ich Qualitätsmanagementbeauftragter. Da arbeitet man mit Daten, Zahlen und Fakten, leitet daraus Maßnahmen ab und rät nicht herum. Diese Haltung habe ich auf meine Webseiten übertragen. Das Statistik-Plugin gehörte bei mir zu den ersten Installationen, direkt nach dem Setup.

Und dann saß ich vor einem Dashboard, in dem fast nichts stand.

Diese Folge erzählt, was ich aus dieser Wiederholung gelernt habe. Sie gehört zur Miniserie „Womit du dich nicht am Anfang beschäftigen solltest“, in der ich Themen aus der Aufbauphase deiner Kursplattform herausnehme, weil sie dir Zeit kosten, ohne dir gerade etwas zu geben.

Statistik hilft dir, wenn zwei Dinge zusammenkommen. Du musst wissen, was du von deinem System wissen willst. Und es muss genug passiert sein, dass die Antwort im Datensatz überhaupt drinsteckt.

In der Folge gehe ich beide Punkte durch. Die Frage kennst du in deiner Aufbauphase in der Regel bisher nicht, jedenfalls dann nicht, wenn du zum ersten Mal eine Kursplattform baust. Und Daten hast du zu diesem Zeitpunkt kaum. Wer trotzdem täglich ins Dashboard schaut, gewöhnt sich an Zahlen, die schön aussehen und nichts entscheiden.

Bevor ich über Gründe rede, erkläre ich in der Folge die Mechanik. Ein Statistik-Plugin hängt sich in jeden Seitenaufruf ein. Es merkt sich, woher jemand kommt, was er anklickt, wann er wiedergeht. Diese Informationen landen in derselben Datenbank, in der WordPress auch alles andere ablegt.

Das ist der Punkt, den ich in der Folge ausführlicher erzähle, weil er die meisten Konsequenzen hat. Jeder Besucher schreibt mindestens einen Datensatz, oft mehrere. Es wird nicht nur gelesen, es wird geschrieben. Und geschrieben wird auf derselben Ebene, auf der auch dein Shop arbeitet, deine Login-Verwaltung läuft und deine Kursinhalte ausgeliefert werden.

Für die ersten Monate ist das kein Thema. Wenig Traffic, kleine Datenbank, minimale Last.

Ich benutze in der Folge ein Bild, das mir selbst geholfen hat, den Unterschied besser darzustellen. Ein internes Statistik-Plugin wohnt in demselben Haus wie WordPress. Es sitzt neben dir und verbraucht Strom und Wasser aus demselben Anschluss, also CPU und RAM.

Eine externe Lösung ist ein anderes Haus, im besten Fall auf einem anderen Server, mit eigener Datenbank. Deine Seite sendet ein Signal hinüber, gezählt und ausgewertet wird dort. Deine WordPress-Instanz bekommt davon nichts mit.

Was das für dich praktisch bedeutet und ab wann der Unterschied spürbar wird, erkläre ich in der Folge an einem Szenario, das für eine Kursplattform naheliegt: dem Launch.

Ein großer Teil der Folge dreht sich um etwas anderes als Technik. Nämlich darum, welche Fragen du deinem System stellen solltest, sobald genug Traffic da ist.

Wo steigen deine Besucher ein, auf welcher Seite landen sie zuerst, aus welcher Quelle kommen sie? Ich rechne das an einem Beispiel vor, das die Sicht auf Reichweite verschiebt: Ein Video mit 10.000 Views, aus dem niemand auf deine Seite klickt, bringt dir weniger als eines mit 1.000 Views und 100 Klicks.

Dazu die Gegenrichtung. Wo verlassen Leute deine Seite? Wo bricht jemand einen Kauf ab, auf der Landingpage, in der Produktauswahl, kurz vor der Bezahlung? Und wenn jemand gekauft hat: Was macht ein Kursteilnehmer eigentlich in deinem Kurs, welches Zusatzmaterial nutzt er, klickt er auf den Hinweis zu deinem nächsten Angebot?

Ich erzähle in dem Zusammenhang auch, was ich aus internen Dokumentationssystemen in meiner Arbeit gelernt habe. Dort sehe ich, wonach Leute suchen und was sie nicht finden. Diese Information bekommst du ohne eigenen Zeitaufwand, wenn dein System sie erfasst.

Nur eben nicht in Woche eins.

Egal ob intern oder extern, es werden Daten erhoben. Manche Plugins senden dabei an Server, von denen du beim Installieren nichts geahnt hast. Bei externen Diensten liegt die Datenbank auf fremder Infrastruktur, und du musst nachweisen können, dass das DSGVO-konform läuft.

Bei einem internen Plugin ist die Lage übersichtlicher. Ich nenne in der Folge das Plugin, mit dem ich starte, und die Einstellung, ohne die es nicht funktioniert. Anonymisierung ist dabei der Punkt, an dem sich vieles klärt.

Und ich sage auch, was du selbst tun musst, bevor du auf Empfehlungen vertraust: nachlesen, was das Plugin konkret erhebt und wohin es sendet.

Es gibt zwei Signale, an denen ich den Wechsel festmachen würde. Deine Seite wird unter Last langsamer. Oder du stellst Fragen, die ein kostenfreies Plugin nicht beantworten kann, weil es die passenden Daten nicht erhebt.

Bis dahin: ein einfaches Statistik-Plugin für WordPress, DSGVO-konform eingestellt, freigeschaltet zum öffentlichen Start deiner Kursplattform. Alle paar Monate ein Blick in die Datenbank, damit du ein Gefühl für das Datenaufkommen bekommst.

Und nicht jeden Tag auf die Zahlen starren. Die sagen dir am Anfang noch nichts.

Wenn du eine WordPress-Kursplattform aufbaust, stolperst du früher oder später über das Thema Cache. Meistens in Form von Empfehlungen, die klingen als müsstest du das alles sofort einrichten – Cache-Plugin hier, CDN dort, dazu ein paar Einstellungen, von denen niemand so richtig erklärt, was sie tun. Genauer gesagt geht es um den WordPress Kursplattform-Cache: ein Thema, das du am Anfang bewusst kleinhalten kannst, ohne dass deine Plattform darunter leidet.

Diese Folge ist der erste Teil einer kleinen Miniserie darüber, womit du dich beim Aufbau deiner Plattform am Anfang nicht beschäftigen solltest. Die Idee dazu kam aus einer eigenen Erfahrung: Als ich die Struktur für meinen Kurs geplant habe, wurde meine Themenliste immer länger. Ich wollte alles hineinpacken, jede Erfahrung, jeden Sonderfall. Irgendwann saß ich davor und merkte, dass das viel zu groß wird – und komplette Vollständigkeit aller Themenbereiche dich als Kursteilnehmer nicht ans Ziel bringen wird. Die Reihenfolge macht das. Manche Themen schaden zu einem bestimmten Zeitpunkt mehr, als dass sie dir helfen. Nicht weil sie unwichtig sind, sondern weil sie zum falschen Moment kommen. Cache ist so ein Thema.

Ein Grund, warum Cache so einschüchternd wirkt, ist die Sprache. Alle reden von „dem Cache“, dabei stecken dahinter vier verschiedene Konzepte, die unterschiedliche Aufgaben haben. In der Folge gehe ich jede Ebene einzeln durch und erkläre sie an einem Bild statt an einer Definition.

Der Object Cache kümmert sich um die Daten aus deiner Datenbank – wer gerade eingeloggt ist, welche Rechte jemand für deine Member-Rollen hat, welche Einstellungen gerade gelten. Ich vergleiche ihn mit dem Kollegen, der sich Antworten notiert, statt bei jeder Frage neu ins Archiv zu laufen. Für eine Kursplattform mit Logins und Zugriffsrechten ist das die Ebene, die am Anfang den spürbarsten Effekt bringt.

Der Page Cache speichert deine fertig gebaute Seite als eine Art Snapshot, damit WordPress sie nicht bei jedem Aufruf neu zusammensetzen muss. Der Edge Cache geht noch einen Schritt weiter und verteilt diesen Snapshot über ein CDN auf Server an verschiedenen Standorten – so bekommt ein Besucher aus Finnland deine Seite von einem Server in seiner Nähe statt aus Nürnberg. Ein schönes System, aber nichts, worum du dich beim Start kümmern musst, schon gar nicht, wenn du deine Zielgruppe regional in deiner Nähe sitzt.

Der Browser-Cache liegt beim Besucher selbst und merkt sich Bilder, Schriften und Dateien beim ersten Besuch. Das Angenehme daran: Er läuft in der Regel schon über deinen Server mit, ohne dass du dafür ein zusätzliches Plugin brauchst. Wenn du dir einen Server mit NGINX buchst, sind hier meist schon sinnvolle Standardwerte hinterlegt.

Ich mache in der Folge eine klare Trennung, welche dieser vier Ebenen für den Aufbau deiner WordPress-Kursplattform am Anfang zählt und welche warten kann. So viel vorweg: Es ist genau eine davon, und sie lässt sich schnell aktivieren – vorausgesetzt, dein Hosting-Anbieter stellt diese in deinem gebuchten Paket zur Verfügung. Die anderen Ebenen sind nicht schlecht oder überflüssig – sie kommen später dran, wenn deine Plattform wächst und mehr Besucher bekommt. Von Anfang an alles aufzusetzen, bringt dich nicht weiter, es hält dich eher auf.

Du hörst außerdem, welche Vorteile ein durchdachtes Cache-System später bringt: mehr Stabilität bei Traffic-Spitzen, etwa wenn du deinen Kurs launchst und alle gleichzeitig auf deinen Link klicken. Weniger Serverlast, sodass du länger mit einem kleineren Server auskommst. Und einen positiven Nebeneffekt auf deine Ladezeit, die Google als Ranking-Faktor bewertet.

Zum Schluss erzähle ich dir von einer Situation, die mich viel Zeit und Nerven gekostet hat. Ich hatte auf einer Testseite etwas gecacht, das man auf keinen Fall cachen darf – meinen Login samt Sicherheitstoken. Die Folge: Ich kam über das Frontend nicht mehr in meine eigene Seite, weil die Abfrage immer ins Leere lief. Zum Glück nur eine Testumgebung, und ich konnte das Plugin über den Server deaktivieren. Aber genau daran siehst du, warum Cache mit Bedacht eingesetzt werden will. Eine gecachte Login-Seite oder ein gecachter Kaufprozess kostet dich im Zweifel das Vertrauen deiner Kursteilnehmer – und dich selbst eine lange Fehlersuche.

Wenn du gerade an deiner Plattform baust und dir unsicher bist, wie tief du beim Thema Cache einsteigen musst, gibt dir diese Folge eine Antwort, mit der du weiterarbeiten kannst. Und einen Punkt, den du für den Moment guten Gewissens von deiner Liste streichen darfst.

Eine Staging-Umgebung klingt nach der offensichtlichen Lösung, wenn du Änderungen an deiner WordPress-Kursplattform testen willst, bevor diese live gehen und für alle ersichtlich sowie nutzbar sind.

Eine 1:1-Kopie deiner Seite, du probierst dort alles aus, und wenn es passt, drückst du auf Push und die Änderungen landen auf deiner Live-Seite. In der Theorie klingt das nach genau dem, was du brauchst. Simple, sicher und nur ein Klick. In der Praxis bin ich davon abgekommen – und in dieser Folge erzähle ich dir warum.

Der Punkt, der mich am meisten beschäftigt hat, ist die Richtung des Pushs. Sobald du Daten von deiner Staging-Umgebung zurück auf die Live-Seite schickst, überschreibst du dort alles, was seitdem passiert ist. Bei einer normalen Info-Website mag das verschmerzbar sein. Bei einer Kursplattform, auf der echte Menschen echtes Geld bezahlen und sich durch echte Kursinhalte arbeiten, sieht die Sache anders aus.

Ich gehe in der Folge an drei konkreten Situationen durch, wo das schiefgehen kann: bei Newsletter-Anmeldungen, die während der Entwicklungszeit auf der Live-Seite dazukommen, bei abgeschlossenen Käufen, die deiner Staging-Datenbank schlicht unbekannt sind, und bei Plugin-Lizenzen, die plötzlich nicht mehr wissen, zu welcher Seite sie eigentlich gehören. Dazu kommt ein vierter Punkt, der auf den ersten Blick harmlos wirkt, aber schnell nervig wird: Automationen, die auf der Staging-Kopie einfach mitlaufen, weil sie ja eine exakte Kopie deiner Live-Seite ist – und dann verschickst du plötzlich doppelte E-Mails an deine Kursteilnehmer.

Es gibt einen Mittelweg, bei dem du nur in eine Richtung pushst: Nur von Live zu Staging, also von der Produktionsseite zu deiner Testumgebung. Das schließt zumindest das Überschreiben deiner Live-Daten aus. Ich erkläre in der Folge, warum mir das trotzdem noch nicht sicher genug war, und welche Alternative ich stattdessen für mich gefunden habe – eine, die zwar mehr manuellen Aufwand bedeutet, mir dafür aber die Sorge um überschriebene Userdaten komplett nimmt.

Ich erläutere dir zusätzlich, wie mein technisches Setup für 7BizWorks konkret aussieht: eine lokale Entwicklungsebene, auf der ich auch meine eigenen Plugins weiterentwickle, eine Online-Entwicklungsebene, auf der ich das Ganze noch einmal unter realistischeren Bedingungen teste, und die eigentliche Live-Seite, die von alldem komplett unberührt bleibt, bis ich mir hundertprozentig sicher bin. Das ist kein Ein-Klick-Workflow, das gebe ich offen zu. Aber genau das ist für mich der Punkt: Lieber ein paar Minuten mehr Aufwand, als eine schlaflose Nacht, weil ich nicht mehr weiß, welche Kundendaten gerade wo liegen.

Ein Punkt, der in der Folge auch noch mal kurz zur Sprache kommt und den ich dir jetzt schon mitgeben will: Egal für welchen Weg du dich entscheidest – ohne ein aktuelles Backup solltest du an keiner dieser Stellschrauben drehen.

Wenn du gerade dabei bist, deine eigene Kursplattform mit WordPress aufzubauen, und dir noch nicht sicher bist, ob du überhaupt eine Testumgebung brauchst oder welcher Ansatz zu deiner Situation passt, bekommst du hier eine Einordnung aus der Praxis – inklusive der Stelle, an der ich selbst am längsten abgewogen habe, bevor ich mich für meinen jetzigen Weg entschieden habe.

Wenn du gerade dabei bist deine eigene Kursplattform mit WordPress aufzubauen, kennst du wahrscheinlich diesen Moment: Du suchst nach dem passenden Plugin für eine Funktion, findest fünf Kandidaten, entscheidest dich für einen – und kurz darauf brauchst du schon das nächste Plugin für das nächste Problem. Nach ein paar Wochen hast du eine Liste, die länger ist als geplant, und fragst dich, ob das noch gesund ist.
In dieser Folge gehe ich genau dieser Frage nach. Nicht mit einer Zahl als Antwort, sondern mit der Denkweise, die sich bei mir über die letzten Jahre entwickelt hat.

WordPress lebt von seinen Plugins – das ist der Grund, warum ich mich überhaupt dafür entschieden habe, statt eine fertige All-in-One-Lösung zu nutzen. Die Flexibilität, die dir Plugins geben, ist gleichzeitig ihre gefährliche Seite. Jedes zusätzliche Plugin bedeutet mehr Wartungsaufwand, mehr potenzielle Konflikte und ein größeres Einfallstor für Sicherheitsprobleme. Ich erkläre in der Folge, warum ich trotzdem nicht bei der reinen Zahl ansetze, sondern bei der Frage, welche Aufgabe ein Plugin eigentlich übernehmen soll.

Der Kern meiner Herangehensweise: Ich teile meine Plattform in klare Bereiche auf – Sicherheit, Backup, Design und Admin-Einstellungen, E-Mail-Automation, Kursstruktur. Jeder dieser Bereiche bekommt ein Plugin, das genau dafür zuständig ist, und nicht für fünf andere Dinge gleichzeitig. Ich gehe in der Folge an einem konkreten Beispiel durch, warum ich unter anderem den E-Mail-Versand bewusst nicht demselben Plugin überlasse, das meine Design- und Admin-Einstellungen verwaltet – auch wenn es funktionstechnisch auf den ersten Blick attraktiv wirkt.

Ein Thema, das in der Folge nicht fehlen darf, ist DSGVO-Konformität. Ich zeige an einem Sicherheitsplugin, das ich selbst nutze, worauf ich achte, wenn ein Plugin Daten an externe Server sendet – und warum es mir wichtig ist, solche Funktionen abschalten zu können, statt blind zu vertrauen. Das ist für mich mittlerweile ein echtes Kriterium bei der Plugin-Auswahl, nicht nur ein Nice-to-have.

Ich erzähle auch, wie ich an eine Grenze gestoßen bin – bei der Kernfunktion meiner Plattform, dem Kurs selbst, habe ich lange kein Plugin gefunden, das mich wirklich überzeugt hat. Am Ende habe ich zwei eigene Plugins entwickelt: 7BizGateway für die Zugangsregelung und 7BizCourse für die Kursstruktur. Das war keine spontane Entscheidung, sondern das Ergebnis von langem Suchen, Testen und der Erkenntnis, dass zwei unterschiedliche Aufgaben – wer darf etwas sehen, und wie läuft der Kurs für den einzelnen Nutzer ab – auch zwei unterschiedliche Systeme brauchen.

Wenn du selbst gerade merkst, dass sich bei dir Plugins ansammeln ohne klaren Plan, gibt dir diese Folge einen Ansatz an die Hand, wie du wieder Ordnung hereinbringst – nicht durch Löschen um jeden Preis, sondern durch eine klare Zuordnung von Aufgaben. Und wenn du noch am Anfang stehst, hilft dir die Folge dabei, von vornherein durchdacht zu starten, statt später alles neu aufzubauen.

Es gibt diesen einen Moment im Aufbau einer WordPress-Kursplattform, den ich selbst gut kenne. Du sitzt an deiner Startseite, schaust dir eine andere Website an – vielleicht von einem Plugin-Hersteller, vielleicht von einem Kursanbieter, den du schätzt – und denkst: Warum wirkt meine Seite nie so aufgeräumt? So professionell? So fertig?

Ich habe mir diese Frage selbst gestellt. Und ich habe eine Weile gebraucht, bis ich gemerkt habe, dass die Frage selbst das Problem ist.

Was wir sehen, wenn wir auf professionell gestaltete Websites schauen, ist immer das Endprodukt. Nie der Weg dahin. Nie, wie viele Anpassungen, wie viel Zeit, wie viele spezialisierte Leute dahinterstecken. Große Unternehmen und Agenturen beschäftigen Menschen, die sich ausschließlich um das Design kümmern – nichts anderes. Wir als Solo-Aufbauer einer Kursplattform machen gleichzeitig Technik, Inhalte, Marketing, Struktur und Design. Das ist ein fundamental anderer Ausgangspunkt.

Dazu kommt: Im Zeitalter von KI und tausenden Templates wirkt fast jede Seite auf den ersten Blick ordentlich. Aber das ist Oberfläche. Was darunterliegt – Struktur, Klarheit, ein System, das funktioniert –, das ist eine andere Frage.

Ich habe großen Respekt vor Webdesignern. Wer wirklich im Webdesign arbeitet, denkt in Farbharmonien – nicht einfach in hell und dunkel. Der achtet auf Typografie, auf die Komposition einer Seite, auf die Wirkung von Weißraum an bestimmten Stellen. Der weiß, warum ein Button an einer bestimmten Stelle sitzt und nicht zwei Zentimeter weiter oben. Das ist ein Handwerk, das jahrelange Erfahrung braucht.

Das werden wir nicht in ein paar Monaten adaptieren. Und wir sollten es auch nicht versuchen.

Was ich damit meine: Es gibt einen Unterschied zwischen dem, was ein Webdesigner macht, und dem, was wir für unsere Kursplattform brauchen. Beides ist real. Aber es ist nicht dasselbe.

Denk mal an dein Lieblingsrestaurant. Hat es die schönste Speisekarte der Stadt? Wahrscheinlich nicht. Bei meinem Lieblings-Sushi-Restaurant ist die Karte schlicht, alt, und nicht besonders aufregend. Aber das Essen ist so gut, dass die Karte völlig irrelevant ist. Ich bekomme alle Informationen, die ich brauche – was es gibt, wie viel, was es kostet. Mehr braucht diese Karte nicht zu leisten.

Genauso ist es mit deiner Kursseite. Was sie leisten muss: klar erklären, was du anbietest, den Interessenten mit den richtigen Informationen versorgen, und ihn am Ende zu einer Entscheidung führen – ob das ein Kauf ist, eine Newsletter-Anmeldung oder ein anderer Call-to-Action. Wenn das funktioniert und das Design dabei schlicht und einheitlich ist, schlägt das jede visuell aufwändige Seite mit Scroll-Animationen und Hover-Effekten.

Zugänglichkeit und Lesbarkeit – das ist die Messlatte. Nicht ausgefallene Schönheit.

Ich habe selbst eine Phase gehabt, in der ich unzählige Templates durchgeschaut habe. Hier was herausgezogen, da getestet, dort ein Template gekauft, wieder verworfen. Irgendwann habe ich aufgehört.

Nicht weil ich aufgegeben habe, sondern weil ich die Frage anders gestellt habe: Was brauche ich wirklich, um eine Seite zu bauen, die meinen Besucher gut führt? Ich habe dann meine definierten Klassen und Variablen im Bricks Builder einmal grundlegend aufgeräumt – alles gelöscht, was ich nicht brauche, alles strukturiert, was ich immer wieder verwende.

Was dabei vorgefallen ist: Ich habe aufgehört, bei jeder neuen Seite von vorn anzufangen. Für Landingpages und Anmeldeseiten brauche ich heute ein oder zwei Templates. Die verwende ich immer wieder. Das spart keine Stunden – das spart Tage an wiederholender Arbeit, die für mich selbst und dem Sinn und Zweck meiner Seite keinen Mehrwert im Aufbau bietet – in Relation zu den Aufgaben, wo meine Zeit viel besser investiert ist.

Die eigene Zeit in ein funktionierendes eigenes Template ist eine mehr oder weniger einmalige Investition. Und selbst wenn sie eine oder zwei Wochen dauert: Diese Zeit bekommst du später mehrfach zurück.

Kein tiefes CSS-Wissen. Kein pixelperfektes Designauge. Was du brauchst, ist überschaubar:

Den Rest nimmt dir ein guter Page-Builder wie der Bricks Builder ab. Du entscheidest mit Logik, nicht mit Code.

Die Frage ist nicht, ob du irgendwann einen Designer holst. Die Frage ist eher, wann und wofür du ihn oder sie wirklich brauchst.

Wenn dein System steht, deine Plattform funktioniert, deine Kursteilnehmer gut durch den Kurs geführt werden – dann ist der richtige Moment, jemanden zu holen, der das Ganze mit einem individuellen gestalterischen Stil ausstatten kann. Das ist kein Widerspruch. Das ist eine sinnvolle Reihenfolge.

Tune nicht dein Auto, bevor der Motor läuft.

Wer mit WordPress eine Kursplattform aufbaut, trifft früh eine Entscheidung – meistens ohne es zu merken. Nicht die Entscheidung für ein bestimmtes Plugin oder einen bestimmten Hoster. Sondern die Entscheidung, in welcher Reihenfolge das alles passiert.

Diese Reihenfolge ist nicht beliebig. Was du in Phase 3 aufbaust, baut auf Phase 2 auf. Was in Phase 7 schiefgeht, hat seinen Ursprung oft in Phase 1. Ich habe das in meinen eigenen Aufbauphasen gelernt – und daraus ein System entwickelt, das ich in dieser Folge in zwölf Phasen runterbreche.

Die Hosting-Entscheidung steht am Anfang, weil sie alles andere beeinflusst. Serverstandort, Ressourcen, DSGVO-Konformität – das sind keine Details, die du später nachrüstest. Wer hier auf einem wackligen Fundament startet, merkt das spätestens dann, wenn der erste Kurs läuft und das System unter Last gerät. Diese Phase ist eine eigene Einheit, weil sie vor WordPress stattfindet – und weil die Kriterien für eine gute Hosting-Entscheidung andere sind als die für ein gutes Plugin.

Sicherheit und Backup kommen direkt nach dem Hosting – nicht nach dem ersten Plugin, nicht nach dem Design. Das ist die Phase, die am häufigsten auf später verschoben wird, und genau das ist das Problem. Wer erst dann an Backups denkt, wenn etwas schiefgeht, hat kein Backup. Diese Phase ist bewusst von der Hosting-Phase getrennt, weil sie auf einer anderen Ebene ansetzt: nicht der Server, sondern die WordPress-Installation selbst und der Umgang mit ihr.

Bevor die erste Seite gebaut wird, wird das Designsystem definiert. Theme, Builder, Farben, Schriften, Grundeinstellungen. Das klingt nach Ästhetik – ist aber eine technische Entscheidung. Wer das Designsystem einmal sauber aufsetzt, baut alle späteren Seiten darauf auf. Wer es nicht tut, beginnt jede neue Seite bei null. Diese Phase ist eine eigene Einheit, weil sie einmalig ist und danach nicht mehr grundlegend geändert werden sollte.

Startseite und Kontaktformular. Noch kein vollständiger Auftritt, aber ein erster öffentlicher Stand. Diese Phase hat ihren Platz vor den rechtlichen Pflichtangaben, weil du für Impressum und Datenschutzerklärung weißt, was auf der Seite passiert – welche Tools laufen, welche Daten erhoben werden. Erst dann lässt sich das korrekt dokumentieren.

Impressum, Datenschutzerklärung, Cookie-Tool. Rechtlich notwendig, technisch oft unterschätzt. Das Cookie-Management ist keine reine Formalität – es entscheidet darüber, welche Daten wann und wie verarbeitet werden dürfen. Diese Phase steht hier, weil ab diesem Punkt die Seite nach außen hin vollständig rechtlich abgesichert ist. Alles, was danach kommt – Newsletter, Shop, Kursplattform – baut auf diesem Rahmen auf.

Das Mailing-System gehört früher ins Setup als die meisten denken – auch wenn der Kurs bisher nicht fertig ist. Wer es erst kurz vor dem Launch einrichtet, richtet es unter Zeitdruck ein. Wer es früh aufbaut, kann schon während der restlichen Aufbauphasen erste Interessenten sammeln. Diese Phase ist eine eigene Einheit, weil sie unabhängig vom Member-Bereich und der Kursplattform funktioniert – und weil Automationen Zeit brauchen, um getestet zu werden.

Hier wird geregelt, wer auf was zugreifen darf. Rollen, Zugangsbeschränkungen, Login-Flows. Diese Phase ist bewusst von der Kursplattform getrennt – weil Member-Management und Kursdarstellung zwei unterschiedliche Aufgaben sind, die nicht zwingend im selben Plugin stecken müssen. Wer sie trennt, bleibt flexibel. Wer sie zusammenlegt, schafft eine Abhängigkeit, die sich später rächt, wenn ein Tool ausgetauscht werden soll.

Kursstruktur, Inhaltsdarstellung, Video-Integration. Die Kursplattform setzt auf dem Member-Bereich auf – deshalb kommt sie danach. Hier werden auch Entscheidungen getroffen, die die Performance der gesamten Seite betreffen: Wo liegen die Videos, wie werden sie ausgeliefert, wer hat unter welchen Bedingungen Zugriff? Das sind keine rein technischen Fragen – sie haben direkte Auswirkungen auf das Erlebnis deiner Kursteilnehmer.

Die Testphase ist eine vollständige Phase – kein Schritt, der nebenbei läuft. Der Unterschied zwischen Admin-Sicht und User-Sicht ist größer, als man denkt. Zugangsbeschränkungen, Passwort-Reset, Login-Flows, Kursfortschritt – alles muss aus User-Perspektive durchgespielt werden. Diese Phase steht zwischen Kursplattform und Shop, weil sie den Stand bis hierhin abnimmt, bevor neue Komplexität hinzukommt.

Zahlungsabwicklung, Rechnungslegung, DSGVO-konformer Checkout. Der Shop kommt spät – weil er auf allem anderen aufbaut. Ein Kauf löst eine Kette aus: Zahlung, Zugangsfreischaltung, automatische E-Mail. Diese Kette kann nur funktionieren, wenn alle vorherigen Phasen stabil stehen. Deshalb ist der Shop keine frühe Entscheidung, sondern eine späte – die aber gut vorbereitet sein muss.

Noch eine Testphase – diesmal für den vollständigen Kaufprozess. Erst im Test-Modus, dann mit einem realen Testkauf. Diese Phase ist eine eigene Einheit, weil sie den ersten echten Durchlauf des Gesamtsystems darstellt: von der Bestellung bis zur Zugangsvergabe, alles in Echtzeit. Erst wenn das funktioniert, ist das System bereit.

Content-Produktion, Promotion, der eigentliche Launch. Diese Phase steht am Ende – nicht weil Content unwichtig ist, sondern weil Content auf einer stabilen Plattform erscheinen sollte. Wer parallel zu allen anderen Phasen schon Content produziert hat, startet hier von einer guten Position.