Shell, HTML, CGI
Webseiten als echte Dateien, Upload per FTP, einfache CGI-Skripte, Logdateien und direkte Verantwortung für jeden Pfad.
Seit 1996: bauen, prüfen, pflegen, vereinfachen.
Ein Webmaster war ursprünglich nicht nur jemand, der Texte in eine Oberfläche einträgt. Die Rolle umfasste den gesamten Weg einer Website: Dateien anlegen, Struktur planen, Inhalte prüfen, Serverpfade verstehen, Fehler finden, Seiten hochladen, Logdateien lesen und dafür sorgen, dass das Ergebnis auch Monate oder Jahre später noch funktioniert.
Genau in diesem Sinn verstehe ich die Aufgabe bis heute. Die technische Webbetreuung begann . Seitdem hat sich fast jedes Werkzeug verändert, nicht aber die grundlegende Verantwortung: Eine Website muss erreichbar, verständlich, wartbar und ehrlich sein. Sie soll ihre Aufgabe erfüllen, ohne den Besucher mit unnötiger Technik zu belasten.
Diese Seite beschreibt nicht die gesamte technische Biografie hinter sslxy; dafür gibt es die sslxy-Übersicht. Hier geht es gezielt um die Webmaster-Arbeit: ihre Entwicklung, ihre täglichen Aufgaben, die technische Haltung dahinter und die Frage, warum handgeschriebene Websites auch heute noch sinnvoll sein können.
Webseiten als echte Dateien, Upload per FTP, einfache CGI-Skripte, Logdateien und direkte Verantwortung für jeden Pfad.
Wachsende Inhalte, Browserunterschiede und immer neue Techniken – aber weiterhin klare Dateien und kontrollierbare Abhängigkeiten.
Responsive Layouts, semantisches HTML, schnellere Auslieferung und stärkere Trennung von Inhalt, Gestaltung und Funktion.
Technische Modernisierung ohne Baukasten: barrierearme Struktur, Datenschutz, Sicherheitsheader, strukturierte Daten und ruhige Langzeitpflege.
/sslxy/ das Zuhause von sslxy istAuf den ersten Blick wirkt es ungewöhnlich, dass die technische Heimat von sslxy nicht auf einer eigenen großen Webmaster-Domain liegt, sondern in einem Unterverzeichnis von hotel-goldener-ochsen-hohenstaufen.de. Genau darin liegt aber die eigentliche Geschichte.
Die Website des Goldenen Ochsen gehört zu den frühesten Webauftritten, die von sslxy technisch aufgebaut und über viele Jahre hinweg betreut wurden. Die Webbetreuung begann . Diese Domain ist deshalb nicht irgendein zufälliger Speicherplatz und auch kein später ausgewählter Werbeträger, sondern Teil der eigenen Webgeschichte.
Das Verzeichnis /sslxy/ ist gewissermaßen der technische Dachboden innerhalb eines sehr lange gepflegten Hauses. Dort können Erinnerungen an frühe Rechner, Shell-Accounts, DFÜ, Hardware, Werkstatt, Webentwicklung und heutige Werkzeuge zusammengeführt werden, ohne daraus eine neue Agenturmarke oder einen eigenständigen Geschäftsbetrieb zu machen.
sslxy ist ein technischer Benutzername beziehungsweise ein über Jahrzehnte erhaltenes Pseudonym. Unter diesem Namen wird auf dieser Seite kein rechtlich eigenständiger Betrieb mit eigener Geschäftsanschrift, eigenem Ladenlokal oder eigener Telefonzentrale dargestellt. Die Seite enthält auch keinen Onlineshop, keine Benutzerkonten und keine unmittelbare Möglichkeit, kostenpflichtige Webmaster-Leistungen zu bestellen.
Deshalb wird für sslxy nicht künstlich ein zweites vollständiges Impressum mit einer nochmals wiederholten Anschrift und Telefonnummer aufgebaut. Anbieter der gesamten Domain – einschließlich des Unterverzeichnisses /sslxy/ – bleibt der im zentralen Impressum der Domain bezeichnete Betreiber. Dieses zentrale Impressum ist von jeder sslxy-Seite aus direkt verlinkt.
Der sslxy-Bereich ist bewusst zurückhaltend gestaltet. Sichtbar ist der technische Name, nicht ein ausführliches privates Personenprofil. Das ist eine Form von Inkognito: Die Inhalte sollen für sich stehen, ohne aus jeder technischen Erinnerung einen öffentlich auswertbaren Lebenslauf zu machen.
Inkognito bedeutet hier jedoch nicht, dass die Website ohne verantwortlichen Anbieter im Netz steht. Die Domain besitzt ein zentrales Impressum und eine Datenschutzerklärung. Wer wissen muss, wer für die Domain verantwortlich ist, findet diese Angaben dort. Der sslxy-Bereich benötigt lediglich keine zusätzliche, davon abweichende Identität mit eigener Adresse oder Telefonnummer.
Eine eigene Domain wäre technisch problemlos möglich, würde aber eine Trennung vortäuschen, die historisch und praktisch gar nicht besteht. sslxy ist aus der Betreuung bestehender Websites entstanden – und diese konkrete Domain ist eines der ältesten erhaltenen Beispiele dafür.
„Nicht auf einer fremden Domain untergebracht, sondern im ältesten noch gepflegten Haus ein eigenes technisches Zimmer behalten.“
Der Begriff Webmaster wirkt heute beinahe altmodisch. Gerade deshalb beschreibt er meine Arbeit besser als viele modernere Rollenbezeichnungen. Ein Webmaster denkt nicht nur an eine einzelne Funktion und auch nicht nur an sichtbares Design. Er hält das gesamte System zusammen: Inhalt, Struktur, Technik, Veröffentlichung, Auffindbarkeit, Sicherheit und spätere Pflege.
Bei einer kleinen oder mittelgroßen statischen Website gibt es keine klare Trennung zwischen Redaktion, Frontend, technischer SEO, Qualitätssicherung und Betrieb. Eine Änderung am Text kann Auswirkungen auf Navigation, Suchergebnisse, strukturierte Daten, interne Verlinkung und sogar rechtliche Aussagen haben. Deshalb ist die wichtigste Fähigkeit nicht das schnelle Erzeugen möglichst vieler Dateien, sondern das Erkennen solcher Zusammenhänge.
Seiten, Überschriften, Navigation, Dateinamen und interne Links müssen ein nachvollziehbares System bilden.
Informationen müssen richtig, aktuell, verständlich und auf allen betroffenen Seiten konsistent sein.
HTML, CSS, JavaScript, Serverregeln und Metadaten dürfen sich nicht gegenseitig widersprechen.
Eine Seite ist nicht fertig, wenn sie lokal gut aussieht. Sie muss auf dem Server richtig ausgeliefert werden.
Diese Gesamtverantwortung ist der Grund, warum ich lieber langsam und kontrolliert arbeite. Eine schnelle Einzeländerung kann später mehr Arbeit erzeugen als sie zunächst spart. Gute Pflege bedeutet deshalb auch, vor jeder Änderung zu verstehen, welche anderen Stellen davon berührt werden.
„Webmaster sein heißt nicht, möglichst viel Technik einzubauen. Es heißt, für das Ganze verantwortlich zu bleiben.“
Eine Website mit vielen Jahren Geschichte darf nicht wie ein Wegwerfprojekt behandelt werden. Vor einer Änderung wird deshalb zuerst geklärt, was tatsächlich geändert werden soll, welche Seiten betroffen sind und welche Aussagen ausdrücklich unverändert bleiben müssen.
Handgeschriebener Code ist kein nostalgisches Ziel und auch kein Qualitätsmerkmal an sich. Schlechter handgeschriebener Code bleibt schlechter Code. Der Vorteil liegt woanders: Jede Abhängigkeit, jede Klasse, jedes Skript und jeder Datenblock ist unmittelbar sichtbar. Die Seite kann ohne Build-System geöffnet, gelesen und geändert werden.
Für eine überschaubare Informationswebsite ist diese direkte Kontrolle wertvoll. Es gibt keine Datenbank, die unbemerkt ausfällt, kein Plugin, das nach einem Update seine Oberfläche verändert, und keinen Baukasten, der den erzeugten Code hinter einer Bedienoberfläche versteckt.
HTML beschreibt die Bedeutung und Reihenfolge der Inhalte. Überschriften, Abschnitte, Navigationen, Adressen, Listen, Zeitangaben und ergänzende Hinweise erhalten passende semantische Elemente. Das verbessert nicht nur die Maschinenlesbarkeit, sondern macht den Quelltext auch für spätere Wartung verständlicher.
CSS soll Inhalte ordnen, nicht verdecken. Abstände, Schriftgrößen, Kontraste, responsive Raster und sichtbare Fokuszustände werden zentral definiert. Die mobile Darstellung ist keine abgespeckte Nebenversion, sondern dieselbe Information in einer anderen räumlichen Anordnung.
JavaScript wird dort eingesetzt, wo es einen konkreten Nutzen gibt: dynamische Jahreszahlen, Tagesinformationen, Kartenanbieter-Auswahl, Nach-oben-Schaltfläche oder Tastaturkürzel. Die eigentlichen Inhalte und die Navigation bleiben auch ohne JavaScript zugänglich.
Eine Website muss nicht alle zwei Jahre neu gebaut werden, nur weil sich Designtrends ändern. Ein vollständiger Neuanfang vernichtet oft bewährte Strukturen, alte Verlinkungen und eingespielte Suchsignale. Sinnvoller ist eine kontrollierte Weiterentwicklung: technische Schwächen beseitigen, Inhalte aktualisieren und die Oberfläche dort modernisieren, wo es die Nutzung tatsächlich verbessert.
Langfristige Pflege bedeutet auch, Altlasten bewusst zu erkennen. Dazu gehören doppelte Seiten, veraltete Dateinamen, nicht mehr benötigte Service Worker, alte Weiterleitungen, uneinheitliche Kontaktangaben oder Aussagen, die sich über verschiedene Sprachversionen auseinanderentwickelt haben.
Welche Dateien sind kanonisch, welche nur Altpfade, welche dürfen indexiert werden und welche nicht?
Stimmen Preise, Zeiten, Leistungen, Kontaktwege und betriebliche Hinweise auf allen Seiten überein?
Funktionieren Navigation, Bilder, Sprunglinks, Skripte, Manifest, Icons und Fehlerseiten noch?
Sind Weiterleitungen, Caching, Komprimierung, CSP und Sicherheitsheader zur aktuellen Dateiversion passend?
Die wichtigste Wartungsregel lautet deshalb: Erst verstehen, dann ändern. Eine alte Datei ist nicht automatisch schlecht. Sie kann sehr gut funktionieren und trotzdem einzelne Stellen enthalten, die heute präziser oder sicherer gelöst werden sollten.
Inhalte werden häufig als rein redaktionelle Aufgabe betrachtet. Auf einer kleinen Unternehmenswebsite sind sie jedoch unmittelbar mit der Technik verbunden. Ein geänderter Zimmerpreis betrifft möglicherweise sichtbaren Text, strukturierte Angebote, FAQ-Antworten, Meta-Beschreibungen und fremdsprachige Varianten.
Dasselbe gilt für betriebliche Einschränkungen. Wenn eine Gaststätte nur unregelmäßig geöffnet ist, darf keine technische Darstellung versehentlich regelmäßige Öffnungszeiten behaupten. Wenn Reservierungen ausschließlich telefonisch möglich sind, darf ein E-Mail-Link nicht gleichzeitig als Buchungsweg beworben werden.
Gute Webmaster-Arbeit hält deshalb nicht nur den Code konsistent, sondern auch die Aussagen. Dabei ist Zurückhaltung wichtig: Eine Website sollte keine Leistungen, Eigenschaften oder Verfügbarkeiten versprechen, die der Betrieb nicht zuverlässig erbringen kann.
Barrierearme Gestaltung beginnt nicht bei einem nachträglich eingebauten Symbol. Sie beginnt mit verständlicher Sprache, sinnvoller Reihenfolge, ausreichenden Kontrasten und einer Bedienung, die nicht ausschließlich von Maus, Farbe oder Animation abhängt.
Vollständige Barrierefreiheit ist mehr als ein automatischer Prüfwert. Trotzdem helfen klare technische Regeln, viele typische Hindernisse von Anfang an zu vermeiden. Entscheidend ist, dass die Seite nicht nur formal besteht, sondern tatsächlich lesbar und bedienbar bleibt.
Schnelle Seiten sind nicht nur ein technischer Wettbewerb. Sie sparen Zeit, Datenvolumen und Energie. Besonders auf mobilen Verbindungen ist jede unnötige Bibliothek spürbar. Eine Informationsseite sollte deshalb nicht mehrere Megabyte laden, bevor der Besucher eine Telefonnummer oder Anfahrtsbeschreibung lesen kann.
Die wirksamsten Maßnahmen sind meistens unspektakulär: wenige Abhängigkeiten, passende Bildgrößen, begrenztes JavaScript, sinnvolle Caching-Regeln, Komprimierung und ein stabiler Seitenaufbau ohne nachträgliche Verschiebungen.
Performance bleibt dabei eine laufende Aufgabe. Neue Bilder, zusätzliche Sprachversionen oder kleine Skriptänderungen können die Werte verändern. Deshalb zählt nicht nur ein einmaliger Prüfbericht, sondern die Disziplin bei jeder späteren Ergänzung.
Eine statische Website besitzt eine kleinere Angriffsfläche als ein komplexes System mit Datenbank, Benutzerkonten und zahlreichen Erweiterungen. Sie ist deshalb aber nicht automatisch sicher. Serverkonfiguration, Dateirechte, HTTPS, Fehlerseiten und HTTP-Header müssen trotzdem kontrolliert werden.
Eine Content Security Policy begrenzt, welche Skripte, Bilder, Styles und Verbindungen der Browser akzeptiert. Bei lokalem Inline-JavaScript können gezielte SHA-256-Hashes eingesetzt werden. Jede Änderung am betreffenden Skript erzeugt dann einen neuen Hash, der auch in der Serverkonfiguration aktualisiert werden muss.
Header wie HSTS, Referrer-Policy oder Schutzvorgaben gegen unerwünschte Einbettung können die technische Auslieferung absichern. Sie müssen jedoch zur tatsächlichen Website passen. Ein möglichst langer Headerblock ist nicht automatisch besser; falsch gewählte Richtlinien können legitime Funktionen blockieren.
Fehlerseiten sollten korrekt mit dem HTTP-Status 404 ausgeliefert werden. Dauerhafte Weiterleitungen benötigen den Status 301 oder 308, temporäre Weiterleitungen einen passenden temporären Status. Eine sichtbare Startseite bei einer nicht vorhandenen URL darf nicht versehentlich als erfolgreiche Seite mit Status 200 erscheinen.
Datenschutz wird häufig erst betrachtet, nachdem eine Website bereits mit Analysewerkzeugen, externen Schriftarten, eingebetteten Karten und Marketingdiensten aufgebaut wurde. Dann entsteht ein erheblicher Aufwand, um Einwilligungen, Widerruf und Drittanbieterinformationen nachträglich zu verwalten.
Der einfachere Weg ist, unnötige Datenverarbeitung gar nicht erst einzubauen. Eine statische Website kann informieren, navigieren und Kontaktwege bereitstellen, ohne Besucherprofile zu erzeugen. Externe Kartendienste lassen sich verlinken, statt sie sofort einzubetten. Lokale Schriften und Bilder vermeiden zusätzliche Verbindungen.
Diese Reduktion ist nicht nur datenschutzfreundlich. Sie verbessert zugleich Performance, Stabilität und Wartbarkeit. Weniger externe Abhängigkeiten bedeuten weniger Stellen, die unbemerkt ihr Verhalten ändern können.
Technische Suchmaschinenoptimierung beginnt mit erreichbaren Seiten, eindeutigen Adressen, sinnvollen Seitentiteln, passenden Beschreibungen und einer klaren internen Verlinkung. Strukturierte Daten können zusätzlich ausdrücken, welche Organisation, welches Angebot oder welche Seite beschrieben wird.
Maschinenlesbarkeit ersetzt jedoch keine verständlichen Inhalte. Suchmaschinen und generative Antwortsysteme können nur dann zuverlässige Informationen übernehmen, wenn die Website eindeutige, widerspruchsfreie Fakten bereitstellt. Übertriebene Werbesprache und künstlich wiederholte Schlüsselbegriffe helfen dabei weniger als klare Antworten.
Eine gute Website beantwortet zuerst die Fragen echter Besucher. Wenn diese Antworten klar strukturiert sind, werden sie in der Regel auch für Suchsysteme verständlicher.
Eine Seite kann im Browser ordentlich aussehen und trotzdem technische Fehler enthalten. Deshalb werden verschiedene Ebenen getrennt geprüft. Ein fehlerfreier Einzeltest ist dabei kein Beweis für die vollständige Qualität, aber mehrere gezielte Prüfungen reduzieren typische Risiken deutlich.
Eine H1, nachvollziehbare Überschriften, keine doppelten IDs und erreichbare Sprungziele.
Gültige JavaScript-Syntax, vorhandene Ziele und kontrolliertes Verhalten ohne unnötige globale Abhängigkeiten.
Gültiges JSON-LD, passende URLs und keine Abweichung zwischen sichtbarem Text und strukturierten Angaben.
HTTP-Status, Header, Weiterleitungen, Cache-Verhalten, mobile Darstellung und echte externe Ziele.
Automatische Werkzeuge sind hilfreich, aber nicht ausreichend. Sie erkennen beispielsweise nicht zuverlässig, ob ein Gaststättenhinweis betrieblich korrekt ist oder ob eine sprachliche Übersetzung den Inhalt unzulässig verkürzt. Dafür bleibt menschliche Prüfung notwendig.
Werkzeuge haben sich seit 1996 stark verändert. Ein moderner Browser zeigt Fehler direkt in den Entwicklerwerkzeugen, Validatoren prüfen strukturierte Daten und Skripte, und KI-Systeme können bei der Analyse großer Dateien oder beim Erstellen konsistenter Varianten unterstützen.
Trotzdem bleibt ein Werkzeug nur ein Werkzeug. Es trägt keine Verantwortung für die veröffentlichte Aussage. Gerade KI kann sehr überzeugend formulieren und dabei Details verkürzen, erfinden oder miteinander vermischen. Deshalb wird ein erzeugter Vorschlag nicht allein deshalb übernommen, weil er sprachlich sauber klingt.
Die Domain des Goldenen Ochsen ist kein kurzfristiges Vorzeigeprojekt, sondern ein über viele Jahre gewachsenes System. Genau deshalb eignet sie sich als Beispiel für langfristige Webmaster-Arbeit. Alte Dateistrukturen, neue Anforderungen, betriebliche Veränderungen und zahlreiche Sprachversionen müssen zusammengeführt werden, ohne die bestehende Auffindbarkeit und die gewachsene Identität zu verlieren.
Startseite, Hotelzimmer, Anfahrt, Kontakt, FAQ, Impressum und Datenschutz bilden ein konsistentes Grundsystem.
Hotelbetrieb, Gaststätte und Metzgerei müssen korrekt unterschieden werden, ohne den Gesamtbetrieb künstlich zu verengen.
Übersetzungen sollen den vollständigen Inhalt erhalten und zugleich klare Regeln für Indexierung, Bildpfade und Kontaktwege beachten.
Responsive Gestaltung, strukturierte Daten, Sicherheitsheader und Barrierearmut werden ergänzt, ohne einen Baukasten einzuführen.
Die Arbeit daran zeigt sehr deutlich, dass technische Qualität nicht allein aus neuem Code besteht. Ein großer Teil ist sorgfältige Konsistenzarbeit: alte Seiten auffinden, falsche Aussagen entfernen, Metadaten angleichen, Weiterleitungen prüfen und darauf achten, dass keine Sprachversion unbemerkt auf einen früheren Stand zurückfällt.
Der sichtbare Stil darf sich modernisieren. Die Identität des Betriebs und die praktische Nutzbarkeit für den Gast müssen dabei erhalten bleiben.
Die Stärke einer kleinen technischen Betreuung liegt nicht darin, jede denkbare Leistung anzubieten. Sie liegt darin, den eigenen Umfang zu kennen und ein überschaubares System zuverlässig zu beherrschen.
Diese Begrenzung ist kein Mangel, sondern Teil der Wartbarkeit. Ein System bleibt dann zuverlässig, wenn seine Komplexität zur tatsächlichen Aufgabe passt.
„Nicht alles bauen, was technisch möglich ist. Nur das, was der Betrieb wirklich braucht und langfristig tragen kann.“
Browser, Suchsysteme und rechtliche Rahmenbedingungen werden sich weiter verändern. Die Antwort darauf kann nicht sein, jeder Entwicklung sofort hinterherzulaufen. Sinnvoller ist eine stabile Grundlage, auf der notwendige Änderungen gezielt nachgezogen werden können.
Für die weitere Pflege bedeutet das: Inhalte aktuell halten, neue Abhängigkeiten kritisch prüfen, alte Pfade kontrolliert abbauen und die Website regelmäßig aus Sicht echter Besucher testen. Dazu gehört auch, bestehende Regeln zu hinterfragen, wenn sich der Betrieb oder die Technik verändert.
Langfristige Wartbarkeit entsteht nicht durch eine letzte endgültige Version. Sie entsteht durch eine nachvollziehbare Struktur, klare Entscheidungen und die Bereitschaft, kleine Korrekturen rechtzeitig durchzuführen.
„Eine gute Website ist nicht für den nächsten Screenshot gebaut, sondern für den nächsten notwendigen Handgriff.“
Diese Seite liegt im eigenständigen sslxy-Bereich der Domain und beschreibt die technische Webmaster-Arbeit, Arbeitsweise und langfristige Betreuung statischer Websites.
Der Bereich /sslxy/ ist kein eigenständiger Anbieter und kein gesonderter Geschäftsbetrieb. Er ist ein technischer Archiv- und Erinnerungsbereich innerhalb der Domain des Goldenen Ochsen.
Anbieter und Verantwortlicher der gesamten Domain ist der Betreiber des Goldenen Ochsen in Göppingen-Hohenstaufen. Die leicht erreichbaren Anbieterangaben stehen im zentralen Impressum der Domain. Sie gelten auch für diesen Unterbereich. Eine davon abweichende eigene Geschäftsanschrift oder Telefonnummer für das Pseudonym sslxy besteht nicht.
Kontakt für technische Rückfragen: mail@sslxy.de
Diese Webmaster-Seite ist als rein informative, statische HTML-Seite konzipiert. Es werden keine Tracker, keine Analyse-Tools und keine zustimmungspflichtigen Cookies eingesetzt.
Handgeschriebene Seite. Lokale Gestaltung. Keine unnötige Datensammlung.