// audit · tech
Wir schauen unter die Haube deiner bestehenden Website: Stack, Architektur, Code-Qualität und der Weg, auf dem Änderungen live gehen. Ein Code-Audit, das nichts umbaut, sondern feststellt, was trägt, was bremst und was ein Risiko ist. Heraus kommt der tech-report — priorisierte Befunde mit Aufwand und Wirkung. Er gehört dir, egal wer danach umsetzt.
// definition
Ein Code-Audit ist die strukturierte Prüfung des Quellcodes und der Technik hinter einer Anwendung — bei einer Website also Stack, Architektur, Code-Qualität, Abhängigkeiten und der Weg, auf dem Änderungen live gehen. Es wird nichts umgebaut. Wir lesen, messen, ordnen ein — und schreiben auf, was wir gefunden haben.
Das Tech-Audit bei siteway ist genau das für Websites und CMS: TYPO3, WordPress, Statamic, PHP und Laravel sind unser Alltag seit 2006. Der Unterschied zu einem Tool-Report ist die Reihenfolge. Ein Scanner listet 340 Findings alphabetisch. Wir sagen dir, welche drei du diese Woche anfasst — und welche 300 du ignorieren kannst.
// anlass
erst wissen, dann entscheiden
Der häufigste Anlass: Jemand soll eine Website übernehmen, die er nicht gebaut hat. Ein Agenturwechsel steht an, ein internes Team erbt das System, oder ein Käufer will vor der Unterschrift wissen, was er technisch kauft — die technische Due Diligence. In allen drei Fällen ist die Frage dieselbe: Kann man auf dieser Basis weiterbauen, oder zahlt man jahrelang Zinsen auf fremde Abkürzungen?
Der zweite Anlass sind Symptome. Jede Änderung dauert plötzlich Tage. Updates werden verschoben, weil niemand weiß, was dann kaputtgeht. Ein Deploy ist ein FTP-Upload am Freitagabend. Nur eine Person kann das System anfassen. Das sind keine Meinungen, das sind Befunde — und sie lassen sich prüfen, bevor sie zu einem Relaunch eskalieren.
// prüfung · 6 bereiche
jeder bereich ein befund
Sechs Bereiche, in dieser Reihenfolge. Wir lesen Code, Konfiguration und Repository-Historie und sprechen mit den Leuten, die das System bedienen. Jeder Bereich endet mit einem Befund, nicht mit einem Gefühl.
// p-01stack
Welches CMS, welches Framework, welche PHP- und Datenbankversion — und wie lange die noch Sicherheitsupdates bekommen. Ein System auf einer abgelaufenen PHP-Version ist kein Detail, sondern ein Zeitplan.
befund: support-status + update-pfad
// p-02architektur
Wie sind Templates, Module und Datenmodell aufgebaut? Wiederverwendbar oder für jede Seite eine Sonderlocke? Hier entscheidet sich, ob die nächste Anforderung eine Stunde oder eine Woche kostet.
befund: struktur-karte + bruchstellen
// p-03code
Lesbarkeit, Duplikate, Änderungen am CMS-Kern, tote Pfade, Testabdeckung. Kern-Hacks sind der klassische Grund, warum ein Update nicht mehr durchläuft — wir finden sie und benennen sie.
befund: technische schulden, beziffert
// p-04dependencies
Plugins, Extensions, Composer- und npm-Pakete: Wer pflegt sie, wann kam das letzte Update, was ist verwaist? Drei Plugins für dieselbe Aufgabe sind keine Auswahl, sondern Ballast.
befund: inventar + pflegestand
// p-05deployment
Wie kommt eine Änderung live? Git mit Branches, CI/CD und Staging — oder FTP ins Live-System? Ohne Versionierung und Rollback ist jede Änderung ein Einzelrisiko. Wir prüfen den Weg, nicht nur das Ziel.
befund: prozess-ist + rollback-fähigkeit
// p-06übergabe
Gibt es Dokumentation, sind alle Zugänge da, hängt das System an einer einzelnen Person? Beim Agenturwechsel ist das der entscheidende Punkt: Wie schnell kann ein neues Team wirklich übernehmen.
befund: zugangs- + wissenslücken
// output
der report gehört dir
Kein PDF-Berg mit 340 Findings in alphabetischer Reihenfolge. Der tech-report ist ein Dokument, das man in einer halben Stunde liest und danach entscheiden kann. Jeder Befund hat einen Schweregrad, einen geschätzten Aufwand und eine Wirkung — daraus ergibt sich die Reihenfolge von selbst. Dazu eine Stunde Durchsprache, in der du Rückfragen stellst.
// r-01befunde
Jeder Befund mit Schweregrad von kritisch bis niedrig, Fundstelle im Code und einem Satz, was passiert, wenn nichts passiert.
// r-02aufwand
Zu jedem Punkt eine Aufwandsschätzung und der erwartete Effekt. So siehst du, was viel bringt und wenig kostet — und was warten kann.
// r-03reihenfolge
Eine konkrete Reihenfolge: was in dieser Woche, was in diesem Quartal, was gar nicht. Umsetzbar auch ohne uns.
// r-04entscheidung
Die ehrliche Antwort auf die teuerste Frage: Trägt die Basis noch — oder ist ein Relaunch günstiger als jahrelange Reparatur?
// r-05risiken
Was dich kalt erwischen kann: auslaufender Support, verwaiste Extensions, fehlendes Backup, Wissen in einem einzigen Kopf.
// r-06eigentum
Als Markdown und PDF, ohne Sperrfrist und ohne Umsetzungspflicht. Gib ihn deiner Agentur, deinem Team oder einem Dritten.
// ablauf · 4 schritte
3–5 tage bis zum report
// schritt 01 · briefing
Was ist das System, was ist der Anlass, was ist die Frage dahinter. Du gibst uns Lesezugriff auf Repository, CMS und Server. Kein Git? Dann Quellcode-Export und Datenbank-Dump — das reicht.
output: scope + festpreis
// schritt 02 · analyse
Wir lesen Code, Konfiguration und Repository-Historie, prüfen Abhängigkeiten und gehen den Deployment-Weg einmal komplett durch. Statische Analyse liefert die Zahlen, unsere Erfahrung die Einordnung.
output: rohbefunde
// schritt 03 · bewertung
Jeder Befund bekommt Schweregrad, Aufwand und Wirkung. Was nur kosmetisch ist, fliegt raus. Übrig bleibt eine Liste, die man abarbeiten kann — von oben nach unten.
output: priorisierte liste
// schritt 04 · übergabe ● ergebnis
Du bekommst den tech-report und eine Stunde Durchsprache. Danach entscheidest du: selbst umsetzen, umsetzen lassen — oder erst mal nichts tun, aber mit offenen Augen.
output: tech-report.md + pdf
// faq
Ein Code-Audit ist die strukturierte Prüfung des Quellcodes und der Technik hinter einer Anwendung — bei einer Website also Stack, Architektur, Code-Qualität, Abhängigkeiten und der Weg, auf dem Änderungen live gehen. Es wird nichts umgebaut. Am Ende steht ein Befund: Was trägt, was bremst, was ist ein Risiko — und in welcher Reihenfolge man es angeht.
Sechs Bereiche: Stack und Versionen (CMS, Framework, PHP, Datenbank), Architektur und Templates, Code-Qualität im Kern und in eigenen Modulen, Abhängigkeiten wie Plugins und Extensions, den Deployment-Prozess mit Git, CI/CD und Staging sowie die Übergabefähigkeit — Dokumentation, Zugänge und die Frage, wie schnell ein neues Team übernehmen kann.
Festpreis nach Briefing. Sobald klar ist, wie groß das System ist, welches CMS läuft und welche Zugänge es gibt, nennen wir einen Preis für das Tech-Audit und halten ihn fest. Keine Tagessätze, die während der Analyse wachsen.
Für eine übliche Business-Website drei bis fünf Arbeitstage vom Zugang bis zum Report. Große TYPO3-Installationen mit vielen Extensions, Schnittstellen und Sprachen brauchen länger — das steht vor Beginn im Angebot, nicht danach in der Rechnung.
Im Idealfall Lesezugriff auf das Repository, das CMS-Backend und den Server. Wenn es kein Git gibt — was häufiger vorkommt, als man denkt —, reicht ein Quellcode-Export plus Datenbank-Dump. Genau dieses Fehlen ist übrigens schon ein Befund und landet im Report.
Nein. Der tech-report gehört dir, inklusive aller Befunde und Empfehlungen. Du kannst ihn deiner bisherigen Agentur geben, deinem internen Team oder einem Dritten. Wenn du willst, übernehmen wir die Umsetzung — als Entwicklung & Umsetzung oder, wenn sich der Weiterbetrieb nicht mehr lohnt, als Relaunch & Migration. Eine Pflicht dazu gibt es nicht.
Nein. Wir greifen deine Seite nicht an und suchen keine Exploits. Das Tech-Audit schaut auf Stack, Architektur, Code und Deployment. Wenn du TLS-Konfiguration, Security-Header wie CSP und HSTS oder bekannte CVEs in Abhängigkeiten geprüft haben willst, ist das Security-Audit der richtige Baustein. Ein echter Penetrationstest ist eine eigene Disziplin — den machen wir nicht.
// passt dazu
audits & leistungen
// leistung · umsetzung
Das Audit findet die Befunde — diese Leistung räumt sie ab: sauberer Code, Git, CI/CD, Staging und ein Deployment ohne Freitagsangst.
weiterlesen →
// audit · security
Die Schwester zum Tech-Audit: TLS, Security-Header wie CSP und HSTS, veraltete Abhängigkeiten und bekannte CVEs.
weiterlesen →
// leistung · ablösung
Wenn der Report sagt, dass sich Reparieren nicht mehr lohnt: Ablösung mit Inhalten, URLs und Rankings — ohne Bruch.
weiterlesen →
// Wissen, was unter deiner Website läuft?
Audit anfragen