Deine Website selbst hosten(Alles, was du dafür brauchst und wie du das machst)

Willkommen beim Marketing Techie Podcast, dem Podcast über die Technik hinter dem Online-Marketing. Verständlich erklärt, auch für Non-Techies. Mit Emilian Buza von trace5.co. In dieser Folge: Deine Website selbst hosten. Alles, was du dafür brauchst und wie du das machst.

Ende der Neunziger gab es eine Website, auf der sich so ziemlich jeder Nerd der Welt jeden Tag rumtrieb: Slashdot. Gegründet 1997 von einem Studenten namens Rob Malda, im Netz nur bekannt als CmdrTaco. Der Slogan: „News for nerds. Stuff that matters.“ Das Prinzip war simpel. Technik-News, kurze Meldung, Link drunter. Und darunter Hunderte Kommentare. Linux, Raumfahrt, Datenschutz, irgendwer hat aus einem Toaster einen Webserver gebaut. Alles, was Nerds interessierte. Querbeet. Und wenn Slashdot auf deine Seite verlinkte, dann war das der Ritterschlag. Denn auf einmal wurde dein kleines Projekt, deine Anleitung, dein selbst gebauter Roboter Hunderttausenden Lesern präsentiert.

Stell dir das mal vor. Du bist Student, irgendwann 1999. Du hast monatelang an einer Seite gebastelt, sagen wir über deinen selbst gebauten Roboterarm. Die Seite läuft auf dem alten Rechner unter deinem Schreibtisch im Wohnheim. Bisher hatte sie elf Besucher. Drei davon warst du.

Und dann schreibt dir ein Kumpel: „Alter. Du bist auf Slashdot.“ Du rufst die Seite auf. Tatsächlich. Dein Roboterarm. Ganz oben auf Slashdot. Du bist stolz wie Bolle.

Und während du es noch kaum fassen kannst, fängt auf einmal unter deinem Schreibtisch die Festplatte an zu rattern. Die Lämpchen an der Netzwerkkarte blinken nicht mehr, die leuchten nur noch. Der Lüfter heult auf. Du willst deine eigene Seite neu laden.

Doch dann? Nichts. Seite nicht erreichbar.

Das Problem: Ende der Neunziger Jahre liefen viele der Seiten, die auf Slashdot verlinkt wurden, genau so. Auf einem Rechner unterm Schreibtisch. An einer Uni-Leitung. An einem privaten Anschluss. Und dann kamen innerhalb von Minuten Zehntausende Besucher gleichzeitig. Und die Seite … war weg. Einfach weg.

Das passierte so oft, dass es einen eigenen Namen bekam: der Slashdot-Effekt. Und daraus wurde sogar ein Verb. Wenn deine Seite unter dem Ansturm zusammengebrochen war, dann warst du „geslashdotted“. Der größte Erfolg deiner Website war damit gleichzeitig ihr Totalausfall. Zehntausende Leute wollten deinen Roboterarm sehen. Gesehen hat ihn am Ende kaum einer.

Und in den Kommentaren lief dann ein ganz eigenes Ritual ab. Die ersten paar Glücklichen, die die Seite noch erwischten, legten Kopien davon auf anderen Servern ab und verlinkten zu diesen Kopien. Mirrors hieß das. Damit überhaupt noch jemand lesen konnte, worüber da gerade alle diskutiert hatten. Und ganz oben stand meistens irgendein Kommentar wie: „Server ist schon tot. Hier ist ein Mirror.“

Warum ich dir das erzähle? Weil das eine Seite vom Selbsthosten zeigt, an die beim Einrichten kaum jemand denkt. Solange keiner kommt, läuft alles. Die Frage ist, was passiert, wenn jemand kommt. Oder wenn nachts um drei etwas kaputtgeht. Und genau darum geht es heute. Was heißt es eigentlich, eine Website selbst zu hosten? Was brauchst du dafür? Und, das ist fast noch wichtiger: Welche Verantwortung und welche Aufgaben übernimmst du da eigentlich, wenn du es machst?

