Webmaster-Arbeit seit 1996

[history/from_subdirectory_to_domain]

Vom Unterverzeichnis zur eigenständigen Domain sslxy.de

Der heutige Standort unter sslxy.de ist das Ergebnis einer bewussten Trennung. Das Archiv lag zuvor über längere Zeit im Verzeichnis /sslxy/ innerhalb der Website des Hotel Goldener Ochsen. Diese frühere Unterbringung gehört zur Geschichte des Archivs, war aber keine Aussage darüber, dass sslxy mit dem Hotelbetrieb identisch wäre.

Die Verbindung entstand aus der langjährigen technischen Begleitung der Hotel-Website. Die Webarbeit an diesem Projekt reicht bis 1996 zurück. Dadurch bot sich die bestehende Infrastruktur lange Zeit als praktischer Ort für technische Erinnerungen, Rechnergeschichte, DFÜ, Hardware, Werkstattnotizen und Webdokumentation an.

Mit der eigenständigen Domain wird diese historische Nähe nicht gelöscht, sondern sauberer eingeordnet: sslxy.de ist ein privates, nicht-kommerzielles Technik- und Webarchiv mit eigener technischer Struktur, eigener Anbieter- und Datenschutzerklärung sowie eigenen kanonischen URLs. Die Website des Hotel Goldener Ochsen bleibt ein langjährig technisch begleitetes Webprojekt und damit Teil der dokumentierten Webgeschichte.

Keine künstliche Unternehmensidentität

Die neue Domain macht aus sslxy weder eine Agentur noch ein Unternehmen. Unter der Bezeichnung werden keine kostenpflichtigen Webdesign-, Hosting-, Programmier- oder Beratungsleistungen angeboten. Die Domain dient der Dokumentation und Archivierung.

Diese Trennung ist auch sprachlich wichtig. sslxy wird auf den Archivseiten nicht als Person, Gründer, Webmaster oder Betreiber personifiziert. Personenbezogene und rechtlich erforderliche Angaben stehen ausschließlich dort, wo sie für Impressum oder Datenschutz tatsächlich benötigt werden.

Historische Verbindung bleibt sichtbar

Die frühere Unterbringung im Hotel-Webauftritt bleibt als Teil der Entstehungsgeschichte dokumentierbar. Sie ist jedoch nicht mehr die Navigations-, Canonical- oder Identitätsgrundlage des Archivs. Sämtliche neuen und überarbeiteten SSLXY-Seiten beziehen sich auf https://sslxy.de/.

• Eigenständige Domain und kanonische URLs unter sslxy.de.
• Keine Agentur- oder Unternehmensdarstellung.
• Keine Personifizierung des Archivnamens.
• Historische Verbindung zum Goldenen Ochsen bleibt als Webgeschichte erhalten.
• Impressum und Datenschutz sind Bestandteile der eigenständigen Archivdomain.

„Historische Verbindungen bleiben dokumentiert; technische Zuständigkeiten und Domains werden trotzdem sauber getrennt.“

Vertiefung: Erste Webseiten 1995–1996 dokumentiert die erste öffentliche Webspur; Webentwicklung 1996 den technischen Arbeitskontext dieser frühen Phase.

[role/definition]

Was die klassische Webmaster-Rolle umfasst

Der Begriff Webmaster wirkt heute beinahe historisch, beschreibt aber eine weiterhin sinnvolle Perspektive auf kleinere und mittelgroße Websites. Gemeint ist nicht nur sichtbares Design oder eine einzelne technische Funktion, sondern der Zusammenhang von Inhalt, Struktur, Technik, Veröffentlichung, Auffindbarkeit, Sicherheit und späterer Pflege.

Bei einer überschaubaren statischen Website lassen sich Redaktion, Frontend, technische Suchmaschinenoptimierung, Qualitätssicherung und Betrieb nicht immer vollständig voneinander trennen. Eine Textänderung kann Navigation, Suchdarstellung, strukturierte Daten, interne Links und rechtliche Aussagen gleichzeitig berühren. Entscheidend ist deshalb nicht die möglichst schnelle Erzeugung vieler Dateien, sondern das Erkennen dieser Abhängigkeiten.

Diese Gesamtbetrachtung spricht für eine kontrollierte Arbeitsweise. Eine scheinbar kleine Einzeländerung kann später mehr Aufwand erzeugen, wenn abhängige Stellen übersehen werden. Gute Pflege beginnt deshalb mit der Frage, welche weiteren Bereiche von einer Änderung betroffen sind.

