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 sowieso 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.

WordPress steht für eine Sache vor allem: Du entscheidest. Welche Plugins du einsetzt, wann du etwas austauschst, wie dein System aufgebaut ist. Das ist kein kleines Detail – das ist der eigentliche Grund, warum so viele Selbstständige und Kurs-Creator bewusst zu WordPress greifen, auch wenn es nicht das einfachste System auf dem Markt ist.

Aber selbst in WordPress kann man sich in eine Abhängigkeit manövrieren, die sich im ersten Moment nicht so anfühlt.

All-in-One Plugins versprechen genau das, was du dir in einer frühen Phase wünschst: weniger Entscheidungen, weniger verschiedene Tools, weniger Abos. Ein Plugin das Kursverwaltung, Member-Bereich, E-Mail-System und Page-Builder unter einem Dach vereint – und das zu einer Jahresgebühr, die sich erst einmal stimmig anfühlt.

Ich habe das selbst geglaubt. Und ich habe fast ein Jahr damit verbracht, ein System zum Laufen zu bringen, das strukturell nicht für mich gebaut war.

Das Problem mit All-in-One Plugins zeigt sich nicht beim Start. Es zeigt sich dann, wenn etwas nicht funktioniert – oder wenn du merkst, dass du raus willst.

Wenn Kursstruktur, E-Mail-System, Member-Logik und Design im selben Plugin stecken, kannst du nicht einen Teil herauslösen. Du kannst nicht sagen: „Das E-Mail-System tausche ich aus, der Rest bleibt.“ Du musst alles auf einmal ersetzen. Und dabei ist bisher nicht einmal sicher, dass du alle deine Daten vollständig mitnehmen kannst – Nutzerdaten, Automationen, Design.

Dazu kommt eine Frage, die ich damals unterschätzt habe: DSGVO (Datenschutzgrundverordnung). Viele dieser Tools sind nicht für den deutschen Markt gebaut. Nicht weil die Entwickler das absichtlich ignorieren – sondern weil ihre Hauptzielgruppe international ist und die spezifischen Anforderungen des deutschen und europäischen Rechtsrahmens schlicht nicht im Fokus stehen. Das bedeutet: Du baust auf einem Fundament, welches du in Teilen nicht selbst beurteilen kannst.

Ich wollte damals einen Online-Kurs zum Thema Podcast-Produktion erstellen. Das All-in-One Plugin das ich gefunden hatte, schien alles mitzubringen. Kursgestaltung, Member-Verwaltung, E-Mail-System, Quiz-Tool, Page-Builder, Theme. Ich habe die Tutorials intensiv durchgearbeitet, die Trial-Version getestet, sogar einen zusätzlichen Strategie-Kurs vom selben Entwickler gekauft.

Fast ein Jahr später war ich noch am selben Punkt. Die Motivation war im Keller. Und dann kam die Nachricht, dass der Entwickler das Plugin verkauft hatte – an eine größere Plugin-Gruppe. Deren erste Maßnahme: die Subscription-Gebühr wurde auf fast das Dreifache angehoben.

Das war der Moment, wo ich ausgestiegen bin. Und im Nachhinein war es das Beste, was passieren konnte.

Was nach diesem Abbruch folgte, klingt nach einem Rückschritt – war aber keiner. Ich war wieder am Anfang, ja. Aber nicht bei null. Ich hatte ein Jahr lang Fragen gestellt, Dinge ausprobiert, und verstanden, was nicht funktioniert und warum. Das ist ein anderer Startpunkt als der, an dem ich vorher stand.

Ab diesem Moment habe ich Funktionen bewusst getrennt. Page-Builder und Design. Member-Management. Kursstruktur. E-Mail-System. Shop. Jeder Bereich bekommt ein eigenes Tool – eines das ich unabhängig vom Rest austauschen kann. Wenn ein Anbieter seine Preise verdreifacht, wechsle ich diesen einen Bereich. Der Rest läuft weiter.

Was mir damals niemand erklärt hat – kein Kurs, kein Tutorial – ist dass der Aufbau einer WordPress-Kursplattform nicht beim Page-Builder beginnt. Er beginnt bei der Serverstruktur. Wo liegt deine Seite? Auf welchem Hosting? Welche Grundlage braucht es damit das System stabil läuft und die DSGVO-Anforderungen erfüllt werden?

Das war der Punkt der mir fehlte. Und genau deshalb fängt WPCourseStack – mein Kurs unter dem Dach von 7BizWorks – wirklich bei A an. Servergrundlage zuerst. Dann Page-Builder, Shop-System, Kursstruktur. Einen Fahrplan den man Schritt für Schritt mitgehen kann – nicht eine Sammlung von Tutorials zwischen denen man sich selbst eine Reihenfolge zusammenreimen muss.

In dieser Podcast-Folge erzähle ich die ganze Geschichte. Was mich damals in dieses All-in-One System geführt hat, was dabei schiefgelaufen ist, was der Verkauf des Plugins ausgelöst hat – und welche Erkenntnis daraus entstanden ist, die heute die Grundlage für alles ist was ich mit sevenbizworks.de aufbaue.

Hier findest du den passenden Blog Post zu diesem Thema: Online-Kurs WordPress aufbauen ohne Lock-in