Bevor wir starten, eine ganz wichtige Sache vorab: Du gewinnst in diesem Podcast einen Überblick darüber, wie du eine Website auf deinem eigenen Server einrichtest und erreichbar machst.

Und wenn ich „Überblick“ sage, meine ich das wörtlich: Das Hosten deiner eigenen Website ist machbar, aber nicht trivial, weil es einige Zwischenschritte und ein paar Kenntnisse voraussetzt. Weil es aber in einem Podcast nicht gut möglich ist, lange und komplexere Schritte darzustellen, schon gar nicht, wenn du von unterwegs zuhörst, kriegst du hier nur einen Überblick.

Aber natürlich will ich dir hier nicht nur vage Überblicke geben, sondern du sollst auch wissen, wie du das, was du in diesem Podcast erfährst, ganz konkret selbst umsetzen kannst.

Darum habe ich dir zusätzlich zu dieser Episode eine genaue Schritt-für-Schritt-Anleitung erstellt, in der alle Arbeitsschritte in genau der richtigen Reihenfolge detailliert beschrieben sind. Du kannst sie dir direkt über den Link in der Podcast-Beschreibung runterladen.

Und damit zurück zu unserem Thema.

Starten wir mit folgendem Szenario.

Du hast dir mit ChatGPT oder Claude eine einfache Website erstellt. Auf deinem Computer kannst du sie schon öffnen. Jetzt möchtest du sie auf deinem eigenen Server veröffentlichen, damit auch andere sie aufrufen können.

Vielleicht hattest du bisher ein normales Hostingpaket. Das heißt: Du hast Texte geschrieben und Bilder hochgeladen. Den Computer, auf dem deine Website lag, hast du aber nie gesehen. Der stand beim Anbieter. Dort waren auch die grundlegenden Programme schon eingerichtet.

Wie viel zusätzlich betreut wurde, hing von deinem Paket ab. Manche Aktualisierungen musstest du vielleicht selbst erledigen.

Dann hast du erfahren, dass es dir viele Vorteile bringt, selbst, auf deinem eigenen Server zu hosten. Weil du dann die völlige Entscheidungsfreiheit hast, viele Dinge lernen und zugleich deutlich Geld sparen kannst.

Das klang gut, denn auch du willst entscheiden können, welche Programme laufen. Wie sie eingestellt sind. Und du willst verstehen, was hinter deiner Website passiert.

Darum möchtest du ab heute mehr selbst entscheiden können. Also mietest du einen Server, den du selbst verwaltest.

Aber nun stellt sich dir schon die Frage: Was ist überhaupt ein Server?

Wenn du dir Folge 2 des Marketing Techie Podcasts schon angehört hast, weißt du bereits ziemlich genau, was ein Server ist.

Falls nicht, hier noch einmal zusammengefasst:

Ein Server ist in unserem Fall ein Computer, der über das Internet erreichbar ist und deine Website bereitstellen soll. Er steht in einem Rechenzentrum. Die Hardware mietest du vom Anbieter, der auch den Strom und die Internetanbindung bereitstellt.

Du hingegen benutzt diesen gemieteten Computer und das heißt: Die Programme für deine Website betreust du.

Häufig mietet man dafür einen virtuellen Server, einen sogenannten VPS. Auf einem großen Computer laufen mehrere getrennte virtuelle Computer. Einen davon verwaltest du. Die tatsächliche Hardware teilst du dir mit anderen Kunden.

So. Und damit haben wir alle Voraussetzungen geschaffen. Du hast eine Website und du weißt, dass du einen Server benötigst, um deine Seite darauf zu betreiben.

Aber was genau musst du jetzt machen, um deine Website auf deinen eigenen Server zu bringen?

Du musst einen Prozess durchlaufen, der immer gleich bleibt, bei jeder Website, die du einrichtest.

Und der beginnt damit, dass du dir bei einem Anbieter wie Netcup oder Hetzner einen VPS bestellst.