„Webmaster-Arbeit bedeutet nicht, möglichst viel Technik einzubauen, sondern den Zusammenhang des gesamten Systems zu verstehen.“

[workflow/change_control]

Wie eine Änderung durchgeführt wird

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.

1. Ist-Zustand sichern.
   Die aktuelle Datei wird vollständig gelesen und als Ausgangspunkt erhalten. Änderungen erfolgen nicht an einer aus dem Gedächtnis nachgebauten Kurzfassung.
2. Maßgebliche Information bestimmen.
   Bei widersprüchlichen Angaben wird festgelegt, welche aktuelle Seite oder betriebliche Aussage maßgeblich ist.
3. Änderungsumfang begrenzen.
   Nur die vereinbarten Inhalte werden verändert. Gestaltung, Funktionen oder Texte außerhalb des Auftrags bleiben bestehen.
4. Abhängigkeiten prüfen.
   Eine Änderung kann Metaangaben, JSON-LD, FAQ, Navigation, interne Links, Sprachversionen oder Sicherheitsrichtlinien betreffen.
5. Datei vollständig erzeugen.
   Am Ende steht keine lose Textstelle, sondern eine komplette und direkt nutzbare HTML-Datei.
6. Technisch validieren.
   Geprüft werden unter anderem JSON-LD, JavaScript-Syntax, Überschriftenstruktur, doppelte IDs und interne Sprungziele.
7. Serverkontext beachten.
   Dateiname, Pfad, Canonical, Sicherheitsheader, CSP-Hash und Weiterleitungen müssen zur tatsächlichen Veröffentlichung passen.
8. Live prüfen.
   Nach dem Upload zählen nicht nur der Quelltext, sondern die ausgelieferten Header, die echte Darstellung und die erreichbaren Ziele.

Zusammenhang: Software- und Tool-Alltag behandelt Werkzeugwahl und Prüfabläufe; Datensicherung und Backups den Rückfall- und Wiederherstellungspfad.

[stack/handwritten]

Warum der Code handgeschrieben bleibt

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 als Grundstruktur

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 als kontrollierte Gestaltung

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 nur für klar begrenzte Funktionen

JavaScript wird dort eingesetzt, wo es einen konkreten Nutzen gibt: dynamische Jahres- oder Standangaben, Nach-oben-Schaltflächen, kleine Bedienhilfen oder Tastaturkürzel. Die eigentlichen Inhalte und die Navigation bleiben auch ohne JavaScript zugänglich.

Vertiefung: Webentwicklung 1996 und Erste Webseiten 1995–1996 zeigen die historischen Wurzeln dieser direkten Arbeitsweise.

[maintenance/long_term]

Langfristige Pflege statt regelmäßiger Neuerfindung

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.

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.

[content/canonical_facts]

Inhaltliche Konsistenz ist technische Arbeit

Inhalte werden häufig als rein redaktionelle Aufgabe betrachtet. Auf einer technisch gepflegten Informationswebsite sind sie jedoch unmittelbar mit der Technik verbunden. Eine geänderte Kernaussage kann sichtbaren Text, strukturierte Daten, FAQ-Antworten, Meta-Beschreibungen, interne Verlinkung und fremdsprachige Varianten gleichzeitig betreffen.

Besonders deutlich wird das bei betrieblichen Informationen. 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. Solche Widersprüche sind zugleich Inhalts-, Technik- und Qualitätsfehler.

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.

[quality/accessibility]

Barrierearmut als Teil der Grundstruktur

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.

• Eine eindeutige Hauptüberschrift pro Seite.
• Logische Hierarchie der weiteren Überschriften.
• Skip-Link zum Hauptinhalt.
• Sichtbare Fokusmarkierungen für Tastaturbedienung.
• Beschreibende Linktexte statt unklarer „Hier“-Verweise.
• Alternative Texte für inhaltlich relevante Bilder.
• Ausreichende Schriftgrößen und mobile Umbrüche.
• Bedienbare Navigation ohne zwingenden JavaScript-Einsatz.
• Berücksichtigung reduzierter Bewegung, soweit dies nicht bewusst anders gestaltet wird.

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.

[quality/performance]

Performance ist eine Form von Respekt

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.

[quality/security]

Sicherheit ohne Sicherheits-Theater

