Die neue Kontaktseite zeigt nach dem Absenden eine freundliche Bestätigung. Im Serverprotokoll fehlt der Vorgang, die Empfängeradresse stammt aus einer alten Umgebung und niemand kann sagen, welche Codefassung gerade läuft. Der Bildschirm sieht richtig aus. Die technische Lieferkette ist trotzdem nicht abnahmefähig.
Webentwicklung für Kanzleien verbindet Code, Inhalte, Konfiguration, Zugriffe, Tests und Betrieb. Jede Änderung muss sich von einer freigegebenen Anforderung bis zu einem identifizierbaren Release und zurück verfolgen lassen. Sonst hängt die Website nicht an dokumentierten Systemen, sondern am Gedächtnis einzelner Agenturpersonen.
DE-176 verwendet eine synthetische Release-Wiederanlaufakte. Sie enthält ein leeres Repositorymodell, vier abstrakte Umgebungen, ein erfundenes CMS-Schema, ein Formular ohne Personendaten, zwei Releasekennungen, einen gesperrten Paketcode und eine harmlose Restoreprobe. Es wird kein echtes System berührt.
Die Entwicklung erfindet keine Gestaltung neu. Seitenmuster, visuelle Komponenten, responsive Zielansichten und sichtbare Zustände kommen aus DE-175. DE-176 implementiert und prüft sie. Eine technische Abweichung wird an das Design zurückgegeben, statt Hierarchie, Text oder Zustand still im Code zu verändern.
Fünf Anbieter veröffentlichen einen ausdrücklichen Kanzlei- oder Anwaltsbezug und mindestens einen sichtbaren Website-, Entwicklungs-, CMS-, Hosting- oder Wartungsgegenstand. Die Reihenfolge bewertet nur die dokumentierte Passung zur synthetischen Akte. Sie bestätigt keine tatsächliche Codequalität, Sicherheit, Rechtskonformität, Zugänglichkeit oder Wirkung.
theStacc veröffentlicht DE-176 und bewirbt über die Handlungsaufrufe auf dieser Seite einen eigenen SEO-Dienst. theStacc wird nicht als Webentwicklungsanbieter gerankt. Kein Anbieter bezahlte für Aufnahme oder Platzierung. Für den Stichtag 31. August 2026 wurden zwölf direkt erreichbare Originalquellen festgehalten. Anbieterbelege stammen von OMmatic, Anwalt Advertising, kanzlei.media, Kallinich Media und anwalts.marketing. GitHub dokumentiert Repository-Grundlagen. MDN beschreibt Browser- und Servervalidierung. W3C veröffentlicht WCAG 2.2. OWASP stellt den Application Security Verification Standard bereit. web.dev veröffentlicht eine Lernreferenz zur Web-Performance. Den amtlichen Wortlaut des § 43b BRAO liefert Gesetze im Internet; die Bundesrechtsanwaltskammer stellt die hier verwendete BORA-Fassung vom 1. Dezember 2025 bereit. Anbieterquellen belegen ausschließlich den jeweils sichtbaren Eigenumfang. Wir haben keine Agentur, Person, Qualifikation, Kanzlei, Website, Domain, Repository, Codebasis, Branchregel, CMS, Migration, Formular, Schnittstelle, Hostingumgebung, Konfiguration, Sicherheitskontrolle, Abhängigkeit, Test, Deployment, Monitoring, Backup, Wiederherstellung oder Wirkung praktisch geprüft. Preise, Pakete, Laufzeiten, Referenzen, Kundenanzahl, Ladezeiten, Messwerte, Zertifizierungen, Rankings, Anfragen, Mandate, Fallausgänge, Umsatz und Ergebnisversprechen wurden ausgeschlossen. Die Release-Wiederanlaufakte ist vollständig synthetisch. Sie enthält keine reale Kanzlei, Person, Kontaktdaten, Rechtsfrage, Akte, Frist, Mandatsbeziehung oder vertrauliche Information. Kein Formular sendet Daten und kein System wird veröffentlicht. Dieser Beitrag ist keine Rechtsberatung und bestätigt weder Berufsrecht noch Datenschutz, Sicherheit oder Barrierefreiheitskonformität. Eine echte Kanzlei muss Anforderungen, Datenverarbeitung, Werbeaussagen, Berufsrecht, Sicherheit, Zugänglichkeit, Verträge und Betrieb zuständig prüfen lassen. Im Serienzuschnitt besitzt DE-176 Repository, Architektur, CMS, Code, Formularverarbeitung, Validierung, Datenfluss, Schnittstellen, Sicherheit, Performance, technische Zugänglichkeitstests, Abhängigkeiten, Hosting, Release, Monitoring, Recovery und technischen Exit. DE-175 besitzt visuelle Hierarchie, Seitenmuster, Design-Tokens, visuelle Zustände, responsive Zielansichten, Prototyp und Designdateien. DE-174 führt Kampagnen, Konten, Budgets und Messung. DE-171 bis DE-173 führen organisches SEO, Local SEO und organisches Social. DE-176 trägt needs_human_review, weil benannte anwaltliche, datenschutzbezogene, sicherheitsbezogene, barrierefreiheitsbezogene und deutsche Schlussprüfung sowie dauerhafte technische Pflegeverantwortung fehlen.
Die kurze Antwort
OMmatic führt diesen Dokumentationsvergleich an, weil die offizielle Anwaltsseite Next.js, WordPress, Elementor Pro, Sanity CMS, Kontaktformular, Hosting und Wartung nennt. Anwalt Advertising folgt mit WordPress-Bezug, technischer Aktualisierung, Ladezeitarbeit sowie Pflege und Wartung. kanzlei.media, Kallinich Media und anwalts.marketing zeigen schmalere oder stärker koordinierende Entwicklungsmodelle.
- OMmatic: Kanzleien, die CMS, Technologieauswahl, Formular, Hosting und Wartung in einem technischen Übergabepiloten sichtbar zerlegen möchten
- Anwalt Advertising: Kanzleien, die eine anwaltsspezifische WordPress-nahe Website samt technischer Aktualisierung und laufender Wartung anfragen
- kanzlei.media: Kanzleien, die eine individuelle mobilfähige Website und anschließende Pflege in einer betreuten Lieferkette prüfen
- Kallinich Media: Kanzleien, die Websiteerstellung und Pflege zusammen mit Positionierung und Corporate Design beschaffen, aber Technik separat abnehmen
- anwalts.marketing: Kanzleien, die Analyse und Projektmanagement zentral halten und eine externe technische Umsetzung transparent steuern möchten
Die Release-Wiederanlaufakte bindet Code, Betrieb und Rücknahme
Die Akte beginnt mit einer Systemkarte. Frontend, CMS, Formulare, externe Dienste, Analytics, Hosting, Domain, DNS, E-Mail-Zustellung und Dateispeicher erscheinen als getrennte Bausteine. Jeder Baustein erhält institutionellen Besitzer, Umgebung, Datenklasse, Konfigurationsklasse, Abhängigkeit, Testbeleg, Betriebsrolle und Exitweg. Die Pilotkarte enthält keine echten Konten.
Der technische Eingangsschein übernimmt das freigegebene Designpaket aus DE-175. Seitenmuster, Komponente, visuelle Variante, responsive Ansicht, Textquelle, Assetquelle, Interaktionsregel, Zugänglichkeitsanmerkung, Freigabe und offene Frage bleiben referenziert. Ist eine Vorgabe technisch nicht tragfähig, entsteht eine dokumentierte Abweichung mit Alternative und Entscheider.
Das Repository ist ein Lieferobjekt. GitHub beschreibt ein Repository als Ort für Code, Dateien und Revisionsverlauf eines Projekts. DE-176 schreibt keine bestimmte Plattform vor, fordert aber institutionelle Kontrolle, individuelle Rollen, Branch- und Reviewregeln, vollständigen Verlauf, Releasebezug, Export und einen getesteten Zugriffsentzug.
Persönliche Agenturkonten dürfen nicht die einzige Verbindung zum Quellcode bilden. Die Kanzlei braucht eine benannte Eigentümerrolle und mindestens einen unabhängigen Wiederzugang. Der Pilot entzieht alle Agenturrollen und prüft, ob Verlauf, Issues, Releases, Buildanleitung und Exporte weiter erreichbar bleiben. Echte Zugangsdaten werden nicht verwendet.
Vier Umgebungen werden logisch getrennt: lokale Entwicklung, Integration, Abnahme und Produktion. Sie erhalten eigene Konfigurationsklassen, Datenregeln, Zugriffsrollen, Veröffentlichungswege und Sperren. Der Pilot nutzt leere oder erfundene Inhalte. Produktionsdaten dürfen nicht als bequeme Testfüllung in eine andere Umgebung kopiert werden.
Konfiguration und Geheimnisse stehen weder in frei sichtbaren CMS-Feldern noch in Screenshots oder öffentlichem Quellcode. Die Akte nennt nur Schlüsselklasse, institutionellen Besitzer, Zielumgebung, Rotationsweg und letzten Prüfstatus. Ein echter Wert gehört nicht in das Dossier. Der Pilot zeigt Entzug und Austausch mit harmlosen Stellvertretern.
Das CMS-Modell übersetzt freigegebene Kanzleiinhalte in definierte Felder. Seitentyp, Rechtsgebietscode, Zusammenfassung, Personenrolle, Standortreferenz, Kontaktoption, Claimquelle, fachlicher Prüfstatus, Werbeprüfung, Fassung und Ablauf erhalten Typ, Pflichtstatus, Validierung, Vorschau und Ausgaberegel. Es werden keine echten Rechtsaussagen gespeichert.
Eine Migration ist eine eigenständige technische Lieferung. Ausgangsschema, Zielversion, Feldzuordnung, ungültige Einträge, Transformationsschritt, Testbestand, Freigabe und Rückfallweg bleiben verbunden. Der Pilot benennt ein synthetisches Feld um und verlangt, dass Templates, Abfragen, Vorschauen, Exporte, Suchindex und Tests denselben Versionswechsel nachvollziehen.
Formulare besitzen einen Browserpfad und einen Serverpfad. MDN erklärt, dass clientseitige Validierung eine nützliche erste Prüfung bietet, aber keine vollständige Sicherheitsmaßnahme ist. Ein Nutzer kann sie umgehen, deshalb müssen eingehende Daten serverseitig geprüft werden. DE-176 verwendet nur synthetische Eingaben und behauptet keine rechtliche Zulässigkeit.
Der Formularvertrag führt Feldkennung, sichtbares Label, Format, Pflichtstatus, Browserfeedback, Serverentscheidung, Fehlerabbildung, Sendestatus, Bestätigung, Zielsystem, Wiederholungsregel, Protokollklasse, Aufbewahrungsfrage und Löschweg. Eine Bestätigungsseite darf keinen Mandatsbeginn, keine Fristwahrung oder fachliche Prüfung behaupten.
Schnittstellen bekommen einen eigenen Vertrag. Anfrage, Antwort, Authentifizierungsklasse, Timeout, Wiederholung, Deduplizierung, Fehler, Protokollierung, Besitzer und Abschaltweg werden beschrieben. Der Pilot sendet keine Anfrage. Er simuliert einen Ausfall und prüft, ob die Website einen sicheren Zustand zeigt, ohne Zustellung oder Termin zu erfinden.
Technische Zugänglichkeit wird am laufenden Build geprüft. WCAG 2.2 ist die offizielle W3C-Referenz für die hier verwendeten Erfolgskriterien. DE-176 verbindet eine Anforderung mit Seite, Komponente, Umgebung, Testart, Befund, Prüfer und offener Abweichung. Eine Designanmerkung aus DE-175 und ein automatischer Scan allein ergeben keine Konformitätsfeststellung.
Semantik, Tastaturbedienung, Fokusreihenfolge, sichtbarer Fokus, Name und Rolle, Fehlerrückmeldung, Statusmeldung, Textvergrößerung, Umfluss und Medienalternative werden gegen konkrete Builds untersucht. Werkzeuge können Befunde liefern. Eine zuständige menschliche Prüfung bleibt nötig, bevor eine rechtliche oder technische Konformitätsaussage erwogen wird.
Performance erhält ein messbares Budget erst nach Projektklärung. Die web.dev-Lernreferenz behandelt unter anderem HTML, kritischen Renderingpfad, Ressourcenladen, Bilder, Video, Webfonts, JavaScript-Aufteilung und verzögertes Laden. DE-176 übernimmt daraus Themen, erfindet aber keine Grenzwerte und schreibt keinem Anbieter ein Ergebnis zu.
Jeder Performancebeleg nennt Codefassung, Route, Umgebung, Gerätekategorie, Netzwerkprofil, Werkzeug, Zeitpunkt und Abweichung. Laborwerte, Felddaten und geschäftliche Wirkung bleiben getrennt. Eine einzelne schnelle Messung auf der Agenturwebsite ist kein Nachweis für ein zukünftiges Kanzleiprojekt oder dessen Betrieb.
OWASP beschreibt ASVS als Grundlage zur Prüfung technischer Sicherheitskontrollen von Webanwendungen und als Anforderungsliste für sichere Entwicklung. DE-176 behauptet bei keinem Anbieter ASVS-Nutzung oder Erfüllung. Eine zuständige Sicherheitsprüfung muss Version, Umfang, Bedrohungsmodell, Testart, Befund, Ausnahme und Korrekturweg festlegen.
Die Sicherheitsakte trennt Anforderung, Implementierung und Prüfung. Authentifizierung, Autorisierung, Eingabeprüfung, Fehlerbehandlung, Protokollierung, Konfiguration, Dateiannahme, Abhängigkeiten und Geheimnisse können relevante Prüfbereiche sein. Welche davon im konkreten System gelten, wird vor dem Auftrag entschieden und nicht aus einer allgemeinen Checkliste vermutet.
Abhängigkeiten erhalten Name, Quelle, Version, Lizenzstatus, Einsatzort, Besitzer, Aktualisierungsweg, bekannte Sperre, Testbezug und Entfernungspfad. Der Pilot verwendet nur einen erfundenen Paketcode. Wird dieser gesperrt, muss der Build stoppen, betroffene Releases müssen auffindbar sein und eine dokumentierte Alternative geöffnet werden.
Tests werden nach Lieferobjekt und Risiko organisiert. Schema-, Komponenten-, Formular-, Schnittstellen-, Zugänglichkeits-, Performance-, Sicherheits-, Smoke-, Release- und Recoveryfälle erhalten Eingabe, Umgebung, erwarteten Zustand, tatsächlichen Befund und Beleg. Ein grüner Gesamtstatus ohne adressierbare Fälle reicht nicht für die Abnahme.
§ 43b BRAO und § 6 BORA dienen als offizielle Ausgangspunkte für Fragen zu anwaltlicher Werbung. Die Entwicklungsagentur entscheidet keine fachliche oder berufsrechtliche Zulässigkeit. Sie muss jedoch sicherstellen, dass freigegebene Fassung, Claimquelle und Prüfstatus technisch zum veröffentlichten Release gehören und nicht durch Migration oder Fallbacktext ersetzt werden.
Ein Release-Manifest bindet Codefassung, CMS-Migration, Konfigurationsklasse, Abhängigkeiten, Assets, Tests, Freigeber, Zielumgebung, Deploymentzeit, Beobachtungsfenster und Rücknahmebedingung. Die synthetische Probe veröffentlicht nichts. Sie prüft, ob aus denselben Belegen eine eindeutige Freigabe und eine eindeutige Rücknahme entstehen.
Hosting ist mehr als eine Anbieterzeile auf der Rechnung. Domain, DNS, Zertifikatsklasse, Laufzeitumgebung, Speicherdienst, Datenbank, Dateispeicher, E-Mail-Zustellung, Cache, Protokolle, Administrationsrollen und Abrechnung erhalten institutionellen Besitzer und Entzugsweg. Rechtliche Speicher- und Standortfragen bleiben zuständiger Prüfung vorbehalten.
Monitoring trennt technische Signale von Marketingmessung. Erreichbarkeit, Antwortstatus, Fehlerklasse, Jobzustand, Ressourcenproblem und Formularpfad können Betriebsindikatoren sein. Sie belegen keine Anfrage, kein Mandat und keinen Umsatz. Alarm, Bereitschaft, Eskalation, Zugriff, Aufbewahrung und Rückkehr zur Normalität werden vor dem Release vereinbart.
Ein Incident beginnt mit Signal und Auswirkung, nicht mit einer Erfolgserzählung. Die Akte hält Erkennung, betroffene Fassung, Sofortmaßnahme, Sicherung, Rollen, Kommunikation, Entscheidung, Korrektur, Retest und Wiederaufnahme fest. Ein Formularfehler wird nicht durch einen manuellen Erfolgstext verdeckt, sondern als technischer Zustand behandelt.
Backup und Restore sind verschiedene Nachweise. Die Akte führt Umfang, Häufigkeitsklasse, Verschlüsselungsfrage, Aufbewahrung, Besitzer, Wiederherstellungsumgebung, Prüffall, Ergebnis und offene Korrektur. Die synthetische Restoreprobe nutzt leere Inhalte und prüft, ob Code, CMS-Schema, Konfiguration und Dateien als zusammengehörige Fassung zurückkehren.
Der technische Exit umfasst Repositoryverlauf, Buildanleitung, Umgebungsregister, Konfigurationsklassen, CMS-Schema, Migrationsschritte, Schnittstellenverträge, Testfälle, Releasehistorie, Monitoring, Backups, Restorebelege, Dokumentation, Lizenzen, Rollen und offene Incidents. Ein ZIP mit unbekannter Herkunft ist keine übernehmbare Systemübergabe.
Zum Abschluss übernimmt ein neues Team die synthetische Akte. Es richtet eine leere Umgebung ein, migriert das erfundene CMS-Feld, reproduziert einen Formularfehler, erzeugt einen Releasekandidaten, führt die Rücknahme aus und stellt den letzten sicheren Stand wieder her. Erst dieser Wiederanlauf zeigt, ob die Dokumentation ohne Agenturgedächtnis trägt.
Branchenspezifische Nachweise, nach denen Sie fragen sollten
- Sichern Sie institutionellen Repositorybesitz, individuelle Rollen, Reviewregeln, Verlaufsexport und Zugriffsentzug.
- Trennen Sie lokale, Integrations-, Abnahme- und Produktionsumgebung samt Daten- und Konfigurationsregeln.
- Versionieren Sie CMS-Felder, Migrationen, Templates, Vorschauen, Exporte, Suchausgabe und Rückfallweg gemeinsam.
- Prüfen Sie Formulare im Browser und auf dem Server mit eindeutigen Fehler-, Sende- und Bestätigungszuständen.
- Binden Sie Schnittstellen, Timeouts, Wiederholungen, Deduplizierung, Protokollierung und Abschaltung an Besitzer.
- Verknüpfen Sie Zugänglichkeits-, Performance- und Sicherheitsprüfungen mit konkreten Builds und Befunden.
- Inventarisieren Sie Abhängigkeiten, Lizenzen, Versionen, Sperren, Aktualisierungs- und Entfernungspfade.
- Proben Sie Release, Monitoring, Incident, Rücknahme, Backup, Restore und vollständige Übernahme ohne Agenturwissen.
So haben wir die Anbieter bewertet
Die Recherche verwendet fünf offizielle Anbieterseiten und sieben offizielle technische, berufsrechtliche oder standardsetzende Quellen. Anbieterbelege gelten nur für die jeweils sichtbare Eigenbeschreibung. GitHub, MDN, W3C, OWASP, web.dev, Gesetze im Internet und BRAK bewerten keinen Anbieter und begründen keinen Rang.
OMmatic nennt auf der eigenen Webdesign-Seite für Anwälte Next.js, WordPress mit Elementor Pro, Sanity CMS zur eigenen Pflege, Kontaktformular, Hosting und Wartung. Preise, Zeitangaben, Messwerte sowie Aussagen zu Geschwindigkeit, Ergebnissen, Recht und Konformität wurden ausgeschlossen.
Anwalt Advertising veröffentlicht eine eigene Webdesign-Seite für Anwälte mit WordPress-Bezug. Außerdem nennt sie Arbeit an Ladezeit und technischer Aktualität sowie Pflege, Wartung und Aktualisierung. Absolute Qualitäts- und Performancebehauptungen beeinflussen die Reihenfolge nicht.
kanzlei.media beschreibt eine individuelle mobilfähige Kanzleiwebsite und fortlaufende Inhaltspflege sowie Wartung. Die Quelle zeigt weniger technische Tiefe zu Repository, CMS-Migration, Formularserver, Tests und Recovery. Diese Gegenstände bleiben Pilotfragen.
Kallinich Media nennt Websites sowie Erstellung und Pflege einer Website im Kanzleimarketing-Umfang. anwalts.marketing beschreibt eine neue oder überarbeitete Kanzleiwebsite und Projektmanagement, weist aber ausdrücklich darauf hin, dass die technische Umsetzung von Website- oder Corporate-Design-Projekten an vertraute Partner gegeben wird.
Gewichtet wurden Kanzleibezug, technischer Lieferumfang, Repository- und Umgebungsmodell, CMS und Migration, Formulare und Schnittstellen, technische Zugänglichkeit, Performance, Sicherheitsanforderungen, Abhängigkeiten, Tests, Release, Hosting, Monitoring, Recovery, Dokumentation und Exit. Nicht sichtbare Punkte werden geprüft, nicht als tatsächlicher Mangel behauptet.
| Kriterium | Gewichtung | Was gezählt hat |
|---|---|---|
| Kanzleibezug und Systemgrenze | Sehr hohe Priorität | Website, CMS, Formulare, Dienste, Domain, Hosting und Betrieb werden als getrennte Bausteine mit Besitz, Datenklasse und Exit erfasst. |
| Repository und Umgebungen | Sehr hohe Priorität | Code, Verlauf, Rollen, Review, Branches, lokale Entwicklung, Integration, Abnahme und Produktion bleiben institutionell kontrollierbar. |
| CMS-Schema und Migration | Sehr hohe Priorität | Feldtypen, Quellen, Prüfstatus, Versionen, Zuordnung, Vorschau, Export, Tests und Rückfallweg sind dokumentiert. |
| Formular- und Serverlogik | Sehr hohe Priorität | Browserfeedback, Serverprüfung, Fehler, Versand, Bestätigung, Zielsystem, Protokollklasse und Löschfrage werden getrennt abgenommen. |
| Schnittstellen und Ausfallzustände | Hohe Priorität | Authentifizierungsklasse, Timeout, Wiederholung, Deduplizierung, Fehler, Protokollierung, Besitzer und Abschaltung sind sichtbar. |
| Technische Zugänglichkeit | Sehr hohe Priorität | Anforderungen, Komponenten, Seiten, Testarten, menschliche Prüfung, Befunde, Ausnahmen und Retests sind an Builds gebunden. |
| Performance und Ressourcen | Hohe Priorität | Budgets, Bedingungen, Routen, Builds, Geräteprofile, Werkzeuge, Ergebnisse und Abweichungen bleiben reproduzierbar. |
| Sicherheit und Abhängigkeiten | Sehr hohe Priorität | Anforderungen, Bedrohungsmodell, Kontrollen, Testbelege, Paketquellen, Versionen, Lizenzen, Sperren und Entfernung sind adressierbar. |
| Release, Hosting und Monitoring | Sehr hohe Priorität | Manifest, Freigabe, Deployment, Infrastruktur, Beobachtung, Alarm, Incident, Rücknahme und Rollen bilden eine kontrollierte Kette. |
| Restore und technischer Exit | Sehr hohe Priorität | Backups, Wiederherstellungsproben, Buildanleitung, Dokumentation, Zugriffe, Lizenzen und offene Arbeit bleiben übernehmbar. |
Jeder Anbieter musste dieselben Mindestanforderungen erfüllen, bevor seine Position überhaupt betrachtet wurde.
- Eine direkt erreichbare offizielle Seite beschreibt Websitearbeit, Webentwicklung, CMS, Hosting, Pflege oder technische Umsetzung ausdrücklich für Kanzleien oder Anwälte.
- Der sichtbare Umfang enthält mindestens einen technischen Gegenstand aus Plattform, Codebasis, CMS, Formular, Hosting, Wartung, technischer Aktualisierung oder Partnerumsetzung.
- Die Quelle beschreibt eine eigene Agentur-, Managed-Service- oder transparent koordinierte Partnerleistung und nicht nur ein Verzeichnis oder eine Ratgeberliste.
- Die verwendete Anbieter-URL war am Beobachtungstag direkt erreichbar.
- Preise, Testimonials, Referenzen, Kundenlisten, Messwerte, Rankings, Anfragen, Mandate, Umsatz und Erfolgsversprechen beeinflussen den Rang nicht.
- Ein Partnernetzwerk bleibt zulässig, wenn Verantwortungen, Dateien, Rechte, Zugriffe, Tests, Betriebsrollen und Exit über alle Parteien vollständig adressierbar werden.
Die recherchierte Anbieterliste
Die Platzierungen folgen der veröffentlichten Methodik und dem Stichtag der Quellen; sie sind keine Ergebnisgarantie. Jede Karte nennt die stärkste Eignung und die Einschränkung, die eine Kaufentscheidung am ehesten verändert.
OMmatic
Belegte Stärken
- Eigene Webdesign- und Entwicklungsseite für Anwälte
- Next.js sowie WordPress mit Elementor Pro werden konkret genannt
- Sanity CMS zur eigenen Inhaltspflege erscheint im Umfang
- Kontaktformular, Hosting und Wartung sind sichtbar dokumentiert
Zu prüfende Grenzen
- Repository-, Branch- und Umgebungsmodell wird auf der gelesenen Seite nicht vollständig erklärt
- Formularserver, Sicherheitsprüfung und technische Zugänglichkeit bleiben gesonderte Nachweise
- Release, Rollback, Monitoring, Restore und Exit müssen im Pilot belegt werden
Der breiteste veröffentlichte technische Umfang im Quellenpaket. Next.js, WordPress mit Elementor Pro, Sanity CMS, Kontaktformular, Hosting und Wartung sind sichtbar. Repositorybesitz, Tests, Sicherheitsprüfung, Releasekette und Restore müssen dennoch praktisch belegt werden.
OMmatic veröffentlicht eine eigene Webdesign-Seite für Anwälte und nennt dort konkrete technische Wege. Next.js oder WordPress mit Elementor Pro erscheinen als Entwicklungsoptionen. Außerdem wird Sanity CMS als selbst pflegbarer Inhaltsweg beschrieben. Für DE-176 entsteht daraus eine prüfbare Technologie- und CMS-Frage.
Die Quelle nennt ein Kontaktformular sowie Hosting und Wartung. Der Pilot verlangt dazu mehr als eine Leistungszeile. Browser- und Servervalidierung, Fehlerabbildung, Sendezustand, Zielsystem, Protokollierung, Datenprüfung, Hostingrollen, Konfiguration, Monitoring und Wiederherstellung werden einzeln dokumentiert.
Technologien werden nicht allein nach Namen abgenommen. Next.js, WordPress, Elementor Pro und Sanity besitzen unterschiedliche Code-, Plugin-, Inhalts-, Hosting- und Updatepfade. Die Agentur muss je gewähltem Weg Repository, Versionen, Abhängigkeiten, Rollen, Migration, Tests, Release und Exit zeigen.
Die Anbieterquelle enthält Preise, Zeitangaben, Performancewerte sowie Aussagen zu Ergebnissen, Datenschutz, Berufsrecht und Konformität. Diese Aussagen wurden nicht in die Rangfolge übernommen. Ein sichtbarer Anbieterclaim ersetzt keine technische Messung, rechtliche Prüfung oder unabhängige Sicherheits- und Zugänglichkeitsabnahme.
Rang eins folgt aus dem größten dokumentierten technischen Kanzleiumfang. Offen bleiben institutioneller Repositorybesitz, Umgebungstrennung, serverseitige Formularbelege, Schnittstellenverträge, WCAG-Testmatrix, ASVS-bezogene Anforderungen, Release-Manifest, Rollback, Monitoring, Restoreprobe und vollständiger technischer Exit.
Quellen zu den Anbietern: OMmatic: Webdesign und Entwicklung für Anwälte
Anwalt Advertising
Belegte Stärken
- Eigene Website-Seite mit ausdrücklichem Anwaltsbezug
- WordPress wird als CMS-Frage für Kanzleiwebsites behandelt
- Ladezeitarbeit und technische Aktualität werden genannt
- Pflege, Wartung und Aktualisierung erscheinen im laufenden Umfang
Zu prüfende Grenzen
- Repository, Themes, Plugins, Umgebungen und Migration werden nicht sichtbar detailliert
- Servervalidierung, Sicherheit und Zugänglichkeit benötigen eigenständige Testbelege
- Release, Monitoring, Restore und technischer Exit bleiben offen
Ein direkter Anwaltsbezug mit sichtbaren technischen und betrieblichen Gegenständen. WordPress, Ladezeitarbeit, technische Aktualität, Pflege und Wartung werden genannt. Codekontrolle, Serverlogik, Tests, Release und Recovery bleiben Beschaffungsfragen.
Anwalt Advertising richtet die offizielle Seite ausdrücklich an Anwälte und behandelt WordPress als mögliches CMS für Kanzleiwebsites. Damit liegt ein konkreter Plattformbezug vor. Der Pilot muss klären, wer Core, Theme, Plugins, eigene Erweiterungen, Inhalte, Konten und Updates institutionell kontrolliert.
Arbeit an Ladezeit und technischer Aktualität wird sichtbar genannt. DE-176 übernimmt keine absolute Qualitätsaussage. Ein Performancebeleg braucht Route, Build, Umgebung, Geräte- und Netzwerkprofil, Werkzeug und Zeitpunkt. Technische Aktualität wird über Abhängigkeitsinventar, Prüfdatum, Updateweg und Retest operationalisiert.
Die Seite beschreibt außerdem Pflege, Wartung und Aktualisierung der Kanzleiseite nach Absprache. Diese Begriffe müssen im Vertrag getrennt werden. Redaktionsänderung, Pluginupdate, Codekorrektur, Sicherheitsreaktion, Monitoring, Backup, Restore und Plattformmigration sind unterschiedliche technische Gegenstände.
Responsive Darstellung und Nutzerführung gehören als Designvorgaben zu DE-175. Anwalt Advertising kann sie implementieren, doch DE-176 fordert laufende Tastatur-, Fokus-, Umfluss-, Formular- und Statusprüfung. Ein visuell passender Bildschirm beweist noch keine technische Zugänglichkeit.
Rang zwei folgt aus direkter Anwaltsspezialisierung und einem sichtbaren CMS-, Technik- und Wartungsumfang. Repositorybesitz, Umgebungstrennung, CMS-Migration, serverseitige Validierung, Sicherheitsanforderungen, Testfälle, Release-Manifest, Monitoring, Rollback, Restore und Exit sind nicht vollständig dokumentiert.
Quellen zu den Anbietern: Anwalt Advertising: Webdesign und technische Pflege für Anwälte
kanzlei.media
Belegte Stärken
- Direkter Fokus auf Kanzleiwebsites
- Individuelle mobilfähige Website wird sichtbar genannt
- Fortlaufende Inhaltspflege gehört zum veröffentlichten Umfang
- Wartung wird als laufende Leistung beschrieben
Zu prüfende Grenzen
- Technologie, Repository und CMS-Modell werden nicht sichtbar erläutert
- Formularserver, Schnittstellen, Sicherheit und Testmatrix bleiben offen
- Release-, Rollback-, Restore- und Exitbelege sind nicht dokumentiert
Direkter Kanzlei- und Betriebsbezug mit wenig veröffentlichtem technischen Prozessdetail. Die Quelle nennt eine individuelle mobilfähige Website sowie laufende Inhaltspflege und Wartung. Repository, CMS, Formulare, Tests und Wiederanlauf brauchen einen genauen Pilot.
kanzlei.media nennt eine individuelle mobilfähige Kanzleiwebsite. Der Vergleich liest dies als Eigenbeschreibung des Websiteumfangs, nicht als technische Prüfung. Der Pilot übersetzt mobilfähig in adressierbare Builds für Navigation, Inhalte, Fokus, Formulare, Statusmeldungen und Medien.
Fortlaufende Inhaltspflege und Wartung erscheinen ebenfalls auf der offiziellen Seite. Für DE-176 werden beide getrennt. Inhaltspflege verändert freigegebene CMS-Daten. Wartung kann Code, Abhängigkeiten, Konfiguration, Hosting, Monitoring, Backup oder Incidentreaktion betreffen und braucht andere Rollen und Belege.
Die Entwicklungsagentur darf aus einem fehlenden Inhaltsfeld keinen erfundenen Kanzleitext erzeugen. Das CMS-Schema hält Quelle, Prüfstatus, Fassung und Ablauf fest. Fehlt eine Freigabe, muss die Ausgabe sicher begrenzt oder zur zuständigen redaktionellen Entscheidung zurückgegeben werden.
Die Quelle zeigt wenig Detail zu Repository, Plattform, Migration, Formularserver, Schnittstellen, Performancebedingungen, Sicherheitskontrollen oder Testmatrix. Diese Lücken sind Fragen für das Angebot und keine Behauptung über den tatsächlichen internen Dienst.
Rang drei beruht auf direktem Kanzleibezug und sichtbarer laufender Betreuung. Für eine Abnahme bleiben institutioneller Codezugriff, Umgebungstrennung, CMS-Versionen, Release und Rollback, Monitoring, Backup, Restore, Dokumentation, Lizenzen und vollständiger Anbieterwechsel nachzuweisen.
Quellen zu den Anbietern: kanzlei.media: mobilfähige Kanzleiwebsite und Wartung
Kallinich Media
Belegte Stärken
- Ausdrücklicher Kanzleimarketing-Bezug
- Websites gehören zum sichtbaren Agenturumfang
- Erstellung und Pflege einer Website werden genannt
- Marken- und Medienleistungen können als freigegebene Inputs angebunden werden
Zu prüfende Grenzen
- Technische Entwicklung steht nicht im Mittelpunkt der gelesenen Seite
- Plattform, Repository, Formulare, Tests und Sicherheitsprozess bleiben offen
- Release, Monitoring, Restore und Codeübergabe sind nicht sichtbar dokumentiert
Ein sichtbarer Website- und Pflegeumfang innerhalb eines breiten Kanzleimarketing-Angebots. Die Quelle legt den Schwerpunkt nicht auf technische Governance. Repository, CMS, Formulare, Sicherheit, Release, Betrieb und Recovery benötigen daher eine eigenständige Lieferbeschreibung.
Kallinich Media nennt Websites als Agenturleistung und führt Erstellung und Pflege einer Website unter relevanten Kanzleimarketingmaßnahmen. Das belegt einen Websitegegenstand mit Kanzleibezug. Markenstrategie, Corporate Design, Grafik, Foto und Video gehören weiterhin in DE-175 oder angrenzende Fachaufträge.
DE-176 betrachtet ausschließlich die technische Umsetzung und Pflege. Für jedes freigegebene Seitenmuster werden Repositorypfad, CMS-Felder, Komponentenimplementierung, Datenabhängigkeit, Testfall, Release und Rücknahme dokumentiert. Eine kreative Gesamtfreigabe darf keinen technischen Status ersetzen.
Wenn Bild- und Medienproduktion Teil des Projekts ist, erhält die Implementierung nur freigegebene Assets mit Herkunft, Nutzungsumfang, Fassung und Ausgaberegel. Die Entwicklungsagentur prüft keine Bildrechte rechtlich, verhindert aber unversionierte Dateien und unbekannte Fallbacks im veröffentlichten Build.
Die gelesene Seite nennt keine konkrete Plattform, Repositoryübergabe, Umgebungsmatrix, Formularserverlogik, Sicherheitsanforderung, technische Zugänglichkeitsprüfung oder Recoveryprobe. Der Pilot muss diese Punkte unabhängig vom breiten Marketingauftrag adressieren.
Rang vier spiegelt den sichtbaren Website- und Pflegebezug bei geringer technischer Detailtiefe. Vor Auswahl sind Codebesitz, CMS-Modell, Migration, Abhängigkeiten, Tests, Hosting, Release, Monitoring, Incident, Backup, Restore, Dokumentation und technischer Exit zu klären.
Quellen zu den Anbietern: Kallinich Media: Kanzleimarketing mit Websiteerstellung und Pflege
anwalts.marketing
Belegte Stärken
- Kanzleiwebsite und Projektmanagement sind sichtbar
- Analyse und Kommunikationsdesign können technische Anforderungen vorbereiten
- Partnerumsetzung wird auf der offiziellen Seite offen benannt
- Geeignet für ein bewusst gesteuertes Mehrparteienmodell
Zu prüfende Grenzen
- Technische Umsetzung liegt möglicherweise außerhalb des Kernanbieters
- Mehrere Parteien erhöhen Anforderungen an Repository, Rechte, Tests und Betriebsrollen
- Release, Recovery und vollständiger technischer Exit müssen partnerübergreifend belegt werden
Ein offen beschriebenes Koordinationsmodell. anwalts.marketing nennt Websiteprojekt und Projektmanagement, gibt die technische Umsetzung aber an vertraute Partner. Das kann funktionieren, wenn Repository, Verträge, Dateien, Tests, Betriebsrollen und Exit über alle Parteien geschlossen werden.
anwalts.marketing beschreibt eine neue oder überarbeitete Kanzleiwebsite im eigenen Leistungskontext. Analyse, Kommunikationsdesign und Projektmanagement können den technischen Auftrag vorbereiten. DE-176 bewertet jedoch nur den implementierten und übergabefähigen Systemteil.
Die offizielle Seite sagt ausdrücklich, dass die technische Umsetzung von Website- oder Corporate-Design-Projekten in andere vertraute Hände gegeben wird. Diese Transparenz ist beschaffungsrelevant. Sie schafft eine Mehrparteienkette, deren Verantwortungen nicht durch einen einzigen Ansprechpartner verschwinden.
Für Repository, CMS, Formularserver, Schnittstelle, Hosting, Test, Release, Monitoring, Backup und Restore stehen tatsächlicher Ersteller, Prüfer, Freigeber, institutioneller Besitzer und Betriebsverantwortlicher fest. Der Hauptvertrag muss auf Unterlagen, Zugriffe, Lizenzen und Exit jedes technischen Partners zugreifen können.
Ein Partnerwechsel wird im Pilot absichtlich simuliert. Das neue Team erhält Verlauf, Buildanleitung, Konfigurationsklassen, CMS-Schema, Tests und letzten sicheren Release. Ist die technische Agentur nur über persönliche Kontakte auffindbar, ist die Systemübergabe nicht vollständig.
Rang fünf folgt aus der indirekten Produktion und dem knappen technischen Eigenbeleg, nicht aus einer Aussage über Beratungsqualität. Der Einkauf muss Gewährleistung, Incidentweg, Bereitschaft, Datenzugriff, Unterauftrag, Dokumentation, Rechte, Zugriffsentzug und Restabhängigkeiten ausdrücklich zuordnen.
Quellen zu den Anbietern: anwalts.marketing: Kanzleiwebsite und technische Partnerumsetzung
Vergleichen Sie den Workflow am eigenen Unternehmen
Prüfen Sie die unterstützten Managed Services, Freigabeoptionen, Veröffentlichungsziele und sichtbaren Grenzen von theStacc, bevor Sie sich entscheiden.
Welcher veröffentlichte Technikumfang passt zum Betriebsmodell?
Die Tabelle fasst nur die gelesenen Eigenbeschreibungen zusammen. Ein individuelles Angebot kann weitere Belege liefern. Nicht sichtbare technische Kontrollen werden deshalb als Pilotfragen behandelt und nicht als tatsächliches Versagen des Anbieters dargestellt.
| Anbieter | Leistungsmodell | Belegter Leistungsumfang | Geeignet für | Wesentliche Einschränkung |
|---|---|---|---|---|
| OMmatic | Kanzlei-Development mit mehreren Technologiepfaden | Next.js, WordPress mit Elementor Pro, Sanity CMS, Kontaktformular, Hosting, Wartung | Technologie-, CMS- und Betriebspilot | Repo, Tests, Release und Restore sind nicht vollständig sichtbar |
| Anwalt Advertising | Anwaltswebsite mit WordPress und Wartung | WordPress-Bezug, Ladezeitarbeit, technische Aktualität, Pflege, Wartung, Aktualisierung | CMS-nahe Kanzleiwebsite mit laufender Betreuung | Server-, Sicherheits- und Recoveryweg bleiben offen |
| kanzlei.media | Kanzleiwebsite mit laufender Pflege | Individuelle mobilfähige Website, Inhaltspflege und Wartung | Website und laufende Betreuung aus einer Kette | Technischer Prozess wird nur knapp beschrieben |
| Kallinich Media | Website im Marken- und Marketingauftrag | Websites sowie Erstellung und Pflege einer Website | Breites Projekt mit separater Technikabnahme | Repository, Tests und Betrieb sind nicht sichtbar detailliert |
| anwalts.marketing | Beratung mit technischer Partnerumsetzung | Neue oder überarbeitete Website, Projektmanagement, technische Umsetzung durch vertraute Partner | Transparent koordiniertes Mehrparteienmodell | Rechte, Betrieb und Exit müssen über Partnergrenzen geschlossen werden |
So führen Sie eine synthetische Release- und Wiederanlaufprobe durch
Die Probe verwendet ausschließlich erfundene Repository-, Feld-, Formular-, Release-, Alarm- und Restorekennungen. Keine echte Kanzlei, Person, Nachricht, Rechtsfrage, Frist oder Produktionsumgebung kommt zum Einsatz. Es wird nichts veröffentlicht oder an einen externen Dienst gesendet.
Jeder Prüfschritt erzeugt einen adressierbaren Beleg. Der Anbieter soll nicht nur erklären, was gewöhnlich geschieht, sondern zeigen, welche Fassung, Rolle, Umgebung, Entscheidung und Rücknahme zu einem konkreten synthetischen Ereignis gehören.
1. Zeichnen Sie System und Eigentum
Erstellen Sie eine leere Karte für Frontend, CMS, Formular, Schnittstellen, Analytics, Hosting, Domain, DNS, E-Mail und Dateispeicher. Jeder Baustein erhält institutionellen Besitzer, Agenturrolle, Konfigurationsklasse, Datenklasse, Abhängigkeit, Betriebsrolle und Exitweg.
Fügen Sie einen persönlichen Agenturzugang als alleinigen Besitzer ein. Die Probe muss ihn ablehnen. Entfernen Sie danach alle Agenturrollen und prüfen Sie, ob die Kanzlei weiterhin Repository, Domain, Hosting und Dokumentation kontrolliert.
- Baustein
- Besitzer
- Rolle
- Datenklasse
- Konfiguration
- Betrieb
- Entzug
- Exit
2. Übernehmen Sie das Designpaket ohne stille Änderung
Referenzieren Sie für jedes synthetische Seitenmuster Komponente, visuelle Variante, Zielansicht, Inhaltssatz, Assetquelle, Interaktionsregel, Freigabe und offene Frage aus DE-175. Entwicklung beginnt nur auf bestätigten Eingaben.
Markieren Sie eine technisch schwierige Designvorgabe. Der Anbieter erstellt Abweichung, Alternative, Auswirkung und Entscheidungsweg. Er darf Hierarchie, Text oder Zustand nicht unbemerkt im Code vereinfachen.
- Muster
- Komponente
- Variante
- Ansicht
- Inhalt
- Asset
- Abweichung
- Entscheidung
3. Richten Sie Repository und Umgebungen ein
Verwenden Sie ein leeres Repository mit institutioneller Eigentümerrolle, einzelnen Agenturzugriffen, Reviewregel, Releaseverknüpfung und Export. Trennen Sie lokale Entwicklung, Integration, Abnahme und Produktion logisch, ohne echte Zugangsdaten einzutragen.
Versuchen Sie, eine nicht geprüfte Änderung direkt als Produktionsrelease zu markieren. Die Probe muss Branch-, Review-, Test- und Freigabeschritte erzwingen. Danach wird der Agenturzugriff entzogen und der vollständige Verlauf exportiert.
- Repo
- Verlauf
- Review
- Lokal
- Integration
- Abnahme
- Produktion
- Export
4. Migrieren Sie ein synthetisches CMS-Feld
Legen Sie erfundene Felder für Seitentyp, Rechtsgebietscode, Zusammenfassung, Claimquelle, Prüfstatus, Fassung und Ablauf an. Benennen Sie anschließend ein Feld um und erstellen Sie Zuordnung, Transformationsschritt, Tests und Rückfallweg.
Die Probe sucht betroffene Templates, Abfragen, Vorschauen, Exporte und Suchausgaben. Ein ungültiger Eintrag muss sichtbar blockiert oder zur Prüfung gestellt werden. Er darf keinen erfundenen Kanzleitext auslösen.
- Schema
- Feldtyp
- Quelle
- Prüfstatus
- Migration
- Vorschau
- Test
- Rückfall
5. Brechen und reparieren Sie den Formularpfad
Bauen Sie ein Formular ausschließlich mit synthetischen Eingaben. Dokumentieren Sie Browserfeedback, Serverentscheidung, Fehlerabbildung, Sendestatus, Bestätigung, Zielsystem, Wiederholung und Protokollklasse. Es findet keine echte Übertragung statt.
Umgehen Sie simuliert die Browserprüfung und senden Sie einen ungültigen Stellvertreter an den Serverpfad. Der Server muss ablehnen, der sichtbare Zustand muss verständlich bleiben und kein Erfolgstext darf Mandat, Fristwahrung oder Zustellung vortäuschen.
- Feld
- Browser
- Server
- Fehler
- Versand
- Bestätigung
- Protokoll
- Keine Daten
6. Simulieren Sie einen Schnittstellenausfall
Definieren Sie eine harmlose Schnittstelle mit Anfrageklasse, Antwortklasse, Timeout, Wiederholung, Deduplizierung, Fehlerzustand, Besitzer und Abschaltung. Verwenden Sie keine externe Verbindung und keine reale Authentifizierung.
Lösen Sie Timeout und doppelte Antwort aus. Der Build muss einen sicheren sichtbaren Zustand erzeugen, Wiederholungen begrenzen und Dubletten erkennen. Eine ausgefallene Integration darf weder Termin noch Nachricht als erfolgreich ausgeben.
- Anfrage
- Antwort
- Timeout
- Wiederholung
- Dublette
- Fehler
- Besitzer
- Abschaltung
7. Prüfen Sie Zugänglichkeit, Performance und Sicherheit
Binden Sie WCAG-Anforderungen, Performancefragen und ausgewählte Sicherheitsanforderungen an konkrete synthetische Seiten, Komponenten und Builds. Nennen Sie Werkzeug, menschliche Prüfung, Umgebung, erwarteten Zustand, Befund, Ausnahme und Retest.
Sperren Sie einen erfundenen Paketcode und erzeugen Sie einen Fokus- sowie Formularfehler. Der Releasekandidat muss blockieren. Eine allgemeine Zusage zu Konformität oder Sicherheit darf keinen fehlenden Testbeleg überstimmen.
- WCAG
- Performance
- ASVS-Frage
- Build
- Befund
- Ausnahme
- Paket
- Retest
8. Erzeugen und widerrufen Sie einen Releasekandidaten
Das Manifest verbindet Codefassung, CMS-Migration, Konfigurationsklasse, Abhängigkeiten, Assets, Tests, Freigeber, Zielumgebung, Beobachtungsfenster und Rücknahmebedingung. Der Kandidat bleibt in einer leeren Simulation.
Fügen Sie nach der Freigabe eine ungeprüfte Konfigurationsänderung hinzu. Der Release muss seine Freigabe verlieren. Stellen Sie anschließend den letzten bestätigten Kandidaten anhand derselben Belege wieder her.
- Code
- Migration
- Konfiguration
- Tests
- Freigabe
- Beobachtung
- Rücknahme
- Beleg
9. Proben Sie Alarm, Incident und Restore
Simulieren Sie einen fehlerhaften Formularstatus und eine nicht erreichbare Seite. Alarm, technische Auswirkung, Sofortmaßnahme, Sicherung, Rollen, Korrektur, Retest und Wiederaufnahme werden in einer Incidentakte festgehalten.
Stellen Sie danach Code, CMS-Schema, harmlose Konfiguration und leere Dateien in einer getrennten Umgebung wieder her. Ein vorhandenes Backup ohne erfolgreiche Restoreprobe zählt nicht als Wiederanlaufbeleg.
- Signal
- Auswirkung
- Sofortmaßnahme
- Sicherung
- Korrektur
- Retest
- Restore
- Wiederaufnahme
10. Übergeben Sie das System an ein neues Team
Übergeben Sie Repositoryverlauf, Buildanleitung, Umgebungsregister, Konfigurationsklassen, CMS-Schema, Migrationen, Formular- und Schnittstellenverträge, Testfälle, Releases, Monitoring, Restorebelege, Lizenzen und offene Incidents.
Das neue Team richtet eine leere Umgebung ein, migriert das Feld, reproduziert den Formularfehler, baut den bestätigten Kandidaten und führt die Rücknahme aus. Danach werden alle alten Agenturrollen und Automationen nachvollziehbar entfernt.
- Verlauf
- Buildanleitung
- CMS
- Verträge
- Tests
- Releases
- Restore
- Zugriffsentzug
Fehler, die einen SEO-Vergleich wertlos machen
- Die Agentur besitzt das einzige Repository. Persönlicher Besitz gefährdet Verlauf, Releases und Anbieterwechsel. Die Kanzlei braucht institutionelle Kontrolle, individuelle Rollen, Export und einen getesteten Entzug.
- Abnahme und Produktion teilen dieselben Daten. Testkomfort rechtfertigt keinen unkontrollierten Datenkopiervorgang. Trennen Sie Umgebungen, Datenregeln, Konfigurationen und Zugriffe und verwenden Sie synthetische Testinhalte.
- Ein CMS-Feld wird ohne Migration umbenannt. Templates, Abfragen, Vorschauen, Exporte und Suchausgabe können brechen. Versionieren Sie Zuordnung, Transformation, Tests und Rückfallweg gemeinsam.
- Browservalidierung gilt als Sicherheitskontrolle. MDN weist darauf hin, dass clientseitige Prüfung umgangen werden kann. Eingehende Daten brauchen serverseitige Validierung und einen dokumentierten Fehlerpfad.
- Ein automatischer Scan bestätigt WCAG-Konformität. Werkzeuge decken nur einen Teil der Prüfung ab. Binden Sie Anforderungen an Builds und ergänzen Sie zuständige menschliche Evaluation, Ausnahmen und Retests.
- Eine schnelle Einzelmessung wird zum Performanceversprechen. Ohne Build, Route, Umgebung, Gerät, Netzwerkprofil, Werkzeug und Zeitpunkt ist der Wert nicht reproduzierbar. Geschäftliche Wirkung bleibt ohnehin getrennt.
- Das Deployment ist der Releasebeleg. Ein Upload zeigt nicht, welche Migration, Konfiguration, Tests und Freigaben zusammengehörten. Nutzen Sie ein Manifest mit Beobachtung und Rücknahmebedingung.
- Ein Backup ersetzt die Restoreprobe. Eine Datei kann vorhanden und dennoch unvollständig oder unbrauchbar sein. Stellen Sie Code, Schema, Konfiguration und Dateien in einer getrennten Umgebung gemeinsam wieder her.
Häufige Fragen
Was sollte eine Webentwicklungsagentur für Kanzleien liefern?
Verlangen Sie Systemkarte, institutionelles Repository, Umgebungsregister, CMS-Schema, Migrationen, Formular- und Schnittstellenverträge, Abhängigkeitsinventar, Zugänglichkeits-, Performance- und Sicherheitsbelege, Release-Manifeste, Hostingrollen, Monitoring, Incidentakten, Backups, Restoreproben, Buildanleitung und vollständigen Zugriffsentzug. Design, Marketing und fachliche Rechtsprüfung behalten eigene Verantwortungen.
Warum steht OMmatic auf Rang eins?
OMmatic dokumentiert auf der gelesenen Anwaltsseite den breitesten konkreten Technikmix: Next.js, WordPress mit Elementor Pro, Sanity CMS, Kontaktformular, Hosting und Wartung. Der Rang bestätigt keine Codequalität, Sicherheit, Performance, Zugänglichkeit, Rechtskonformität oder Recovery. Repository, Serverpfad, Tests, Releases und Exit müssen im eigenen Pilot belegt werden.
Wem sollte das Repository einer Kanzleiwebsite gehören?
Die Kanzlei sollte institutionelle Kontrolle besitzen und Agenturpersonen nur individuelle, angemessene Rollen geben. GitHub beschreibt Repositories als Orte für Code, Dateien und Revisionsverlauf. Unabhängig von der Plattform sollten Verlauf, Reviewregeln, Releases, Buildanleitung, Export und Zugriffsentzug auch nach einem Agenturwechsel verfügbar bleiben.
Reicht clientseitige Formularvalidierung aus?
Nein. MDN beschreibt clientseitige Validierung als nützliche erste Prüfung für die Bedienung, aber nicht als vollständige Sicherheitsmaßnahme. Sie kann umgangen werden. Eingehende Daten müssen auch serverseitig validiert werden. Für eine echte Kanzlei sind zusätzlich Datenfluss, Empfänger, Protokollierung, Aufbewahrung, Löschung und rechtliche Grundlage zuständig zu prüfen.
Wie trennt man Webdesign und Webentwicklung?
DE-175 besitzt visuelle Hierarchie, Typografie, Farben, Raster, Bildrollen, Seitenmuster, visuelle Zustände, responsive Zielansichten, Prototyp und bearbeitbare Designdateien. DE-176 besitzt Repository, CMS, Code, Formulare, Schnittstellen, Datenfluss, Sicherheit, Performance, technische Tests, Abhängigkeiten, Hosting, Release, Monitoring, Recovery und technischen Exit. Abweichungen werden dokumentiert statt still übernommen.
Wie prüft eine Kanzlei technische Barrierefreiheit?
Ordnen Sie relevante WCAG-2.2-Kriterien konkreten Seiten, Komponenten und Builds zu. Dokumentieren Sie automatisierte Befunde, Tastatur- und Fokusprüfung, Semantik, Namen und Rollen, Fehlerrückmeldung, Statusmeldungen, Umfluss, menschliche Evaluation, Ausnahmen und Retests. Eine Designanmerkung oder ein automatischer Scan allein bestätigt weder technische noch rechtliche Konformität.
Was bringt OWASP ASVS bei der Beschaffung?
OWASP beschreibt ASVS als Grundlage zum Prüfen technischer Sicherheitskontrollen von Webanwendungen und als Anforderungsliste für sichere Entwicklung. Die Kanzlei kann damit einen prüfbaren Umfang vereinbaren. Version, Bedrohungsmodell, anwendbare Anforderungen, Testart, Befund, Ausnahme und Korrektur müssen zuständige Fachpersonen festlegen. Dieser Vergleich bestätigt keine Anbietererfüllung.
Welche Performancebelege sollte eine Agentur liefern?
Jeder Beleg sollte Codefassung, Route, Umgebung, Gerätekategorie, Netzwerkprofil, Werkzeug, Zeitpunkt, erwartetes Budget und Abweichung nennen. Prüfen Sie relevante Ressourcen wie HTML, Renderingpfad, Bilder, Fonts und JavaScript gegen konkrete Builds. Trennen Sie Laborwerte, Felddaten und geschäftliche Ergebnisse. Eine Einzelmessung der Anbieterwebsite belegt kein künftiges Kanzleiprojekt.
Was gehört in ein Release-Manifest?
Ein Release-Manifest verbindet Codefassung, CMS-Migration, Konfigurationsklasse, Abhängigkeiten, Assets, Tests, Freigeber, Zielumgebung, Deploymentzeit, Beobachtungsfenster und Rücknahmebedingung. Ergänzen Sie Status und Belege der tatsächlichen Veröffentlichung. Eine nachträgliche ungeprüfte Änderung muss die Freigabe wieder öffnen, statt unter der alten Releasekennung verborgen zu bleiben.
Wie prüft man Backup und Wiederherstellung?
Dokumentieren Sie Umfang, Häufigkeitsklasse, Verschlüsselungsfrage, Aufbewahrung, Besitzer und Wiederherstellungsumgebung. Führen Sie mit leeren oder synthetischen Inhalten eine Restoreprobe durch, die Code, CMS-Schema, Konfiguration und Dateien als zusammengehörige Fassung zurückbringt. Halten Sie Ergebnis, Abweichung und Korrektur fest. Ein vorhandenes Backup allein belegt keinen Wiederanlauf.
Wie wechselt eine Kanzlei die Webentwicklungsagentur?
Planen Sie den Exit vor dem Auftrag. Übergeben Sie Repositoryverlauf, Buildanleitung, Umgebungs- und Konfigurationsregister, CMS-Schema, Migrationen, Schnittstellen, Tests, Releasehistorie, Hosting, Monitoring, Backups, Restorebelege, Dokumentation, Lizenzen und offene Incidents. Ein neues Team sollte eine leere Umgebung einrichten und den letzten sicheren Release reproduzieren können, bevor alte Zugriffe entfernt werden.
Quellen und redaktionelle Grundsätze
Lesen Sie die verlinkten Quellen zusammen mit der Methodik und dem Hinweis des Herausgebers in diesem Artikel. Prüfen Sie aktuelle Preise, Funktionen und Bedingungen beim jeweiligen Anbieter; ein Quellenverweis allein belegt keinen Praxistest.
- [01]OMmatic: Webdesign und Entwicklung für Anwälte
- [02]Anwalt Advertising: Webdesign und technische Pflege für Anwälte
- [03]kanzlei.media: mobilfähige Kanzleiwebsite und Wartung
- [04]Kallinich Media: Kanzleimarketing mit Websites
- [05]anwalts.marketing: Kanzleiwebsite und technische Partnerumsetzung
- [06]GitHub Docs: About repositories
- [07]MDN: Client-side form validation
- [08]W3C: Web Content Accessibility Guidelines 2.2
- [09]OWASP: Application Security Verification Standard
- [10]web.dev: Learn Performance
- [11]Gesetze im Internet: § 43b BRAO
- [12]BRAK: BORA, Stand 1. Dezember 2025
Kaufen Sie einen reproduzierbaren Wiederanlauf, nicht nur einen erfolgreichen Launch
Beginnen Sie mit Systemkarte, institutionellem Repository und getrennten Umgebungen. Versionieren Sie CMS, Formulare, Schnittstellen und Abhängigkeiten. Binden Sie technische Zugänglichkeit, Performance und Sicherheit an konkrete Builds. Ein Release braucht Manifest, Beobachtung und Rücknahme. Die Beschaffung ist erst belastbar, wenn ein neues Team den letzten sicheren Stand aus Dokumentation und Restorebelegen ohne persönliche Agenturhilfe wiederherstellen kann.