Das machst du auf deren Websites. Du wirst dabei sehen, dass es sehr unterschiedliche Größen gibt. Aber wenn es um einen Server geht, auf dem eine oder mehrere kleinere Websites betrieben werden sollen, genügt bei Netcup in der Regel der VPS 500 G12 und bei Hetzner der CX23, sofern er an deinem gewünschten Standort verfügbar ist.

Für unsere einfache Website ist das bereits großzügig bemessen. Auch mehrere kleine Websites lassen sich damit normalerweise problemlos betreiben. Entscheidend ist allerdings, was diese Websites machen und wie viele Besucher gleichzeitig darauf zugreifen. Eine fertige HTML-Datei auszuliefern, verlangt dem Server deutlich weniger Arbeit ab als ein aufwendiger Onlineshop.

Ok, zurück zu unserem Prozess.

Nehmen wir mal an, du hast jetzt einen Server bestellt – dann steht er dir in der Regel schon innerhalb weniger Minuten zur Verfügung.

Im Kundenkonto kannst du nun deinen neuen Server starten. Häufig startet er nach der Einrichtung auch automatisch.

Aber was jetzt?

Nun, du hast jetzt einen laufenden Server, aber damit du ihn benutzen kannst, braucht er erst einmal ein Betriebssystem. Das wählst du bei vielen Angeboten schon beim Erstellen des Servers aus. Bei anderen installierst du es anschließend über das Kundenkonto.

Überrascht, dass du ein Betriebssystem installieren musst?

Tja, so ist das mit selbst verwalteten Servern. Mit ihnen bekommst du viel Verantwortung – aber eben auch viel Freiheit. Das heißt: Dein Hosting-Anbieter legt dich nicht auf ein einziges Server-Betriebssystem fest. Du entscheidest, welches du im Rahmen der Möglichkeiten deines Angebots benutzt.

Du musst dir dafür auch nichts runter- oder hochladen. Dein gewünschtes Betriebssystem wählst du einfach im Kundenkonto aus, und der Anbieter installiert es für dich auf deinem Server.

Welches Betriebssystem du nimmst, hängt nun davon ab, welche Programme du betreiben möchtest und womit du dich auskennst. Sehr viele Unternehmen, darunter auch große Konzerne, setzen dafür Linux ein. Auch FreeBSD wird auf Servern verwendet. Beide sind beliebte, verbreitete und vor allem auch kostenlose Betriebssysteme.

Und Linux kommt in vielen unterschiedlichen Varianten.

Für einen Server sind Debian oder Ubuntu sehr verbreitet und sehr beliebt. Ich kann beide empfehlen, wenn du ein stabiles und sicheres Betriebssystem möchtest.

Ich unterstelle mal, dass du meiner Empfehlung folgst, und nehme darum jetzt an, du entscheidest dich für Ubuntu Linux als Betriebssystem.

Dann wählst du es im Kundenkonto aus, und nach kurzer Zeit ist es installiert.

Und sobald du das hinter dir hast, kannst du schon zum ersten Mal stolz auf dich sein: Du hast zum ersten Mal deinen eigenen Server eingerichtet, er ist da!

Glückwunsch.

Aber das war nur der erste Schritt. Deine Website ist damit noch nicht eingerichtet. Du hast erst den Computer, auf dem sie laufen soll.

Und an diesen Computer musst du herankommen. Du musst auf ihm arbeiten können, von deinem Schreibtisch aus, während er irgendwo im Rechenzentrum steht.

Dafür gibt es SSH. Das ist eine Technologie, mit der du von deinem Rechner aus den entfernten Rechner, also deinen Server bedienen kannst.

Und jetzt kommt etwas Wichtiges: Bei unserem Ubuntu-Server arbeitest du nicht mit einer grafischen Oberfläche, so wie du es auf deinem Rechner zu Hause machst, in Windows, macOS oder vielleicht ja auch Linux.

Ja, theoretisch könntest du durchaus auch ein Betriebssystem mit grafischer Oberfläche installieren, etwa eine passende Windows-Version, wenn dein Serverangebot das unterstützt. Für unsere einfache Website würde eine grafische Oberfläche aber zusätzlich Rechenleistung, Arbeitsspeicher und Speicherplatz beanspruchen, ohne dass wir das brauchen.