Eine statische Website kann gegenüber einem komplexen System mit Datenbank, Benutzerkonten und zahlreichen Erweiterungen eine kleinere anwendungsseitige Angriffsfläche besitzen. Automatisch sicher ist sie deshalb nicht. Serverkonfiguration, Dateirechte, HTTPS, Fehlerseiten und HTTP-Header müssen trotzdem kontrolliert werden.

Content Security Policy

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.

Sicherheitsheader

Header wie HSTS, Referrer-Policy oder Vorgaben gegen unerwünschte Einbettung können die technische Auslieferung zusätzlich 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.

Fehler und Weiterleitungen

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.

Vertiefung: Server-Härtung behandelt TLS, CSP, Header, Rechte, Logs und Recovery; SSL und Zertifikate die Transport- und Zertifikatsebene.

[quality/privacy]

Datensparsamkeit als technische Entscheidung

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.

• Keine Tracking- oder Marketing-Cookies.
• Keine Analyse-Dienste.
• Keine eingebetteten Social-Media-Feeds.
• Keine automatische Verbindung zu Kartendiensten vor einem aktiven Klick.
• Keine unnötige Übermittlung personenbezogener Daten an KI-Systeme.
• Klare Trennung zwischen technischer Bereitstellung und inhaltlicher Bearbeitung.

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.

Aktuelle Einordnung: Die konkrete Datenverarbeitung auf sslxy.de steht in der Datenschutzerklärung.

[visibility/search_and_answers]

Auffindbarkeit, ohne Texte für Maschinen zu verbiegen

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 Informationen zuverlässiger einordnen, wenn eine Website eindeutige, widerspruchsfreie Fakten und nachvollziehbare Strukturen bereitstellt. Übertriebene Werbesprache und künstlich wiederholte Schlüsselbegriffe helfen dabei weniger als klare Antworten.

Technische Grundlagen

• Eindeutige kanonische URL pro Inhalt.
• Passender Indexierungsstatus für Haupt-, Hilfs- und Sprachseiten.
• Saubere Seitentitel und Beschreibungen.
• Logische Überschriftenstruktur.
• Interne Links auf die maßgeblichen Hauptseiten.
• JSON-LD ohne widersprüchliche oder erfundene Angaben.
• Sitemap nur mit tatsächlich indexierbaren kanonischen Seiten.
• Keine Blockierung einer Seite in robots.txt, wenn Suchmaschinen dort ein noindex lesen sollen.

Eine gute Website beantwortet zuerst die Fragen echter Besucher. Klare Strukturen und eindeutige Aussagen erleichtern anschließend auch Suchsystemen die technische Einordnung.

[quality/verification]

Prüfen heißt mehr als nur ansehen

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.

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.

Zusammenhang: CGI und Logdateien vertieft Laufzeitdiagnose und Protokolle; Shell-Accounts und Hosts die Systemebene dahinter.

[tools/practical_use]

Werkzeuge, KI und die Verantwortung für das Ergebnis

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.

Sinnvolle Unterstützung

• Vergleich langer HTML-Dateien.
• Suche nach inkonsistenten Begriffen und veralteten Angaben.
• Erzeugung vollständiger Sprachvarianten nach festen Regeln.
• Prüfung von JavaScript, JSON-LD, IDs und Sprungzielen.
• Formulierung verständlicher Alternativen zu technisch oder rechtlich schwer lesbaren Sätzen.

Nicht delegierbar

• Die Entscheidung, welche betriebliche Aussage tatsächlich stimmt.
• Die abschließende Prüfung veröffentlichter rechtlich relevanter Informationen.
• Die Prüfung, ob eine Übersetzung den vollständigen Inhalt erhält.
• Die Abwägung, welche personenbezogenen Daten überhaupt verarbeitet werden dürfen.
• Die Kontrolle der realen Serverkonfiguration nach dem Upload.

Vertiefung: Software- und Tool-Alltag behandelt Werkzeugwahl und technische Arbeitsmittel ausführlicher.

[webproject/goldener_ochsen]

Der Goldene Ochsen als langjährig begleitetes Webprojekt

Die Website des Hotel Goldener Ochsen in Göppingen-Hohenstaufen gehört zu den langjährig technisch begleiteten Webprojekten. Die technische Unterstützung erfolgt unentgeltlich und aus freundschaftlicher Verbundenheit. Sie ist kein kommerzielles Angebot von sslxy.de und wird hier ausschließlich als Teil der dokumentierten Webgeschichte genannt.

Gerade die lange Laufzeit macht das Projekt technisch interessant. Alte Dateistrukturen, neue Anforderungen, betriebliche Veränderungen, Suchmaschinenanforderungen und zahlreiche Sprachversionen müssen zusammengeführt werden, ohne gewachsene Inhalte oder funktionierende Pfade unnötig zu zerstören.

Das Projekt zeigt, dass technische Qualität nicht allein aus neuem Code besteht. Ein großer Teil ist sorgfältige Konsistenzarbeit: alte Seiten auffinden, unzutreffende Aussagen korrigieren, Metadaten angleichen, Weiterleitungen prüfen und verhindern, dass Sprachversionen unbemerkt auf unterschiedliche Sachstände auseinanderlaufen.

Der sichtbare Stil kann sich modernisieren. Die Identität des Betriebs, bestehende Inhalte und die praktische Nutzbarkeit für Gäste müssen dabei erhalten bleiben.

[scope/limits]

Bewusste technische Grenzen

Wartbare Systeme profitieren von einem klar abgegrenzten Umfang. Nicht jede verfügbare Technik verbessert eine Informationswebsite, und zusätzliche Abhängigkeiten müssen langfristig gepflegt, aktualisiert und geprüft werden.

• Keine künstliche Agentur- oder Dienstleistungsdarstellung unter sslxy.de.
• Keine komplexen Webanwendungen mit Benutzerkonten und Zahlungsabwicklung innerhalb des Archivs.
• Kein CMS- oder Plugin-Unterbau, solange statische Dateien die Aufgabe zuverlässig erfüllen.
• Keine dauernde Umgestaltung allein nach Modetrends.
• Keine invasive Analyse von Besucherprofilen.
• Keine Behauptung vollständiger Rechtssicherheit durch bloßen Quelltext.
• Keine automatische Veröffentlichung ungeprüfter KI-Ergebnisse.

Diese Begrenzung ist kein technischer Rückschritt. Sie reduziert unnötige Fehlerquellen und hält die Komplexität im Verhältnis zur tatsächlichen Aufgabe.

„Nicht alles einbauen, was technisch möglich ist – sondern das, was eine konkrete Aufgabe zuverlässig erfüllt.“

[future/maintenance]

Was auch künftig wichtig bleibt

Browser, Suchsysteme, Sicherheitsanforderungen und rechtliche Rahmenbedingungen verändern sich weiter. Eine tragfähige Reaktion besteht nicht darin, jeder Entwicklung sofort zu folgen, sondern in einer stabilen Grundlage, auf der notwendige Änderungen gezielt umgesetzt werden können.

Langfristige Pflege bedeutet deshalb: Inhalte aktuell halten, neue Abhängigkeiten kritisch prüfen, alte Pfade kontrolliert abbauen, technische Standards beobachten und die Website regelmäßig aus Sicht realer Besucher testen. Bestehende Regeln müssen angepasst werden können, wenn sich Technik, Inhalte oder tatsächliche Anforderungen verändern.

Wartbarkeit entsteht nicht durch eine vermeintlich letzte Endversion. Sie entsteht durch nachvollziehbare Strukturen, dokumentierte Entscheidungen und rechtzeitige, begrenzte Korrekturen.

„Eine gute Website ist nicht für den nächsten Screenshot gebaut, sondern für den nächsten notwendigen Handgriff.“

Zusammenhang: Technische Philosophie bündelt die langfristigen Grundsätze; Server-Härtung die fortlaufende Sicherheitsseite.

[links/archive]

Querverweise im SSLXY-Archiv

Die Webmaster-Perspektive verbindet frühe Webpraxis, Hostbetrieb, CGI, Sicherheit, Werkzeuge und langfristige Wartung. Die bekannten Zielseiten sind bereits mit ihren endgültigen Dateinamen verknüpft.

• Startseite von sslxy.de
• Erste Webseiten 1995–1996
• Webentwicklung 1996
• Shell-Accounts und Hosts
• CGI und Logdateien
• Server-Härtung
• SSL und Zertifikate
• Unix und Linux im Alltag
• Fernwartung und Remote-Zugriffe
• Netzwerk und Heimvernetzung
• Software- und Tool-Alltag
• Datensicherung und Backups
• Technische Philosophie
• Datenschutz auf sslxy.de