Viele Linux-Server werden deshalb ohne grafische Oberfläche betrieben, und so machen wir das auch. Du bedienst den Server hier ausschließlich per Texteingaben, in dem Fenster für Befehle.

Unter Windows kannst du dafür PowerShell verwenden – du öffnest sie über das Startmenü. Auf dem Mac heißt die Anwendung „Terminal“, und du öffnest sie über die Suche. Auch unter Linux öffnest du die Anwendung „Terminal“. Dieses Fenster nimmt geschriebene Befehle entgegen.

Zum Beispiel: Installiere jetzt dieses Programm. Oder: Wechsle in diesen Ordner. Oder: Zeige mir die Dateien in diesem Ordner.

Heißt: Über SSH bedienst du den Server von deinem Computer aus mit deinem Terminal.

Du öffnest also auf deinem Computer ein Fenster für Befehle, ein sogenanntes Terminal. Darin verbindest du dich mit dem Server und meldest dich an. Sobald du das getan hast, wird alles, was du innerhalb dieser Verbindung eingibst, dann auf dem entfernten Rechner ausgeführt.

Diesen Zugang musst du übrigens gut schützen. Darüber lassen sich schließlich auch Dateien löschen und Einstellungen verändern. Die privaten Zugangsdaten dazu bewahrst du geschützt auf deinem eigenen Computer auf. Darum gehört zu deinen ersten Schritten auf dem Server eine kurze Ersteinrichtung: Updates einspielen, einen eigenen Benutzer anlegen und die Anmeldung per SSH-Schlüssel einrichten. Die Schritte sind nicht kompliziert, und es gibt unzählige Anleitungen dazu, darum gehe ich an dieser Stelle nicht auf sie ein. Mit ChatGPT, Claude oder einer schlichten Google-Suche kannst du sie selbst erledigen.

Sobald du das alles getan hast, sind wir wieder ein Stück weiter: Jetzt können wir auch auf dem Server arbeiten.

Und das Erste, was wir tun wollen, ist erstmal unsere Seite auf den Server zu bringen.

Dass du die Seite schon hast, davon gehe ich mal aus. Ich nehme also an, du hast deine Seite bereits mit einer KI wie ChatGPT oder Claude erstellt und dir als einzelne HTML-Datei geben lassen und irgendwo auf deinem Computer gespeichert.

Genau diese Datei musst du nun auf deinen Server bringen.

Aber in welchem Ordner auf dem Server?

Auf einem Linux-Server liegen Websites häufig in einem Ordner wie /var/www.

Vorgeschrieben ist dieser Ort aber nicht. Dort kannst du einen Unterordner erstellen, zum Beispiel „Website_01“, und deine HTML-Datei mit einem Übertragungsbefehl vom Terminal deines Computers aus dorthin kopieren.

Sobald das passiert ist, solltest du auf dem Server in den Ordner wechseln und sie in index.html umbenennen, falls sie noch anders heißt. Das ist ein üblicher Dateiname für die Startseite einer Website.

Wie gesagt: Das ist alles ein “Kann” nicht ein “Muss”. Aber es wird dir ungemein helfen, wenn du zumindest am Anfang die Konventionen kennenlernst und dich daran hältst.

Sobald du das erledigt hast, hast du einen Server und eine Website, die in dem dafür vorgesehenen Ordner auf dem Server liegt.

Nun ist es zwar schön, dass sie dort liegt, aber damit ist sie noch immer nicht für Besucher erreichbar. Die Seite selbst macht nichts weiter, außer auf deinem Server zu liegen.

Du kannst einem Besucher noch keinen funktionierenden Weblink zu dieser Datei geben, weil Besucher nicht einfach so Zugriff auf deinen Server bekommen.

Also brauchst du ein vermittelndes Programm, das von außen von Browsern angesprochen werden kann, damit jemand sagen kann: „Ich möchte gerne die Website auf diesem Server sehen, bitte zeig sie mir.“

Dieses Programm, das zwischen den Browsern deiner Besucher und den Dateien auf deinem Server vermittelt, ist in unserem Beispiel nginx. Das installierst du jetzt auf deinem Server.

Stell es dir für jetzt wie einen Archivar vor. Und wenn du möglichst viel darüber erfahren möchtest, schlage ich vor, du hörst dir Folge 9 dieses Podcasts an, wo ich nur darüber spreche.

Warum ein Archivar? Weil nginx ähnlich wie ein Archivar funktioniert.

Ein Browser klopft von außen an deinem Server an und sagt: „Bitte zeige mir die Website so und so an.“ nginx sucht daraufhin anhand seiner Einstellungen nach der passenden Datei und liefert sie an den Browser deines Besuchers aus. So wie ein Archivar auf Anfrage nach Akten sucht und sie ausliefert.

Übrigens ist nginx ein sogenanntes “Webserver-Programm”.

Und wenn du dich jetzt wunderst, weil in der Bezeichnung schon wieder das Wort “Server” vorkommt: Lass dich jetzt bitte nicht von dem Wort verwirren.

“Server” kann sowohl einen gemieteten Computer meinen als auch ein Programm.

Der gemietete Computer ist unser Server. Auf dem lassen wir jetzt das Programm nginx laufen. Dieses Programm ist ein “Webserver”. Es nimmt Anfragen nach Webseiten entgegen und beantwortet sie.

Nun genügt es aber nicht, einfach nginx zu installieren. Du musst auch nach der Installation in seinen Einstellungen festlegen, welche Websites es betreut und wo deren Dateien liegen.

Hast du das gemacht, dann startest du es. Ab jetzt läuft es im Hintergrund und wartet auf Anfragen.

Damit sind wir schon wieder einen Schritt weiter: Die Seite liegt bereit. Und jemand kann sie ausliefern.

Weiter, aber noch immer nicht fertig.

Denn noch weiß niemand, dass die Domain deiner Seite zu genau diesem Server mit genau dieser IP, auf der deine Website liegt, hinführen soll. Ein Besucher kann also noch nicht deine Domain im Browser eingeben und landet dann bei dir – weil du das noch nicht eingerichtet hast.

Falls dir das gerade zu schnell gegangen ist, hier noch einmal, warum wir das machen müssen.

Also: Deine Besucher wissen, dass deine URL z.B. meinefirma.de lautet. Diesen Namen nennt man Domain. Dein Server hat dagegen eine öffentliche IP-Adresse. Das ist seine Adresse im Internet. Für unser Beispiel hast du einen Server mit einer festen öffentlichen IP-Adresse gewählt.

Du musst jetzt den Namen mit dieser Adresse verbinden.

Dafür gibt es die DNS-Einstellungen deiner Domain. Du findest sie bei dem Anbieter, bei dem du den Namen registriert hast, also dort, wo du die Domain gemietet hast.

Wo du deine Domain hast, weißt nur du. Du kannst sie dir dort geholt haben, wo du auch deinen Server gemietet hast, also zum Beispiel bei Netcup oder Hetzner. Oder bei einem anderen Anbieter, wie etwa GoDaddy, IONOS oder Namecheap. Falls du dir nicht sicher bist: Denk noch einmal darüber nach – wo hast du die Domain gekauft?

Du weißt es?

Gut. Dann gehst du jetzt in die DNS-Einstellungen bei deinem Anbieter und sagst: Diese Domain soll zu einer Website führen, die auf meinem Server mit dieser IP-Adresse liegt.

Wenn Besucher deine Domain, also zum Beispiel meinefirma.de, aufrufen, können ihre Browser genau das nachschlagen. Sie können also herausfinden, dass sie zu deinem Server müssen, wenn ihre Nutzer deine Seite aufrufen wollen. So finden sie das richtige Ziel, den richtigen Computer, also den richtigen Server.

Hast du das eingerichtet, landet der Browser deiner Besucher von nun an bei deinem Server, wenn deine Domain aufgerufen wird.

Jetzt wäre der nächste logische Schritt der, dass der Browser zu deinem Server sagt: „Hi Server, ich weiß, dass auf dir eine Seite mit der Domain so und so liegt, und ich soll meinem Nutzer diese Seite anzeigen. Lass mich mal bitte mit dem Programm auf dir sprechen, das mir die Seite aussuchen und geben kann.“

Diesen zusätzlichen Auskunftsschritt gibt es aber nicht. Dein Browser kann direkt zum zuständigen Programm auf dem Server.

Möglich wird das durch sogenannte „Ports“.

Ein Port ist wie eine Art „Zimmernummer“ in einem Hotel. Ein Programm, das Verbindungen entgegennimmt, kann sozusagen in einem bestimmten Zimmer auf sie warten.

Und ein Browser weiß: Wenn in der Webadresse kein anderer Port angegeben ist, verwende ich für HTTPS immer Port 443 und für HTTP immer Port 80. Dort erwartet er dann in aller Regel das Programm, das ihm die Website ausliefert.

Und weil deine Webadresse https://meinefirma.de lautet, weiß der Browser: Die IP-Adresse zu dieser Domain kann ich über DNS herausfinden. Und das Programm, mit dem ich für diese HTTPS-Verbindung sprechen soll, erwarte ich an Port 443 unter dieser IP-Adresse. Bei der Verbindung und der anschließenden Anfrage übermittelt der Browser außerdem den Domainnamen. So kann nginx die richtige Website auswählen, auch wenn es mehrere Websites unter derselben IP-Adresse betreut.

Aber Achtung: Dass nginx an diesen beiden Ports auf Anfragen wartet, ist Konvention, kein Muss. Du kannst nginx auch so einstellen, dass es an einem anderen Port wartet.

Dann muss der Browser diesen anderen Port kennen, etwa weil er zusätzlich in der Webadresse steht. Welche Ports nginx benutzt, hängt von seiner Einrichtung ab. Port 80 ist bei einer üblichen Installation oft schon vorbereitet. Port 443 und die verschlüsselte Verbindung für HTTPS richten wir gleich noch ein. Du prüfst also in den Einstellungen, ob nginx an den vorgesehenen Ports auf Anfragen wartet.

Sobald du auch diesen Schritt erledigt hast, bist du ein sehr großes Stück weiter.

Du hast jetzt die grundlegenden Bestandteile zusammen: Deine Website. Einen Server, auf dem deine Website in einem Ordner liegt. Eine Domain für deine Website, die auf die IP-Adresse deines Servers zeigt. Und nginx, das auf deinem Server läuft und versteht, welche Seite es einem Browser anzeigen soll, wenn der eine Verbindung zum richtigen Port aufbaut und ihm sagt: „Ich hätte gerne die Website meinefirma.de.“

Wir sind aber noch nicht fertig.

Denn was du für deinen Server auch noch einrichten solltest, ist die Firewall. Das solltest du immer erledigen, bevor du die Adresse deiner Website weitergibst.

Und was macht die Firewall?

Sie entscheidet nach deinen Regeln, welche Verbindungen erlaubt sind. Für Besucher öffnest du die Zugänge zum Webserver, also Port 80 und Port 443. Port 80 brauchst du auch für den nächsten Schritt, denn darüber wird in der Regel geprüft, ob die Domain wirklich zu deinem Server führt. Deinen Verwaltungszugang schützt du gesondert und achtest darauf, ihn nicht versehentlich zu sperren. Programme, die nur innerhalb des Servers zusammenarbeiten, brauchen keinen offenen Zugang für alle im Internet.

Sobald du die Firewall eingerichtet hast, kommen wir endlich zum letzten Schritt: Die HTTPS-Adresse.

Was heißt das?

Nun, wir hatten ja gerade schon von https:// gesprochen. Es steht am Anfang vieler Webadressen, noch vor der Domain, und wir haben gerade gesagt: Wenn jemand so eine Seite will, verbindet sich der Browser in der Regel mit Port 443 auf diesem Server.

Aber was ist HTTPS nun? HTTPS sorgt für eine verschlüsselte Verbindung zwischen Browser und Webserver. Dadurch kann ein Hacker zum Beispiel deine Anmeldedaten für deine Bank nicht einfach mitlesen oder die übertragenen Inhalte unbemerkt verändern.

Damit das funktioniert, braucht dein Webserver ein gültiges Zertifikat für deine Domain und den dazugehörigen privaten Schlüssel.

Stell dir das Zertifikat wie einen Ausweis vor.

Der Browser deines Besuchers sagt praktisch zum Server: „Ich möchte gerne meinefirma.de aufrufen, aber ich will prüfen können, dass du dich für genau diesen Domainnamen ausweisen kannst. Nicht, dass mich jemand unterwegs auf einen fremden Server umleitet, der sich nur als meinefirma.de ausgibt.“

Zertifikate sind also wie Ausweise. Der Browser sagt: „Zeig mir mal deinen Ausweis.“

Der Server zeigt ihn und beweist so, dass er der richtige Server ist.

Solche Zertifikate gibt es kostenlos, beispielsweise von Let’s Encrypt. Sie müssen regelmäßig erneuert werden. Das lässt du automatisch erledigen.

So, und wenn du das alles erledigt hast, kommt der große Moment.

Du greifst jetzt zu deinem Handy, schaltest die Verbindung zu deinem WLAN aus und öffnest https://meinefirma.de über das Mobilnetz. Du prüfst also den Aufruf von einem anderen Internetanschluss aus.

Der Browser findet über DNS die Adresse deines Servers. Er baut die geschützte Verbindung zum Webserver auf und fordert die Seite an.

nginx schickt die vorbereitete Datei zurück.

Du siehst jetzt deine Website – im Browser unter deiner Domain.

Du kannst deinen Laptop jetzt ausschalten. Die Seite bleibt erreichbar. Alles, was dafür nötig ist, läuft auf dem gemieteten Server.

Und du bist überglücklich, dass du etwas gemacht hast, was du dir vorher vielleicht nicht zugetraut hast: Du hast den aufwendigeren Weg gewählt und dir die Mühe gemacht, deine Seite selbst zu hosten und die Verwaltung selbst zu übernehmen. Vom Anbieter deines gemieteten Servers bist du weiterhin abhängig, aber du bist nicht mehr auf die Möglichkeiten eines fertigen Webhostingpakets beschränkt.

Damit kommen mehr Freiheit bei der Einrichtung und ein Wissen, das dich als Online-Marketer noch einmal deutlich attraktiver machen kann. Denn viele Online-Marketer wissen nur sehr wenig über den Gegenstand, der eigentlich eine zentrale Grundlage ihrer täglichen Arbeit bildet: die Website.

Und wenn du wirklich verstehen willst, was eigentlich auf einer Website alles passiert, empfehle ich dir meinen Kurs „Was passiert im Browser?“ unter trace5.co. Du verfolgst dort Schritt für Schritt und im Detail, welche Schritte nacheinander passieren, sobald jemand eine Domain im Browser eingibt.

Auf diese Art und Weise lernst du die technische Grundlage deiner Arbeit als Online-Marketer kennen: die Website. So kannst du nach dem Kurs mehr aus deinen Paid-Ads-Kampagnen oder deiner SEO-Arbeit holen, weil du technische Probleme selbst identifizieren oder auf einem anderen Niveau mit deiner IT klären kannst – und natürlich aus der Masse von Online-Marketern herausstechen, für die die Technik hinter einer Website ein Buch mit sieben Siegeln ist.

So, und das war es schon für heute. Wie gesagt: Den kompletten Schritt-für-Schritt-Prozess mit allen Details kannst du dir von trace5.co kostenlos als PDF herunterladen.

Und falls du überrascht bist, weil wir noch nicht über die Verantwortung gesprochen hast, die du mit dem Hosten übernimmst: Keine Sorge. Wir schauen uns das detailliert in der nächsten Folge an. Ich wollte nur nicht diese Folge mit Infos überfrachten und das Thema zu sehr in die Länge ziehen.

Also: Wir hören uns!