{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://contegus.com/#website",
      "url": "https://contegus.com",
      "name": "Contegus",
      "inLanguage": "de"
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/akuthilfe/#webpage",
      "url": "https://contegus.com/akuthilfe/",
      "name": "Anwendung ausgefallen? Deployment fehlgeschlagen?",
      "description": "Hilfe bei ausgefallenen Anwendungen, Server- und Dienstproblemen, fehlgeschlagenen Deployments sowie WordPress- und E-Mail-Fehlern.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/akuthilfe/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/akuthilfe/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Leistungen",
          "item": "https://contegus.com/leistungen/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Akute Hilfe"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/bestandsaufnahme/#webpage",
      "url": "https://contegus.com/bestandsaufnahme/",
      "name": "Technische Fehler und Sicherheitsfragen gezielt untersuchen.",
      "description": "Fehler in Anwendungen und Infrastruktur untersuchen, Sicherheitsfragen prüfen, Befunde dokumentieren und vereinbarte Maßnahmen umsetzen.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/bestandsaufnahme/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/bestandsaufnahme/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Leistungen",
          "item": "https://contegus.com/leistungen/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Fehlersuche und Sicherheitsprüfung"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/blog/digitale-barrierefreiheit/#webpage",
      "url": "https://contegus.com/blog/digitale-barrierefreiheit/",
      "name": "BFSG 2025: Digitale Barrierefreiheit – Was wirklich gilt und warum es sich trotzdem lohnt",
      "description": "BFSG 2025 verständlich erklärt: Für welche Websites Barrierefreiheit wirklich Pflicht ist, wer nicht betroffen ist und warum es sich trotzdem lohnt.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "dateModified": "2026-04-13T00:00:00.000Z",
      "breadcrumb": {
        "@id": "https://contegus.com/blog/digitale-barrierefreiheit/#breadcrumb"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://contegus.com/blog/digitale-barrierefreiheit/#article",
      "headline": "BFSG 2025: Digitale Barrierefreiheit – Was wirklich gilt und warum es sich trotzdem lohnt",
      "description": "BFSG 2025 verständlich erklärt: Für welche Websites Barrierefreiheit wirklich Pflicht ist, wer nicht betroffen ist und warum es sich trotzdem lohnt.",
      "mainEntityOfPage": {
        "@id": "https://contegus.com/blog/digitale-barrierefreiheit/#webpage"
      },
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "datePublished": "2025-06-28T00:00:00.000Z",
      "dateModified": "2026-04-13T00:00:00.000Z",
      "author": {
        "@type": "Person",
        "name": "Kevin Kulik"
      },
      "articleBody": "BFSG 2025: Digitale Barrierefreiheit – Was wirklich gilt und warum es sich trotzdem lohnt \n28.6.2025 · Kevin Kulik \nAktualisiert: 13.4.2026 \n      \nErst klären: Betrifft dich das BFSG überhaupt? \nSeit dem 28. Juni 2025 ist das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft – Deutschlands Umsetzung des European Accessibility Act (EAA). Seitdem kursieren viele Halbwahrheiten. Manche Anbieter kommunizieren das Thema sehr alarmistisch, Overlay-Tools versprechen Barrierefreiheit per Knopfdruck. Und im schlimmsten Fall zahlen Unternehmer Geld für etwas, das sie gar nicht brauchen. \nDeshalb fangen wir mit dem Wichtigsten an: Wer ist überhaupt betroffen? \nWas das BFSG tatsächlich regelt \nDas BFSG gilt nicht für alle Websites. Es gilt für bestimmte digitale Produkte und Dienstleistungen: \n \nE-Commerce – Online-Shops, die Waren oder Dienstleistungen verkaufen \nOnline-Banking und Finanzdienstleistungen \nTelekommunikationsdienste \nPersonenbeförderung – Ticketbuchung (Bahn, Flug, ÖPNV) \nMessenger-Dienste \nE-Books und E-Book-Reader \nBestimmte Software und Betriebssysteme  \nWer ist befreit? \nKleinstunternehmen sind von den Dienstleistungs-Pflichten ausgenommen, wenn beide Bedingungen erfüllt sind: \n \nWeniger als 10 Mitarbeiter (Vollzeitäquivalent) \nWeniger als 2 Millionen Euro Jahresumsatz oder Bilanzsumme  \nDas bedeutet konkret:    Unternehmen BFSG-Pflicht?     Online-Shop mit 15 Mitarbeitern Ja   Bank oder Versicherung mit Online-Portal Ja   Telefonanbieter mit Kunden-App Ja   Arztpraxis mit Info-Website Nein   Maler mit Kontaktseite Nein   Selbstständiger Berater mit Portfolio Nein   Friseur mit Online-Terminbuchung, unter 10 MA Nein (Kleinstunternehmen)    \nWenn du ein kleiner Dienstleister mit einer reinen Info-Website bist, fällst du wahrscheinlich nicht unter die beschriebenen BFSG-Dienstleistungspflichten. Im Zweifel braucht es eine Einordnung des konkreten Angebots. \nAber – und das ist der Punkt dieses Artikels – es gibt trotzdem verdammt gute Gründe, sich mit Barrierefreiheit zu beschäftigen. Nicht weil du musst. Sondern weil es sich lohnt. \nWarum Barrierefreiheit auch ohne Pflicht Sinn ergibt \nMehr Menschen erreichen \nDigitale Barrierefreiheit klingt erst mal abstrakt. Lass uns das konkret machen. \nOpa Herbert, 72 Jahre alt. Seine Sehkraft lässt nach. Wenn die Schriftgröße deiner Website fest auf 14 Pixel eingestellt ist und er sie nicht vergrößern kann, liest er deine Texte nicht. Wenn der Kontrast zwischen Text und Hintergrund zu schwach ist, verschwimmt für ihn alles zu grauem Brei. Herbert ist kein Einzelfall – in Deutschland leben über 10 Millionen Menschen über 65 Jahre. Viele davon haben altersbedingte Seheinschränkungen. \nLisa, 28 Jahre alt, Dyslexie. Sie hat eine Lese-Rechtschreib-Schwäche. Klare Strukturen, einfache Sprache und die Möglichkeit, sich Texte von einem Screenreader vorlesen zu lassen, sind für sie Gold wert. Komplizierte Schachtelsätze, fehlende Überschriftenhierarchien und unleserliche Schriftarten machen deine Inhalte für sie unzugänglich. \nMia, 23 Jahre alt, gehörlos. Videos ohne Untertitel oder Transkripte sind für sie wertlos. Wenn dein Erklärvideo nur auf Ton setzt, verlierst du Mia als Kundin. Und mit ihr etwa 80.000 gehörlose Menschen allein in Deutschland. \nThomas, 45 Jahre alt. Er hat sich beim Skifahren den Arm gebrochen und kann seine Maus temporär nicht nutzen. Wenn deine Website nicht mit der Tastatur bedienbar ist, kann Thomas bei dir keinen Termin buchen. \nEtwa 15 Prozent der Bevölkerung haben irgendeine Form von Einschränkung. Dazu kommen situative Barrieren: grelles Sonnenlicht auf dem Smartphone, laute Umgebung ohne Kopfhörer, langsame Internetverbindung. Barrierefreiheit hilft allen – nicht nur Menschen mit Behinderungen. \nBesseres Google-Ranking \nViele Maßnahmen für Barrierefreiheit überschneiden sich mit solider technischer SEO: sauberer HTML-Code, klare Strukturen, sinnvolle Alternativtexte und gute Nutzbarkeit. Das ist keine Ranking-Garantie. Aber es sorgt oft dafür, dass Inhalte für Menschen und Suchmaschinen leichter verständlich werden. \nProfessionelleres Auftreten \nEine barrierefreie Website ist in der Regel auch eine benutzerfreundlichere Website. Klare Navigation, lesbare Schriften, logische Strukturen – das fällt jedem Besucher positiv auf, nicht nur Menschen mit Einschränkungen. Gerade in Branchen wie Gesundheit, Beratung oder Therapie sendet Barrierefreiheit ein starkes Signal: Hier wird an alle gedacht. \nZukunftssicherheit \nDie Kleinstunternehmen-Ausnahme kann sich ändern. Der Trend geht klar Richtung flächendeckende Barrierefreiheit. Wer heute schon sauber arbeitet, muss morgen nicht nachrüsten. Und wer in den USA aktiv ist: Dort gilt der Americans with Disabilities Act (ADA) deutlich breiter – auch für kleine Praxen und Dienstleister. \nDer Punkt ist nicht, jede Norm auswendig zu kennen. Der Punkt ist, dass Lesbarkeit, Bedienbarkeit und saubere Struktur darüber entscheiden, ob eine Website für mehr Menschen tatsächlich nutzbar ist. \nWCAG 2.2 AA: Was technisch dahinter steckt \nGut, du willst deine Website zugänglicher machen, ob aus Pflicht oder aus Überzeugung. Aber was heißt das konkret? Für neue und aktualisierte technische Prüfungen nutze ich WCAG 2.2, Konformitätsstufe AA, als Maßstab. Ob und welche gesetzliche Pflicht im Einzelfall gilt, ist davon getrennt zu prüfen. \nSauberer, semantischer HTML-Code \nDas Fundament jeder barrierefreien Website. Eine Überschrift ist eine <h1>, <h2> oder <h3> – nicht einfach ein fett formatierter Absatz. Eine Liste wird mit <ul> oder <ol> ausgezeichnet. Ein Button ist ein <button>, kein gestyltes <div>. \nScreenreader – Software, die blinden oder sehbehinderten Menschen Webinhalte vorliest – sind auf diese semantische Struktur angewiesen. Wenn deine Überschriften keine echten Überschriften sind, kann ein Screenreader-Nutzer nicht von Kapitel zu Kapitel springen. Wenn deine Buttons keine Buttons sind, erkennt die Hilfstechnologie nicht, dass da etwas klickbar ist. \nARIA-Attribute für dynamische Inhalte \nModerne Websites sind interaktiv. Inhalte werden nachgeladen, Menüs klappen auf und zu, Fehlermeldungen erscheinen dynamisch. ARIA-Attribute (Accessible Rich Internet Applications) machen das für Hilfstechnologien verständlich. \nEin aufklappbares Menü kann mit aria-expanded=\"true\" oder aria-expanded=\"false\" kennzeichnen, ob es gerade geöffnet oder geschlossen ist. Ein Live-Update kann mit aria-live markiert werden, sodass Screenreader die Änderung ansagen. \nDie korrekte Anwendung erfordert technisches Verständnis. Falsch eingesetzt, können ARIA-Attribute mehr schaden als nutzen. Richtig implementiert, machen sie komplexe Webanwendungen erst zugänglich. \nLesbarkeit: Kontraste und Typografie \nDer WCAG-Standard definiert klare Mindestkontraste: Normaler Text muss ein Kontrastverhältnis von mindestens 4,5:1 zu seinem Hintergrund haben. Großer Text (ab 18 Punkt oder 14 Punkt fett) benötigt mindestens 3:1. \nHellgrauer Text auf weißem Hintergrund – ein beliebtes Design-Element – erfüllt diese Anforderungen oft nicht. Die Schriftgröße sollte anpassbar sein – Nutzer müssen den Text vergrößern können, ohne dass das Layout zerbricht. \nVollständige Tastaturbedienbarkeit \nJeder interaktive Teil deiner Website – Links, Buttons, Formularfelder, Menüs – muss allein mit der Tastatur erreichbar und bedienbar sein. Der Fokus muss sichtbar sein. Dropdown-Menüs müssen sich auch ohne Mausklick öffnen lassen. \nViele moderne Websites – besonders solche, die stark auf JavaScript setzen – haben massive Probleme damit. Custom-Widgets wie selbstgebaute Datepicker, Slider oder modale Dialoge sind oft nur mit der Maus bedienbar. \nAlternativtexte für Bilder \nJedes inhaltlich relevante Bild braucht einen beschreibenden Alternativtext. Ein Produktfoto braucht eine Beschreibung wie “Rotes Damen-T-Shirt aus Bio-Baumwolle, V-Ausschnitt”. Rein dekorative Bilder sollten mit einem leeren Alt-Text (alt=\"\") gekennzeichnet sein, damit Screenreader sie überspringen. \nFehlen Alt-Texte komplett, liest der Screenreader oft den Dateinamen vor: “IMG_4729.jpg”. Das hilft niemandem. \nUntertitel und Transkripte für Videos \nVideos mit gesprochenem Inhalt brauchen Untertitel. Idealerweise auch ein Transkript. Automatisch generierte Untertitel sind ein Anfang, aber oft ungenau – für wirklich barrierefreie Videos sollten sie manuell überprüft werden. \nResponsive Design und Zoom-Fähigkeit \nDeine Website muss sich an verschiedene Bildschirmgrößen anpassen und auf bis zu 200 Prozent zoombar sein, ohne dass Inhalte verschwinden oder überlappen. \nKlare Fehlerbehandlung in Formularen \nFehlermeldungen sollten nicht nur durch rote Farbe gekennzeichnet sein (Menschen mit Rot-Grün-Schwäche sehen das nicht), sondern auch durch Text. Die Meldung sollte direkt beim betroffenen Feld stehen und konkret sagen, was falsch ist. \nLogische Überschriftenstruktur \nEine <h1> als Hauptüberschrift, darunter <h2> für Hauptabschnitte, darunter <h3> für Unterabschnitte. Diese Struktur hilft Screenreader-Nutzern, schnell durch die Seite zu navigieren. Viele Websites setzen Überschriften rein nach optischen Gesichtspunkten ein – das ist ein Fehler. \nWarum das komplex ist – und trotzdem machbar \nDie Liste der Anforderungen ist lang. Der Hauptgrund für die Komplexität: Du musst für Nutzungsszenarien entwickeln, die du selbst vielleicht nie erlebst. Wenn du kein Screenreader-Nutzer bist, merkst du nicht, wenn deine Navigation dafür unbrauchbar ist. Wenn du eine Maus benutzt, fällt dir nicht auf, dass wichtige Buttons per Tastatur nicht erreichbar sind. \nHinzu kommt: Viele moderne Webtechnologien wurden nicht mit Barrierefreiheit als Priorität entwickelt. Auch fertige Templates und Themes – egal ob für WordPress, Shopify oder andere Systeme – sind oft nicht barrierefrei. Sie mögen hübsch aussehen, aber unter der Haube fehlen Alt-Texte, die Kontraste stimmen nicht, die Tastaturbedienung ist kaputt. \nDie gute Nachricht: Es ist machbar. Barrierefreiheit ist keine Raketenwissenschaft, sondern eine Frage von Wissen, Sorgfalt und Erfahrung. \nWie du vorgehen kannst \nSchritt 1: Bestandsaufnahme \nFinde heraus, wie barrierefrei deine aktuelle Website ist. Automatisierte Tools wie WAVE, Axe oder der Lighthouse-Accessibility-Test in den Chrome Developer Tools zeigen offensichtliche Probleme: fehlende Alt-Texte, zu schwache Kontraste, fehlende Formular-Labels. \nAber: Automatisierte Tools decken nur etwa 30 bis 40 Prozent aller Probleme auf. Viele Aspekte – die Qualität der Alt-Texte, die logische Tab-Reihenfolge, die Bedienbarkeit komplexer Widgets – lassen sich nicht automatisch prüfen. \nVersuch, deine Website nur mit der Tastatur zu bedienen. Schalte einen Screenreader ein (NVDA auf Windows, VoiceOver auf macOS) und hör zu, was vorgelesen wird. Ist es verständlich? Kannst du navigieren? \nSchritt 2: Prioritäten setzen \nNicht alle Probleme sind gleich schwerwiegend. Konzentriere dich zuerst auf die High-Impact-Probleme: \n \nKann die Website vollständig mit der Tastatur bedient werden? \nHaben alle relevanten Bilder Alt-Texte? \nSind die Farbkontraste ausreichend? \nFunktionieren alle Formulare mit Hilfstechnologien? \nIst die Überschriftenstruktur logisch?  \nWenn diese Basics stimmen, hast du schon einen großen Schritt gemacht. \nSchritt 3: Selbst machen oder Hilfe holen? \nSelbst machen – möglich, wenn du technisch versiert bist und Zeit hast. Die WCAG-Dokumentation, Tutorials und Community-Foren helfen. Aber Barrierefreiheit ist komplex, und du trägst das Risiko, wichtige Dinge zu übersehen. \nProfessionelle Hilfe – sinnvoll, wenn du keine Zeit für Tests, Strukturarbeit und technische Fehlersuche hast oder wenn du nicht sicher weißt, wo die eigentlichen Probleme sitzen. Verglichen mit hektischem Nachrüsten kurz vor einem Relaunch oder nach einer Beschwerde ist eine saubere Einordnung oft der ruhigere Weg. \nSchritt 4: Umsetzen und testen \nArbeite die identifizierten Probleme Schritt für Schritt ab. Teste nach jeder Änderung. Dokumentiere, was du tust – das hilft dir und anderen, die an der Website weiterarbeiten. \nBarrierefreiheit ist kein Projekt, das man einmal abschließt. Wenn du neue Inhalte hinzufügst oder das Design änderst, muss Barrierefreiheit weiterhin berücksichtigt werden. \nFür wen das BFSG wirklich gilt: Was du beachten musst \nFalls du doch unter die BFSG-Pflicht fällst – etwa weil du einen Online-Shop betreibst oder über der Kleinstunternehmen-Grenze liegst – hier die wichtigsten Fakten: \nSeit dem 28. Juni 2025 müssen betroffene digitale Produkte und Dienstleistungen die gesetzlichen Barrierefreiheitsanforderungen erfüllen. Für technische Website-Prüfungen ist WCAG 2.2 AA der aktuelle Arbeitsmaßstab; die rechtliche Einordnung eines konkreten Angebots bleibt davon getrennt. \nMögliche Konsequenzen bei Verstößen: \n \nBußgelder durch Marktüberwachungsbehörden – bis zu 100.000 Euro \nAbmahnungen durch Verbraucherschutzverbände \nKlagen von betroffenen Nutzern auf Beseitigung der Barrieren  \nDas sind keine theoretischen Szenarien. Wer einen Online-Shop mit über 10 Mitarbeitern oder über 2 Millionen Euro Umsatz betreibt und offensichtliche Barrieren hat, sollte jetzt handeln. \nWie ich dabei unterstütze \nNicht jede Website braucht sofort ein großes Barrierefreiheits-Projekt. Meistens ist zuerst wichtig, die Lage sauber einzuordnen: \n \nBist du überhaupt BFSG-pflichtig? \nGeht es um ein paar klare Baustellen oder um strukturelle Probleme? \nLässt sich der Bestand sinnvoll verbessern oder sollte Barrierefreiheit erst im nächsten Umbau sauber mitgedacht werden?  \nJe nach Situation kann das sehr unterschiedlich aussehen: \n \nkurze technische Einordnung \ngezielte Behebung einzelner Probleme \nÜberarbeitung von Formularen, Navigation, Struktur oder Kontrasten \nEinplanung von Barrierefreiheit in einen Relaunch oder Umbau  \nWichtig ist nur: Barrierefreiheit sollte nicht als Zusatzetikett behandelt werden, sondern als Teil sauberer technischer Qualität. \nWenn du nicht nur den rechtlichen Hintergrund lesen willst, sondern deine bestehende Website technisch einordnen oder gezielt verbessern lassen möchtest: Barrierefreie Website prüfen oder planen \nHäufige Fragen \n“Betrifft mich das BFSG? Ich bin doch nur ein kleines Unternehmen.” \nWenn du unter 10 Mitarbeiter und unter 2 Millionen Euro Jahresumsatz hast, bist du von den BFSG-Dienstleistungspflichten befreit. Wenn du keine Produkte online verkaufst, sondern eine reine Info- oder Portfolio-Website betreibst, fällst du wahrscheinlich sowieso nicht unter das Gesetz. Wenn du unsicher bist, lässt sich das technisch und organisatorisch meistens schnell einordnen. \n“Warum sollte ich dann überhaupt etwas tun?” \nWeil Menschen deine Website sonst schlechter nutzen können. Weil saubere Struktur, gute Lesbarkeit und klare Bedienbarkeit auch für alle anderen hilfreich sind. Und weil viele der gleichen Maßnahmen zugleich die technische Qualität der Seite verbessern. \n“Reicht ein barrierefreies WordPress-Theme?” \nNein. Auch Themes, die als “accessible” beworben werden, sind oft nur teilweise barrierefrei. Sobald du eigene Inhalte, Plugins oder Anpassungen hinzufügst, können neue Barrieren entstehen. Ein gutes Theme ist ein Anfang, keine Garantie. \n“Kann ein Plugin oder Overlay meine Website barrierefrei machen?” \nNein. Es gibt Plugins und Overlays, die Barrierefreiheit per Knopfdruck versprechen. Experten und Interessenverbände warnen davor. Sie beheben nicht die eigentlichen Probleme im Code und können sogar neue Barrieren schaffen. Echte Barrierefreiheit erfordert Arbeit am Code und am Content. \n“Was kostet das?” \nDas hängt stark vom Ausgangszustand ab. Eine überschaubare Info-Seite ist etwas völlig anderes als ein Shop, ein Portal oder eine gewachsene Website mit vielen Sonderlösungen. Deshalb ist die erste sinnvolle Frage selten der Paketpreis, sondern der tatsächliche Zustand. \n“Muss ich jeden Alt-Text selbst schreiben?” \nAlt-Texte sollten sinnvoll und beschreibend sein. KI-generierte Alt-Texte können unterstützen, ersetzen aber nicht die manuelle Prüfung. Gerade bei inhaltlich wichtigen Bildern ist Kontext entscheidend.  \nDie Informationen in diesem Artikel basieren auf dem aktuellen Stand des European Accessibility Act (EAA) und des Barrierefreiheitsstärkungsgesetzes (BFSG). Sie ersetzen keine Rechtsberatung. Im Zweifelsfall solltest du einen Anwalt mit Schwerpunkt Digital- oder Verwaltungsrecht konsultieren."
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/blog/digitale-barrierefreiheit/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Startseite",
          "item": "https://contegus.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "BFSG 2025: Digitale Barrierefreiheit – Was wirklich gilt und warum es sich trotzdem lohnt"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/blog/dsgvo-agenturen-selbstcheck/#webpage",
      "url": "https://contegus.com/blog/dsgvo-agenturen-selbstcheck/",
      "name": "Ich habe 10 Webagenturen geprüft, die DSGVO-Konformität verkaufen. 7 hatten technische Befunde.",
      "description": "Ich habe 10 Agentur-Websites geprüft, die DSGVO-Konformität verkaufen. 7 luden Tracking oder externe Dienste schon vor der Einwilligung.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "dateModified": "2026-03-31T00:00:00.000Z",
      "breadcrumb": {
        "@id": "https://contegus.com/blog/dsgvo-agenturen-selbstcheck/#breadcrumb"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://contegus.com/blog/dsgvo-agenturen-selbstcheck/#article",
      "headline": "Ich habe 10 Webagenturen geprüft, die DSGVO-Konformität verkaufen. 7 hatten technische Befunde.",
      "description": "Ich habe 10 Agentur-Websites geprüft, die DSGVO-Konformität verkaufen. 7 luden Tracking oder externe Dienste schon vor der Einwilligung.",
      "mainEntityOfPage": {
        "@id": "https://contegus.com/blog/dsgvo-agenturen-selbstcheck/#webpage"
      },
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "datePublished": "2026-03-31T00:00:00.000Z",
      "dateModified": "2026-03-31T00:00:00.000Z",
      "author": {
        "@type": "Person",
        "name": "Kevin Kulik"
      },
      "articleBody": "Ich habe 10 Webagenturen geprüft, die DSGVO-Konformität verkaufen. 7 hatten technische Befunde. \n31.3.2026 · Kevin Kulik \n      \nDie Idee war simpel \nIch wollte wissen: Halten sich Webagenturen, die DSGVO-Konformität als Service verkaufen, eigentlich an ihre eigenen Standards? \nNicht mit einem Fragebogen. Nicht mit einem Scan-Tool. Sondern so, wie es ein Datenschutzbeauftragter oder eine Aufsichtsbehörde tun würde: Browser öffnen, DevTools aufmachen, schauen was passiert. Bevor ich auf irgendeinen Cookie-Banner klicke. \nWas ich geprüft habe \n10 Webagenturen aus NRW, die auf ihren Websites DSGVO, Datenschutz oder “rechtssichere Websites” als Leistung anbieten. Keine Exoten, keine Einmann-Hobbyisten. Etablierte Agenturen mit echten Kunden. \nFür jede Seite habe ich dokumentiert: \n \nWerden Tracking-Scripts geladen, bevor ich dem Cookie-Banner zustimme? \nWerden Cookies gesetzt, bevor ich irgendwas klicke? \nLaden externe Dienste (Google Fonts, Chat-Widgets, Analytics) Nutzerdaten ohne Einwilligung?  \nKein Hacking, kein Spezialwerkzeug. Nur ein Browser und die eingebauten Entwicklertools, die jeder kostenlos nutzen kann. \nDie Ergebnisse \n3 von 10 Agenturen waren sauber. Kein Tracking vor Consent, keine problematischen Cookies, keine externen Dienste vor Einwilligung. Respekt. \n7 von 10 Agenturen hatten technische Befunde. Bei mehreren davon ging es um Tracking oder externe Dienste vor Einwilligung. Hier die häufigsten Punkte: \nGoogle Analytics & Google Ads ohne Einwilligung \n \nMehrere Agenturen laden Google Analytics oder Google Ads Tracking, bevor der Besucher dem Cookie-Banner zustimmt. Bei einer Agentur waren es gleich drei Google-Tracking-Scripts parallel: ein veraltetes Universal Analytics und zwei GA4-Properties. Dazu Cookies wie _ga, _gid und _gcl_au, gesetzt beim ersten Seitenaufruf. \nEine andere Agentur hatte keinen sichtbaren Cookie-Banner, aber Google Ads und Google Analytics liefen trotzdem. Dazu ein Chat-Widget eines Drittanbieters. \nMatomo & HubSpot: “selbst gehostet” heißt nicht “erlaubt” \nZwei Agenturen nutzen Matomo, eine davon zusätzlich HubSpot. Selbst gehostetes Matomo ist datenschutzfreundlicher als Google Analytics, aber es ist nicht von der Einwilligungspflicht befreit, wenn es Cookies setzt oder personenbezogene Daten verarbeitet. Beide Agenturen laden Matomo vor dem Consent. \nConsent abgelehnt, Tracking läuft trotzdem \n \nBei einer Agentur, die einen 3.000-Wörter-Artikel über DSGVO-Konformität veröffentlicht hat, zeigte der Cookie-Tab: cmplz_marketing = deny. Der Besucher hat Marketing-Cookies abgelehnt. Trotzdem waren Drittanbieter-Cookies von einem Chat-Widget und einem Video-Dienst gesetzt. Komplett am Consent-Banner vorbei. \nExterne Dienste ohne Einwilligung \nGoogle Fonts von googleapis.com, Chat-Widgets von Drittanbietern, reCAPTCHA. Alles Dienste, die beim Laden die IP-Adresse des Besuchers an externe Server übermitteln. Ohne Einwilligung, ohne Hinweis. \nSSL-Zertifikat ungültig \nEine Agentur war schlicht nicht erreichbar. Das SSL-Zertifikat war ungültig, keine sichere Verbindung möglich. Bei einer Agentur, die Webdesign als Dienstleistung verkauft. \nWarum das ein Problem ist \nSeit dem EuGH-Urteil zu Google Fonts (LG München, Januar 2022) und den laufenden Entscheidungen der Datenschutzbehörden ist die Rechtslage klar: \n \nExterne Ressourcen die Nutzerdaten übermitteln, brauchen eine Einwilligung \nTracking-Cookies dürfen nicht vor der Einwilligung gesetzt werden \n“Berechtigtes Interesse” reicht für Marketing-Cookies nicht aus  \nDie Bußgelder der DSGVO liegen bei bis zu 20 Millionen Euro oder 4% des Jahresumsatzes. Realistischer sind Abmahnungen, die schnell vierstellig werden. \nWarum das relevant ist \nEs geht nicht darum, einzelne Anbieter anzugreifen. Fehler passieren. Konfigurationen veralten. Plugins ändern ihr Verhalten nach Updates. \nDer relevante Punkt ist: Bei mehreren geprüften Websites passten Leistungsversprechen und technische Umsetzung nicht zusammen. Wenn eine Website beim ersten Seitenaufruf Tracking-Cookies setzt, obwohl DSGVO-Konformität als Leistung angeboten wird, ist das ein Vertrauensproblem. \nWas du tun kannst \nWenn du selbst prüfen willst, ob deine Website betroffen ist: \n \nBrowser öffnen (Chrome oder Firefox) \nDevTools öffnen (F12) \nTab “Application” → Cookies: Sind dort schon Einträge, bevor du dem Banner zugestimmt hast? \nTab “Network”: Lade die Seite neu. Siehst du Anfragen an googletagmanager.com, google-analytics.com, fonts.googleapis.com oder andere externe Dienste? \nWenn ja: Diese Daten werden ohne deine Einwilligung übertragen.  \nSo sieht es aus wenn es richtig gemacht ist \n \n \nKeine externen Requests, keine Cookies, kein Tracking. Nicht vor der Einwilligung. Das ist kein Hexenwerk. Das ist Standard, wenn man es ernst meint. \nWenn du wissen willst, ob bei dir Consent, Tracking oder externe Dienste technisch sauber laufen, lässt sich das meist schnell einordnen: kleiner Fix, größeres technisches Thema oder Teil eines umfassenderen Website-Checks. \nConsent, Tracking und Anbieter-Claims technisch prüfen  \nAlle geprüften Agenturen wurden anonymisiert. Es geht nicht darum, einzelne Unternehmen bloßzustellen, sondern ein systematisches Problem sichtbar zu machen. Die Prüfungen wurden am 22. März 2026 durchgeführt."
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/blog/dsgvo-agenturen-selbstcheck/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Startseite",
          "item": "https://contegus.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Ich habe 10 Webagenturen geprüft, die DSGVO-Konformität verkaufen. 7 hatten technische Befunde."
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/blog/healthcare-chatbot-sicherheitsluecke/#webpage",
      "url": "https://contegus.com/blog/healthcare-chatbot-sicherheitsluecke/",
      "name": "Kritische Sicherheitslücke in Healthcare-Chatbot entdeckt",
      "description": "Bei einer Wartung fiel ein als HIPAA-konform beworbener Healthcare-Chatbot auf. Die Analyse zeigte eine kritische Schwachstelle mit Patientendaten-Risiko.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "dateModified": "2026-07-22T00:00:00.000Z",
      "breadcrumb": {
        "@id": "https://contegus.com/blog/healthcare-chatbot-sicherheitsluecke/#breadcrumb"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://contegus.com/blog/healthcare-chatbot-sicherheitsluecke/#article",
      "headline": "Kritische Sicherheitslücke in Healthcare-Chatbot entdeckt",
      "description": "Bei einer Wartung fiel ein als HIPAA-konform beworbener Healthcare-Chatbot auf. Die Analyse zeigte eine kritische Schwachstelle mit Patientendaten-Risiko.",
      "mainEntityOfPage": {
        "@id": "https://contegus.com/blog/healthcare-chatbot-sicherheitsluecke/#webpage"
      },
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "datePublished": "2026-02-01T00:00:00.000Z",
      "dateModified": "2026-07-22T00:00:00.000Z",
      "author": {
        "@type": "Person",
        "name": "Kevin Kulik"
      },
      "articleBody": "Kritische Sicherheitslücke in Healthcare-Chatbot entdeckt \n1.2.2026 · Kevin Kulik \nAktualisiert: 22.7.2026 \n      \nEs war ein ganz normaler Tag \nIch war dabei, die Website eines langjährigen Kunden zu warten – ein Unternehmen im US-amerikanischen Gesundheitswesen, das psychische Gesundheitsdienste anbietet. Alle Namen und identifizierenden Details sind bewusst anonymisiert. Routine-Updates. Plugin-Checks. Performance-Monitoring. Nichts Besonderes. \nDann fiel mir der Chatbot auf. \nEin kleines Widget in der unteren rechten Ecke der Website. “Sprechen Sie mit unserem virtuellen Assistenten” – ein KI-Chatbot, der Patienten bei der Terminbuchung und ersten Fragen unterstützt. Der Chatbot stammte von einem Drittanbieter, der sich als “HIPAA-konforme Enterprise-Healthcare-Chatbot-Lösung” vermarktet. \nHIPAA regelt in den USA den Schutz bestimmter Gesundheitsinformationen. Mein Kunde hatte den Anbieter unter anderem wegen dessen Compliance-Aussage gewählt. Ob ein konkretes System rechtlich konform ist, lässt sich aber nicht allein aus einem Anbieter-Label ableiten. \nIm vereinbarten technischen Kontext fiel die Integration auf, deshalb sah ich mir ihren ausgelieferten Code genauer an. \nDie Prüfung zeigte eine kritische Angriffskette. \nDie erste Entdeckung: Ein Schlüssel, der nicht hätte existieren dürfen \nWenn du JavaScript-Code analysierst, der von einer Website ausgeliefert wird, findest du oft obfuskierten Code – absichtlich unlesbar gemachten Code, der die Funktionsweise verschleiern soll. Das ist normal. Viele Anbieter tun das, um ihr geistiges Eigentum zu schützen. \nWas nicht normal ist: sensible Daten in diesem Code zu verstecken und zu hoffen, dass niemand hinschaut. \nIch fand einen AES-Schlüssel für die clientseitige Verschlüsselung. Direkt im JavaScript. Obfuskiert, aber extrahierbar. Mit diesem Schlüssel konnte ich entschlüsseln, was die Anwendung verschlüsselte. \nDas Problem: Diese “Verschlüsselung” war die einzige Sicherheitsebene zwischen der Außenwelt und… nun ja, allem. \nDie Kette bricht: Von einem Schlüssel zum vollen Zugriff \nMit dem extrahierten Schlüssel konnte ich: \n \n \nAPI-Token entschlüsseln und fälschen – Die Anwendung nutzte verschlüsselte Token für die API-Kommunikation. Mit dem Schlüssel konnte ich eigene Token erstellen.  \n \nAuf die Backend-API zugreifen – Die API hatte eine kritische Fehlkonfiguration: Sie akzeptierte Anfragen von jeder Quelle (CORS-Wildcard). Normalerweise sollte eine API nur Anfragen von autorisierten Domains akzeptieren.  \n \nCloud-Zugangsdaten extrahieren – Und hier wurde es wirklich kritisch. Die API lieferte verschlüsselte Zugangsdaten zurück. Mit dem Schlüssel konnte ich sie entschlüsseln: Ein vollständiger Service-Account-Schlüssel für die Cloud-Infrastruktur.   \nDamit waren Zugangsdaten zum Dialogflow-Agenten des Chatbots erreichbar. \nDie Tragweite: Was ein Angreifer hätte tun können \nBevor ich meinem Kunden Bericht erstattete, musste ich verstehen, wie schlimm es wirklich war. Ich ging daher tiefer in die Analyse – streng im Rahmen meiner Wartungsvereinbarung und nur um die Schwere einzuschätzen – und verifizierte, ob die Zugangsdaten funktionieren. \nSie funktionierten. \nErst als die Tragweite klar war, informierte ich meinen Kunden umgehend und stoppte weitere Tests. Es wurden keine Daten verändert, gelöscht oder exfiltriert. \nMit diesen Zugangsdaten hatte ich Zugriff auf: \nVollständige Lese- und Schreibrechte auf den Dialogflow-Agenten des Chatbots. Ich konnte die therapeutischen Antworten lesen, die der Chatbot an Patienten mit psychischen Problemen gab. Ich konnte diese Antworten verändern. \nEin Angreifer hätte: \n \nTherapeutische Ratschläge manipulieren können – Bei einem Chatbot, der Menschen mit Spielsucht, Angstzuständen oder Depressionen unterstützt \nKriseninterventions-Protokolle löschen können – Die Antworten bei Suizidgedanken einfach entfernen \nPatientendaten stehlen können – Trainingsdaten und Konversationslogs waren potenziell zugänglich \nDen gesamten Chatbot ersetzen können – Import-Funktion mit vollen Rechten  \nDie Schwachstelle war praktisch ausnutzbar und betraf einen sensiblen Anwendungskontext. Die Verifikation wurde deshalb nach Bestätigung der Tragweite beendet und unmittelbar eskaliert. \nWarum das besonders gefährlich ist \nIn einem E-Commerce-Shop könnte ein Angreifer Preise verändern oder Bestellungen manipulieren. Ärgerlich, teuer, juristisch unangenehm. Aber in einem Healthcare-Kontext geht es um Vertrauen und Sicherheit. Menschen öffnen sich einem Chatbot oft in einer verletzlichen Situation. Sie stellen Fragen, die sie vielleicht nicht einmal ihrem Arzt stellen würden. \nWenn Antworten manipulierbar sind, entsteht ein Risiko, das über Datenschutz weit hinausgeht. Es geht um Fehlberatung, eskalierende Krisen und das Gefühl: „Ich kann dieser Plattform nicht mehr trauen.” In der mentalen Gesundheitsversorgung kann dieser Vertrauensverlust reale Folgen haben. Genau deshalb war für mich sofort klar: Das ist nicht nur eine technische Schwachstelle, sondern ein Risiko für Patientensicherheit. \nWas ein beauftragter Review solcher Integrationen prüfen kann \nWenn Drittanbieter-Integrationen mit sensiblen Daten beauftragt geprüft werden, gehören je nach Scope unter anderem diese Bereiche dazu: \n \nClient-Side-Code: Wird etwas Sensibles im Browser ausgeliefert, das nicht dort sein sollte? \nToken-Handling: Sind Tokens statisch, leicht reproduzierbar oder im Frontend rekonstruierbar? \nCORS & Authentifizierung: Darf jede Domain auf die API zugreifen, oder gibt es klare Regeln? \nRückkanäle: Liefert die API Konfiguration, Schlüssel oder IDs zurück, die intern bleiben sollten? \nSession-Replay/Analytics: Zeichnet das System Eingaben auf? Sind Maskierungen aktiv? \nAbhängigkeiten: Sind zentrale Libraries veraltet oder EOL? Gibt es kritische CVEs? \nMarketing vs. Realität: Stimmen Datenschutzaussagen und Compliance-Claims mit dem Code überein?  \nDiese Checks sind kein Ersatz für eine vollständige Security-Analyse – aber sie reichen oft, um kritische Risiken früh zu entdecken. \nDie unbequeme Wahrheit über “HIPAA-konforme” Drittanbieter \nIch analysierte den Code weiter und fand: \n \n12+ bekannte Sicherheitslücken (CVEs) in veralteten Bibliotheken, darunter eine mit CVSS-Score 9.1 (kritisch) \nDrei End-of-Life-Frameworks – Software, die keine Sicherheitsupdates mehr erhält \nSession-Replay/Fehlertracking ohne Maskierung – Der Chatbot zeichnete 10% aller Patientensitzungen auf (bei Fehlern 100%) und übertrug sie an einen Drittanbieter-Session-Replay/Fehlertracking-Dienst. Patienteneingaben im Klartext. \nFalsche Datenschutzaussagen – Der Chatbot behauptete gegenüber Nutzern: “Ich speichere keine persönlichen Informationen oder Konversationshistorie.” Der Code zeigte das Gegenteil.  \nDer Anbieter bewarb sich als “HIPAA-konform”. Die technische Realität war das genaue Gegenteil. \nDie Meldung und die Eskalation \nAm 14. Januar 2026 meldete ich die Schwachstelle an meinen Kunden. Die E-Mail war sachlich, aber unmissverständlich: KRITISCH – SOFORTIGE AKTION ERFORDERLICH. \nDie Reaktion kam schnell. Mein Kunde informierte den Chatbot-Anbieter. Ein externer Sicherheitsdienstleister wurde hinzugezogen. Das Widget wurde serverseitig deaktiviert. Ich stellte zunächst eine redigierte Version des Reports bereit und bat für die vollständige Dokumentation um einen sicheren Übertragungsweg. \nKurze Timeline (vereinfacht) \n \nTag 0: Fund im Rahmen der Routine-Wartung \nTag 1: Meldung an den Kunden, formale Eskalation \nTag 1–2: Containment (Widget deaktiviert), Übergabe eines redigierten Reports \nWoche 1–2: Remediation beim Anbieter \nWoche 2: QA-Verifizierung der Maßnahmen  \nIn den folgenden Wochen arbeitete der Anbieter an der Behebung: \n \nZugangsdaten widerrufen und rotiert \nSensible Daten aus dem Frontend-Code entfernt \nCORS-Konfiguration korrigiert \nServerseitige Authentifizierung und Token-Handling implementiert \nServerseitige Verarbeitung statt Client-seitiger Entschlüsselung  \nZwei Wochen später erhielt ich die Nachricht: “Alle Änderungen implementiert. Können Sie die Behebung verifizieren?” \nIch führte eine vollständige QA durch. Die ursprüngliche Angriffskette war unterbrochen. Die kritischen Schwachstellen waren behoben. \nResponsible Disclosure: Warum ich redaktiert habe \nIn Sicherheitsvorfällen gilt: so viel wie nötig dokumentieren, aber so wenig wie möglich exponieren. Deshalb habe ich den Report anfangs nur redigiert geteilt – ohne Zugangsdaten oder sensible Details. Das schützt den Kunden, minimiert Missbrauchsrisiken und stellt sicher, dass die Behebung durch den Anbieter nicht unnötig gefährdet wird. Die vollständige technische Dokumentation habe ich erst über einen sicheren Übertragungsweg bereitgestellt. \nWas wäre gewesen, wenn… \nIch denke oft darüber nach, was hätte passieren können. \nWenn ich nicht neugierig gewesen wäre. Wenn ich nur die Updates installiert und die Performance gecheckt hätte, ohne mir den Chatbot genauer anzuschauen. \nWenn ein Angreifer zuerst dort gewesen wäre. Die Schwachstelle existierte seit der Installation des Chatbots. Monate, vielleicht Jahre. Jeder hätte sie finden können. \nWenn die Schwachstelle missbraucht worden wäre. Dann hätten technische, organisatorische und möglicherweise rechtliche Folgen geklärt werden müssen. Welche Pflichten und Kosten tatsächlich entstanden wären, lässt sich aus dem Fund allein nicht seriös beziffern. \nDer Fund wurde vor einem bekannten Missbrauch behoben. \nDie Lehren: Was du aus diesem Fall mitnehmen solltest \n1. “Konformität” ist kein Freifahrtschein \nEin Anbieter kann sich als HIPAA-konform, DSGVO-konform oder ISO-zertifiziert bezeichnen. Das bedeutet nicht automatisch, dass seine Software sicher ist. Zertifizierungen prüfen Prozesse und Richtlinien – nicht zwingend den tatsächlichen Code. \nFrage deinen Anbieter: Wann wurde der letzte Penetrationstest durchgeführt? Von wem? Können Sie die Ergebnisse teilen? \n2. Drittanbieter-Integrationen sind Einfallstore \nJedes Widget, jeder Chatbot, jede Integration, die du auf deiner Website einbindest, ist Code, den du nicht kontrollierst. Dieser Code kann Schwachstellen enthalten. Er kann Daten an Orte senden, von denen du nichts weißt. \nMeine Empfehlung: Lass Drittanbieter-Integrationen regelmäßig überprüfen – besonders wenn sie mit sensiblen Daten arbeiten. \n3. Routine-Wartung und Security-Review sind verschiedene Aufträge \nUpdates, Backups und Funktionschecks gehören zur laufenden Website-Betreuung. Eine gezielte Prüfung von Drittanbieter-Code, Authentifizierung und Datenflüssen ist dagegen ein eigener Security-Scope. Im beschriebenen Fall entstand dieser Scope aus einer konkreten Auffälligkeit und wurde entsprechend begrenzt. \nBetreiber brauchen deshalb eine aktuelle Übersicht der eingebundenen Dienste und eine klare Entscheidung, welche Integrationen nur betrieben und welche technisch geprüft werden sollen. \n4. Frühe Befunde schaffen eine bessere Entscheidungsgrundlage \nDer dokumentierte Befund ermöglichte Containment, Behebung und anschließende Verifikation. Einen hypothetisch vermiedenen Schaden oder Return on Investment leite ich daraus nicht ab. \nEin schneller Reality-Check für deine eigenen Integrationen \nWenn du Drittanbieter-Tools auf deiner Website nutzt, kannst du dir selbst ein paar einfache Fragen stellen – ganz ohne tiefes technisches Wissen: \n \nWelche Tools sind eingebunden? Hast du eine aktuelle Liste aller Widgets, Chatbots, Tracking-Tools? \nWelche Daten fließen durch sie? Werden Formulare, Chats oder Support-Anfragen erfasst? \nWas verspricht der Anbieter? Gibt es belastbare Nachweise (Audit-Bericht, Pen-Test, BAA)? \nWie aktuell ist die Technik? Werden veraltete Frameworks oder alte Bibliotheken genutzt? \nGibt es Monitoring ohne Maskierung? Session-Replay & Error-Tracking sind häufige Risiken.  \nWenn du bei zwei oder mehr Fragen unsicher bist, lohnt sich ein kurzer Security-Check. Viele Probleme lassen sich mit kleinen Änderungen entschärfen – bevor daraus ein Vorfall wird. \nWas der Fall belegt \nEin Compliance-Claim ersetzt keine technische Verifikation. In diesem Fall lagen sensible Schlüssel im Frontend, weitere Datenflüsse widersprachen der öffentlichen Aussage des Anbieters, und die Behebung musste anschließend im Produktivverhalten geprüft werden. Daraus folgt kein pauschales Urteil über alle Chatbots, sondern ein klarer Prüfgrund für sensible Integrationen.  \nNutzt du Drittanbieter-Integrationen auf deiner Website? \nChatbots, Buchungssysteme, Analytics-Tools und Marketing-Widgets erweitern den technischen und datenschutzrelevanten Scope einer Website. Bei sensiblen Daten sollte klar sein, welche Prüfung beauftragt ist und welche nicht. \nIch biete klar begrenzte technische Reviews für Drittanbieter-Integrationen an. Der vereinbarte Ausschnitt wird dokumentiert geprüft; formale Penetrationstests, Rechtsberatung und Zertifizierung bleiben getrennte Leistungen. \nDrittanbieter-Integration technisch prüfen lassen  \nDieser Artikel beschreibt einen realen, anonymisierten Fall aus meiner Arbeit. Er ersetzt weder einen formalen Penetrationstest noch eine rechtliche Compliance-Bewertung."
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/blog/healthcare-chatbot-sicherheitsluecke/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Startseite",
          "item": "https://contegus.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Kritische Sicherheitslücke in Healthcare-Chatbot entdeckt"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/blog/#webpage",
      "url": "https://contegus.com/blog/",
      "name": "Technik, die im Alltag zählt.",
      "description": "Eigene Untersuchungen und Checklisten zu Sicherheit, Datenschutz, Wartung, Performance, Barrierefreiheit und Website-Kosten.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/blog/website-kosten-professionell/#webpage",
      "url": "https://contegus.com/blog/website-kosten-professionell/",
      "name": "Warum eine günstige Website später teuer werden kann",
      "description": "Was Website-Kosten wirklich beeinflusst: Bestand, Inhalte, Technik, Übergabe und Wartung. Checkliste für einen fairen Angebotsvergleich.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "dateModified": "2026-07-14T00:00:00.000Z",
      "breadcrumb": {
        "@id": "https://contegus.com/blog/website-kosten-professionell/#breadcrumb"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://contegus.com/blog/website-kosten-professionell/#article",
      "headline": "Warum eine günstige Website später teuer werden kann",
      "description": "Was Website-Kosten wirklich beeinflusst: Bestand, Inhalte, Technik, Übergabe und Wartung. Checkliste für einen fairen Angebotsvergleich.",
      "mainEntityOfPage": {
        "@id": "https://contegus.com/blog/website-kosten-professionell/#webpage"
      },
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "datePublished": "2024-09-15T00:00:00.000Z",
      "dateModified": "2026-07-14T00:00:00.000Z",
      "author": {
        "@type": "Person",
        "name": "Kevin Kulik"
      },
      "articleBody": "Warum eine günstige Website später teuer werden kann \n15.9.2024 · Kevin Kulik \nAktualisiert: 14.7.2026 \n      \nEine Website für 500 Euro kann für einen kleinen, klaren Zweck völlig ausreichen. Eine Website für 5.000 Euro kann trotzdem schlecht geplant sein. Der Preis allein sagt wenig darüber aus, ob das Ergebnis zu deinem Betrieb passt. \nTeuer wird es meist dort, wo vor dem Start Dinge unklar bleiben: \n \nWelche Seiten und Funktionen sind wirklich enthalten? \nWer liefert Texte, Bilder und fachliche Freigaben? \nWem gehören Domain, Hosting und zentrale Konten? \nWie werden Formulare, Tracking und externe Dienste eingerichtet? \nWer prüft mobile Nutzung, Barrierefreiheit und technische Fehler? \nWas passiert nach dem Launch?  \nDie sinnvolle Frage lautet deshalb nicht nur: „Was kostet eine Website?“ Sie lautet: Welcher Zustand soll am Ende erreicht sein, und wer trägt dafür welche Verantwortung? \nWas den Preis einer Website beeinflusst \n1. Der Ausgangszustand \nEin Neubau ohne vorhandene Technik ist anders als ein Relaunch mit alter Domain, bestehenden Rankings, Formularen, Tracking und mehreren Dienstleistern. \nBei einer bestehenden Website muss zuerst geklärt werden: \n \nWelche Inhalte und URLs müssen erhalten bleiben? \nWelche Konten und Zugänge existieren? \nWelche externen Dienste sind eingebunden? \nGibt es Daten, Formulare oder Prozesse, die migriert werden müssen? \nIst die vorhandene Grundlage reparierbar oder wäre weiteres Flicken unwirtschaftlich?  \nWenn diese Fragen offen sind, ist ein pauschaler Website-Preis oft nur eine Annahme. \n2. Inhalt und Struktur \nFünf vorhandene, freigegebene Seiten sind ein anderer Aufwand als ein Angebot, das noch sortiert, geschrieben und mit Belegen unterfüttert werden muss. \nVor dem Angebot sollte klar sein: \n \nWelche Leistungen müssen erklärt werden? \nFür welche Zielgruppen oder Standorte? \nWelche Fragen sollen Besucher beantwortet bekommen? \nWelche Belege, Bilder und Zitate dürfen verwendet werden? \nWer gibt Inhalte fachlich frei?  \nEine klare Struktur spart nicht nur Umsetzungszeit. Sie verhindert auch, dass nach dem Launch wichtige Seiten oder Kontaktwege nachgebaut werden müssen. \n3. Technik und Funktionen \nEin Kontaktformular ist einfacher als ein Kundenportal. Ein überschaubarer Dienstleister-Auftritt ist einfacher als ein mehrsprachiger Produktkatalog. \nTypische Kostentreiber sind: \n \nMehrsprachigkeit \nTerminbuchung oder externe Integrationen \nindividuelle Formulare und Datenflüsse \nviele Inhalts- oder Produkttypen \nMigration bestehender Inhalte \nRollen und redaktionelle Workflows \nbesondere Anforderungen an Performance, Barrierefreiheit oder Sicherheit  \nNicht jede Website braucht all das. Ein gutes Angebot lässt unnötige Komplexität weg und benennt notwendige Komplexität vor dem Start. \n4. Qualitätssicherung und Launch \n„Die Seite ist gebaut“ ist nicht dasselbe wie „die Seite kann sauber live gehen“. \nZum Launch gehören je nach Projekt unter anderem: \n \nPrüfung auf mobilen Größen und in relevanten Browsern \nTastaturbedienung, Fokus und Formularzustände \ninterne Links, Weiterleitungen und Fehlerseiten \nMeta-Daten, Canonical, Sitemap und Indexierung \nPerformance und horizontale Überläufe \nÜbergabe von Domain, Konten und Dokumentation  \nWelche Prüfungen enthalten sind, sollte im Angebot stehen. Vollständige Sicherheit, feste Rankings oder rechtliche Konformität lassen sich dadurch nicht garantieren. \n5. Betrieb nach dem Launch \nAuch eine technisch saubere Website braucht eine geklärte Zuständigkeit. Das bedeutet nicht automatisch einen Wartungsvertrag. \nMögliche Modelle sind: \n \nDer Kunde übernimmt Inhalte und Betrieb selbst. \nEin bestehender Dienstleister übernimmt die fertige Website. \nUpdates, Backups und kleine Pflegearbeiten werden separat vereinbart. \nGrößere Änderungen bleiben eigene Projekte.  \nWichtig ist, dass Zugänge, Eigentum und Übergabe nicht erst am letzten Projekttag besprochen werden. \nReparieren, übernehmen oder neu bauen? \nEin Neubau ist nicht automatisch die beste Antwort. \nReparieren kann wirtschaftlicher sein, wenn: \n \ndie technische Grundlage noch gepflegt werden kann, \nStruktur und Inhalte im Kern passen, \ndie Probleme auf wenige Bereiche begrenzt sind, \nZugänge und Zuständigkeiten geklärt werden können.  \nEin Neubau wird realistischer, wenn: \n \ndas System nicht mehr sicher oder zuverlässig wartbar ist, \njede kleine Änderung neue Nebenprobleme erzeugt, \nStruktur, Inhalte und Technik gleichzeitig neu gedacht werden müssen, \neine Übernahme mehr Aufwand erzeugen würde als ein sauberer Neustart.  \nWenn die Antwort nicht klar ist, sollte vor dem Website-Projekt erst der Zustand geprüft werden. \nSo vergleichst du zwei Angebote \nLege nicht nur die Endsumme nebeneinander. Prüfe für jedes Angebot: \n \nErgebnis: Welche Seiten, Funktionen und Übergaben stehen am Ende? \nMitwirkung: Was musst du selbst liefern und bis wann? \nGrenzen: Was ist ausdrücklich nicht enthalten? \nKonten: Auf wessen Namen laufen Domain, Hosting, Tracking und Profile? \nQualitätssicherung: Was wird vor dem Launch geprüft? \nMigration: Welche URLs, Inhalte und Daten werden übernommen? \nNach dem Launch: Wer ist wofür zuständig? \nZusatzarbeit: Wie werden neue Anforderungen freigegeben und berechnet?  \nEin niedriger Preis mit engem, ehrlichem Scope kann gut sein. Problematisch ist ein niedriger Preis mit großen, unklaren Versprechen. \nWas ich bei einem Website-Projekt festhalte \nVor dem Start werden mindestens diese Punkte geklärt: \n \nZiel und Seitenumfang \nenthaltene Funktionen \nbenötigte Inhalte und Freigaben \ntechnische Plattform und externe Dienste \nZuständigkeit für Domain und Konten \nQualitätsprüfungen vor dem Launch \nÜbergabe und mögliche laufende Betreuung \nAusschlüsse und Umgang mit Zusatzarbeit  \nDas macht ein Projekt nicht automatisch erfolgreich. Es macht aber sichtbar, worüber beide Seiten tatsächlich sprechen. \nHäufige Fragen \nWas kostet eine professionelle Website? \nDas hängt von Ausgangszustand, Seitenumfang, Inhalten, Funktionen, Migration und gewünschter Übergabe ab. Eine belastbare Zahl braucht einen konkreten Scope. \nKann ich meine Website selbst bauen? \nJa. Für einen kleinen, klaren Zweck kann das gut funktionieren. Entscheidend ist, ob du auch Konten, Formulare, Datenschutz-Basis, technische Pflege und spätere Änderungen selbst verantworten möchtest. \nIst WordPress besser als ein statisches System? \nNicht pauschal. WordPress kann sinnvoll sein, wenn Inhalte regelmäßig selbst gepflegt werden. Ein statisches System kann besser passen, wenn die Website schlank und wartungsarm bleiben soll. Die Technik folgt dem Betriebsmodell. \nKann eine neue Website mehr Anfragen oder bessere Rankings garantieren? \nNein. Eine Website kann Angebot, Kontaktwege und technische Suchgrundlage verbessern. Nachfrage, Wettbewerb, Vertrauen, Inhalte und weitere Marktbedingungen bleiben eigenständige Faktoren. \nDer nächste Schritt \nWenn bereits klar ist, dass du einen Neubau oder Relaunch brauchst, lässt sich das Website-Projekt direkt abgrenzen. \nWebsite-Projekt einordnen \nWenn noch unklar ist, ob Reparatur, Übernahme oder Neubau sinnvoll ist, sollte zuerst der Bestand geprüft werden. \nTechnische Bestandsaufnahme ansehen"
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/blog/website-kosten-professionell/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Startseite",
          "item": "https://contegus.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Warum eine günstige Website später teuer werden kann"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/blog/website-langsam-was-tun/#webpage",
      "url": "https://contegus.com/blog/website-langsam-was-tun/",
      "name": "Website lädt langsam: Was wirklich bremst",
      "description": "Website lädt langsam: Bilder, Hosting, Theme, Plugins, Tracking, Fonts und Core Web Vitals prüfen. Wann Optimierung oder Neubau sinnvoll ist.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "dateModified": "2026-05-26T00:00:00.000Z",
      "breadcrumb": {
        "@id": "https://contegus.com/blog/website-langsam-was-tun/#breadcrumb"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://contegus.com/blog/website-langsam-was-tun/#article",
      "headline": "Website lädt langsam: Was wirklich bremst",
      "description": "Website lädt langsam: Bilder, Hosting, Theme, Plugins, Tracking, Fonts und Core Web Vitals prüfen. Wann Optimierung oder Neubau sinnvoll ist.",
      "mainEntityOfPage": {
        "@id": "https://contegus.com/blog/website-langsam-was-tun/#webpage"
      },
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "datePublished": "2026-05-26T00:00:00.000Z",
      "dateModified": "2026-05-26T00:00:00.000Z",
      "author": {
        "@type": "Person",
        "name": "Kevin Kulik"
      },
      "articleBody": "Website lädt langsam: Was wirklich bremst \n26.5.2026 · Kevin Kulik \n      \nWenn eine Website langsam lädt, ist das selten ein einzelnes Problem. Meist kommen mehrere kleine Bremsen zusammen: zu große Bilder, schwaches Hosting, aufgeblähte Themes, zu viele Plugins, Tracking-Skripte, externe Fonts oder ein Cache, der nicht richtig arbeitet. \nEin Speed-Test kann Hinweise liefern. Die eigentliche Frage ist aber: Was bremst deine Website wirklich, und lohnt sich Optimierung noch? \nErst klären: Ist sie wirklich langsam? \nManchmal fühlt sich eine Website nur langsam an, weil sie auf dem eigenen Gerät aus dem Cache geladen wird oder weil einzelne Unterseiten schwerer sind als andere. Prüfe deshalb nicht nur die Startseite. \nSinnvoll sind: \n \nStartseite \nwichtigste Leistungsseite \nKontaktseite \nBlogartikel oder Ratgeber mit Bildern \nmobile Ansicht  \nPageSpeed Insights, Lighthouse oder WebPageTest können helfen. Wichtig ist aber, die Werte nicht isoliert zu betrachten. Ein roter Score erklärt noch nicht, welches Problem geschäftlich zuerst gelöst werden sollte. \nUnd wenn die Seite nicht langsam ist, sondern seit einem bestimmten Zeitpunkt gar nicht mehr richtig lädt, ist das kein Performance-Thema. Dann geht es um einen Fehler nach einem Update oder, wenn fremde Inhalte auftauchen, um eine gehackte Seite. \nHäufige Ursache 1: Bilder \nBilder sind oft der größte Bremsklotz. Typische Probleme: \n \nOriginalfotos werden direkt hochgeladen. \nBilder sind viel größer als die Anzeigegröße. \nAlte Formate statt WebP oder AVIF. \nKeine responsive Auslieferung. \nHero-Bilder sind zu schwer.  \nGerade bei WordPress-Websites sammeln sich über Jahre große Uploads an. Ein einzelnes 4-MB-Bild im sichtbaren Bereich kann reichen, damit die Seite auf Mobilgeräten zäh wirkt. \nHäufige Ursache 2: Hosting \nBilliges oder überlastetes Hosting kann jede Optimierung ausbremsen. Wenn der Server lange braucht, bevor überhaupt HTML ausgeliefert wird, helfen komprimierte Bilder nur begrenzt. \nHinweise auf Hosting-Probleme: \n \nhohe Time to First Byte \nstark schwankende Ladezeiten \nlangsames WordPress-Backend \nAussetzer bei Formularen oder Cronjobs \nviele Websites auf demselben Shared-Hosting-Paket  \nDann ist die Frage nicht nur “Cache aktivieren?”, sondern ob die Grundlage tragfähig ist. \nHäufige Ursache 3: Theme und Page Builder \nViele WordPress-Themes und Page Builder laden viel Code, auch wenn nur ein kleiner Teil gebraucht wird. Das ist bequem beim Aufbau, kann aber langfristig teuer werden. \nTypische Symptome: \n \nviele CSS- und JavaScript-Dateien \nungenutzte Slider, Animationen oder Icon-Sets \nLayout-Verschiebungen beim Laden \nlangsame mobile Bedienung \nschwer wartbare Templates  \nHier muss man sauber unterscheiden: Lässt sich die bestehende Website sinnvoll entschlacken, oder ist das System selbst der Flaschenhals? \nHäufige Ursache 4: Plugins \nPlugins sind nicht automatisch schlecht. Aber jedes Plugin bringt Code, Datenbankabfragen, Updates und potenzielle Konflikte mit. \nBesonders kritisch sind: \n \nmehrere Formular- oder Builder-Plugins parallel \nSecurity-Plugins mit schwerer Laufzeitlast \nschlecht konfigurierte Cache-Plugins \nalte Plugins ohne Wartung \nMarketing-Plugins, die viele externe Skripte laden  \nBei WordPress ist Performance deshalb eng mit Wartung verbunden. Wer nie aufräumt, wird irgendwann langsamer. \nHäufige Ursache 5: Tracking, Fonts und Drittanbieter \nAnalytics, Ads, Chat-Widgets, Cookie-Banner, Karten, Bewertungswidgets, externe Fonts: Jede Integration kann Ladezeit kosten. Manche Skripte blockieren den Aufbau, andere erzeugen Datenschutz- oder Consent-Probleme. \nPrüfe: \n \nWelche Drittanbieter laden beim ersten Seitenaufruf? \nLäuft Tracking erst nach Einwilligung? \nWerden Fonts lokal oder extern geladen? \nSind Chat-Widgets wirklich nötig? \nGibt es alte Tags im Google Tag Manager?  \nPerformance, Datenschutz und Vertrauen hängen hier oft zusammen. \nWas du selbst schnell prüfen kannst \nOhne tiefes Technik-Wissen kannst du eine erste Bestandsaufnahme machen: \n \nPageSpeed Insights für Startseite und wichtigste Unterseite öffnen. \nPrüfen, ob Bilder als Hauptproblem auftauchen. \nIm WordPress-Backend Plugin-Liste anschauen: Was ist aktiv, aber unklar? \nWebsite mobil aufrufen: Springt das Layout, verschieben sich Buttons? \nKontaktformular testen: Kommt die E-Mail wirklich an? \nBrowser-DevTools Network öffnen: Wie viele externe Domains laden?  \nWenn schon diese Punkte unklar sind, ist ein manueller Check meistens sinnvoller als das nächste Optimierungsplugin. \nWann Optimierung reicht \nOptimierung kann reichen, wenn: \n \ndie Website strukturell noch gut ist \nHosting und CMS tragfähig sind \nnur Bilder, Cache oder einzelne Skripte bremsen \nkeine größeren Sicherheits- oder Wartungsprobleme sichtbar sind \ndie Inhalte und Seitenstruktur noch passen  \nDann kann gezieltes Aufräumen viel bringen. \nWann ein Neubau wirtschaftlicher ist \nEin Neubau wird realistischer, wenn: \n \nTheme und Page Builder dauerhaft bremsen \ndie Website auch inhaltlich veraltet ist \nPlugins nicht mehr sauber wartbar sind \nmobile Darstellung und Barrierefreiheit schwach sind \nSEO-Struktur, Kontaktwege und Technik gleichzeitig nicht passen \njede Reparatur neue Nebenprobleme erzeugt  \nDann ist “Performance-Optimierung” oft nur ein anderes Wort für Flickarbeit. \nDie sinnvolle Reihenfolge \nWenn deine Website langsam ist, geh nicht direkt in Aktionismus: \n \nZustand prüfen. \nHauptbremsen identifizieren. \nTechnische Risiken einordnen. \nEntscheiden: optimieren, warten, bereinigen oder neu bauen. \nDanach erst umsetzen.  \nSo vermeidest du, Geld in eine Grundlage zu stecken, die ohnehin nicht mehr trägt. \nTechnische Bestandsaufnahme ansehen \nWenn klar ist, dass die bestehende Website technisch am Ende ist, ist der nächste Schritt kein weiteres Speed-Plugin, sondern ein sauber geplanter Neubau. \nWebsite erstellen lassen: Neubau einordnen"
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/blog/website-langsam-was-tun/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Startseite",
          "item": "https://contegus.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Website lädt langsam: Was wirklich bremst"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/blog/website-wartung-investition/#webpage",
      "url": "https://contegus.com/blog/website-wartung-investition/",
      "name": "Website-Wartung: Warum 'läuft doch' teuer wird",
      "description": "Warum regelmäßige Website-Wartung keine unnötige Ausgabe ist: Updates, Backups, Sicherheit und die Kosten, wenn 'läuft doch' plötzlich kippt.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "dateModified": "2026-07-22T00:00:00.000Z",
      "breadcrumb": {
        "@id": "https://contegus.com/blog/website-wartung-investition/#breadcrumb"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://contegus.com/blog/website-wartung-investition/#article",
      "headline": "Website-Wartung: Warum 'läuft doch' teuer wird",
      "description": "Warum regelmäßige Website-Wartung keine unnötige Ausgabe ist: Updates, Backups, Sicherheit und die Kosten, wenn 'läuft doch' plötzlich kippt.",
      "mainEntityOfPage": {
        "@id": "https://contegus.com/blog/website-wartung-investition/#webpage"
      },
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "datePublished": "2025-01-22T00:00:00.000Z",
      "dateModified": "2026-07-22T00:00:00.000Z",
      "author": {
        "@type": "Person",
        "name": "Kevin Kulik"
      },
      "articleBody": "Website-Wartung: Warum 'läuft doch' teuer wird \n22.1.2025 · Kevin Kulik \nAktualisiert: 22.7.2026 \n      \nWas ohne klare Zuständigkeit unbemerkt bleibt \nNehmen wir einen zusammengesetzten Fall aus Situationen, die mir regelmäßig begegnen: Ein kleiner Online-Shop läuft im Alltag unauffällig. Updates wurden seit Monaten nicht geprüft. Der Betreiber geht davon aus, dass der Hoster die Backups übernimmt. Eine benannte technische Zuständigkeit gibt es nicht. \nAls die Website ausfällt, zeigt sich, dass Schadcode eingeschleust wurde und das automatische Backup seit Monaten nicht mehr zuverlässig lief. Die Bereinigung wird dadurch aufwendiger, und für die Wiederherstellung fehlt ein verlässlich getesteter Stand. \nWelche Kosten daraus entstehen, hängt vom System, vom Vorfall und vom Geschäft ab. Belastbar ist nur: Ohne funktionierendes Backup, Dokumentation und klare Zuständigkeit dauert die Wiederherstellung meist länger als bei einem gepflegten Setup. \nDie Details unterscheiden sich. Das wiederkehrende Muster ist fehlende Verantwortung: Niemand prüft Updates, Wiederherstellbarkeit und zentrale Funktionen in einem vereinbarten Rhythmus. Dieser Artikel erklärt, welche Aufgaben laufende Betreuung abdecken kann und wo ein eigener Prüf- oder Projektumfang nötig wird. \nWarum “läuft doch” eine gefährliche Illusion ist \nEine Website ist keine Broschüre, die du einmal drucken lässt und dann jahrelang nutzt. Sie ist ein dynamisches System – Software, die auf einem Server läuft, mit anderen Systemen interagiert und ständigen Veränderungen ausgesetzt ist. Und wie jedes System braucht sie regelmäßige Pflege. \nDas Problem: Wenn deine Website heute funktioniert, sieht es so aus, als wäre alles in Ordnung. Du siehst nicht, dass im Hintergrund veraltete Software läuft. Du merkst nicht, dass dein letztes Backup seit Wochen fehlschlägt. Du bemerkst nicht, dass eine bekannte Sicherheitslücke in einem deiner Plugins seit Monaten darauf wartet, ausgenutzt zu werden. \nDas stille Risiko: Sicherheitslücken \nWordPress-Websites werden laufend automatisiert angegriffen. Die häufigste Ursache sind veraltete Komponenten. Ein veraltetes WordPress-Core, ein nicht aktualisiertes Plugin oder ein Theme mit bekannten Schwachstellen sind offene Türen für Angreifer. \nSicherheitslücken werden laufend entdeckt und über Updates geschlossen. Bleiben bekannte Schwachstellen offen, können automatisierte Scans sie finden. Dafür muss eine Website kein gezielt ausgewähltes Angriffsziel sein. \nMögliche Folgen reichen von Spam-Inhalten und Weiterleitungen bis zu unbefugtem Zugriff auf Daten. Welche Melde- oder Informationspflichten daraus entstehen, muss im konkreten Vorfall rechtlich und organisatorisch bewertet werden. \nDie unsichtbare Gefahr: Fehlende Backups \nBackups schaffen einen Wiederherstellungspunkt. Wenn bei einem Update, Serverfehler oder Sicherheitsvorfall etwas schiefgeht, hängt die weitere Arbeit davon ab, ob ein aktueller und geprüfter Stand vorhanden ist. \nViele denken: “Mein Hoster macht doch Backups.” Das stimmt oft – aber nicht immer. Und selbst wenn der Hoster Backups macht, heißt das nicht, dass sie funktionieren. Backups können fehlschlagen. Sie können unvollständig sein. Sie können zu alt sein, um nützlich zu sein. \nIm Beispiel oben fiel das fehlerhafte Backup erst beim Ausfall auf. Genau deshalb gehört nicht nur das Erstellen, sondern auch die kontrollierte Wiederherstellung in einen belastbaren Backup-Prozess. \nDie schleichende Verschlechterung: Performance \nWebsites werden mit der Zeit langsamer. Datenbanken sammeln Müll an. Plugins werden aufgebläht. Caches funktionieren nicht mehr richtig. Bilder werden nicht mehr optimal ausgeliefert. Jedes dieser Probleme für sich ist klein – aber zusammen können sie deine Ladezeit von zwei auf fünf Sekunden erhöhen. \nUnd das kostet dich Geld. Langsame Websites verlieren oft Sichtbarkeit, Vertrauen und Anfragen. Wenn Ladezeiten kippen, springen Menschen ab, bevor sie überhaupt verstehen, worum es auf der Seite geht. \nDu merkst diese Verschlechterung oft nicht, weil sie schleichend passiert. Aber deine Kunden merken es – und sie gehen zur Konkurrenz. \nDas schleichende Problem: Kompatibilität \nDie digitale Welt entwickelt sich weiter. PHP-Versionen werden aktualisiert. Browser ändern ihre Standards. Hosting-Umgebungen werden modernisiert. Wenn deine Website nicht mitwächst, wird sie irgendwann inkompatibel. \nVielleicht läuft deine Website noch auf PHP 7.4 – eine Version, die seit November 2022 keine Sicherheitsupdates mehr erhält. Vielleicht nutzt du Plugins, die nicht mehr mit der neuesten WordPress-Version kompatibel sind. Vielleicht basiert dein Theme auf veralteten Standards, die moderne Browser nicht mehr richtig unterstützen. \nDas Ergebnis: Irgendwann geht etwas kaputt. Nicht weil du etwas geändert hast, sondern weil sich die Umgebung geändert hat. Und dann stehst du vor der Wahl: Notfall-Reparatur unter Zeitdruck – oder gleich ein kompletter Neubau, weil das alte System nicht mehr zu retten ist. \nWas professionelle Website-Wartung wirklich umfasst \nWartung ist mehr als gelegentliches Klicken auf den Update-Button. Es ist ein systematischer Prozess, der sicherstellt, dass deine Website sicher, schnell und zuverlässig bleibt. Lass uns die einzelnen Bausteine durchgehen. \nRegelmäßige Software-Updates – aber richtig \nDas Herzstück jeder Wartung sind Updates. WordPress selbst, dein Theme, alle Plugins – all diese Komponenten erhalten regelmäßig Updates. Manche schließen Sicherheitslücken. Andere beheben Fehler. Wieder andere verbessern die Kompatibilität mit neuen Technologien. \nKlingt einfach: Klick auf Update, fertig. Aber ganz so simpel ist es nicht. \nErstens: Updates können etwas kaputt machen. Ein Plugin-Update ist nicht kompatibel mit deinem Theme. Ein WordPress-Update bricht eine Custom-Funktion. Ein Theme-Update überschreibt Anpassungen. Professionelle Wartung bedeutet, Updates in einer Testumgebung zu prüfen, bevor sie auf der Live-Site installiert werden. Funktioniert alles noch? Sieht die Seite noch richtig aus? Nur wenn die Antwort ja ist, geht das Update live. \nZweitens: Nicht alle Updates sind gleich dringend. Kritische Sicherheits-Updates sollten zeitnah geprüft und eingespielt werden. Ein kleines Feature-Update für ein nebensächliches Plugin kann oft warten. Professionelle Wartung bedeutet, Prioritäten zu setzen und nicht alles gleich zu behandeln. \nDrittens: Updates müssen dokumentiert werden. Was wurde wann aktualisiert? Gab es Probleme? Was wurde gelöst? Diese Dokumentation ist Gold wert, wenn später etwas schiefgeht und du verstehen musst, was sich geändert hat. \nZuverlässige Backups – und regelmäßige Tests \nBackups sind deine letzte Verteidigungslinie. Aber ein Backup zu haben ist nicht genug – du musst wissen, dass es funktioniert. \nProfessionelle Wartung bedeutet: \nAutomatisierte, regelmäßige Backups. Nicht einmal im Monat, sondern täglich oder zumindest wöchentlich, je nachdem, wie oft sich deine Inhalte ändern. Datenbank und Dateien, vollständig. \nExterne Speicherung. Backups auf demselben Server, auf dem deine Website läuft, sind nutzlos, wenn der Server ausfällt oder kompromittiert wird. Backups gehören auf einen separaten, sicheren Speicher – idealerweise an mehreren Orten. \nRegelmäßige Tests. Ein Backup, das noch nie wiederhergestellt wurde, ist kein Backup – es ist Hoffnung. Professionelle Wartung beinhaltet regelmäßige Wiederherstellungs-Tests. Funktioniert das Backup? Ist es vollständig? Wie lange dauert die Wiederherstellung? Diese Fragen sollten beantwortet sein, bevor der Notfall eintritt. \nVersionierung. Was ist, wenn du erst eine Woche später merkst, dass etwas kaputt ist? Du brauchst nicht nur das Backup von gestern, sondern auch die von vor einer Woche, einem Monat. Mehrere Wiederherstellungspunkte geben dir Flexibilität. \nSicherheitschecks statt blinder Beruhigung \nNicht jede Website braucht laufendes Security-Monitoring. Aber jede Website braucht Klarheit darüber, wer sicherheitsrelevante Updates einspielt, Backups prüft und bei Auffälligkeiten Verantwortung übernimmt. \nIm Alltag heißt das meist: \nSicherheitsrelevante Updates priorisieren. Kritische Lücken sollten nicht wochenlang liegen bleiben, nur weil gerade niemand zuständig ist. \nBackups und zentrale Funktionen gegenprüfen. Ein Backup, das nie getestet wurde, ist nur Hoffnung. Dasselbe gilt für Formulare, Logins oder Shops, die nach einem Update plötzlich nicht mehr sauber laufen. \nUnnötige Angriffsfläche reduzieren. Alte Plugins, fragwürdige Integrationen und halb vergessene Tools sind oft das eigentliche Risiko, nicht die sichtbare Oberfläche. \nAuffälligkeiten technisch einordnen. Wenn Spam auftaucht, Dateien sich verändern oder ein Drittanbieter merkwürdig arbeitet, muss jemand unterscheiden können zwischen Routineproblem, Bereinigung und echter Eskalation. \nWenn es um Vendor Reviews, Privacy-/Security-Prüfungen oder einen echten Vorfall geht, ist das nicht einfach “in der Wartung mit drin”. Das ist ein eigener technischer Arbeitsschritt. \nPerformance-Überwachung – Schnell bleiben, nicht langsam werden \nEine schnelle Website ist essenziell für Nutzerzufriedenheit und Google-Ranking. Wartung bedeutet, die Performance im Blick zu behalten. \nRegelmäßige Ladezeit-Checks. Wie schnell lädt deine Startseite? Wie schnell deine wichtigsten Unterseiten? Tools wie GTmetrix, PageSpeed Insights oder Pingdom geben dir objektive Zahlen. \nDatenbank-Optimierung. Über die Zeit sammelt die WordPress-Datenbank Müll an: Post-Revisionen, Spam-Kommentare, verwaiste Metadaten. Eine regelmäßige Bereinigung hält die Datenbank schlank und die Abfragen schnell. \nCache-Management. Caching ist eine der effektivsten Methoden, um Websites zu beschleunigen. Aber Caches müssen konfiguriert, überwacht und gelegentlich geleert werden, damit sie richtig funktionieren. \nBild-Optimierung. Neue Bilder, die du hochlädst, sollten automatisch komprimiert und im richtigen Format ausgeliefert werden. Professionelle Wartung stellt sicher, dass diese Automatisierung läuft. \nFunktionsprüfungen – Sicherstellen, dass alles funktioniert \nNach Updates, in regelmäßigen Abständen oder bei Verdacht auf Probleme sollten zentrale Funktionen getestet werden: \nFormulare: Funktioniert das Kontaktformular? Kommen E-Mails an? Ist die DSGVO-Einwilligung korrekt implementiert? \nE-Commerce: Kann man Produkte in den Warenkorb legen? Funktioniert der Checkout? Werden Zahlungen korrekt verarbeitet? \nLinks: Gibt es kaputte Links auf der Seite? Tote interne Links schaden der SEO. Tote externe Links frustrieren Nutzer. \nLogin und Berechtigungen: Können sich Nutzer anmelden? Funktionieren Mitgliederbereiche? Sind die Berechtigungen korrekt gesetzt? \nDiese Checks verhindern, dass kleine Fehler unbemerkt bleiben und zu großen Problemen werden. \nWarum “ich mach das selbst” oft teurer wird \nViele Unternehmer überlegen: Kann ich die Wartung nicht selbst übernehmen? Schließlich sind Updates doch nur ein Klick, oder? \nJa, technisch gesehen kannst du Updates selbst installieren. Du kannst auch lernen, Backups zu erstellen, Sicherheits-Scans durchzuführen und Performance zu optimieren. Die Frage ist: Solltest du? \nDer Zeitfaktor: Wer übernimmt die Aufgabe zuverlässig? \nWie viel Zeit Wartung braucht, hängt stark von System, Änderungsfrequenz und Risiko ab. Entscheidend ist weniger eine pauschale Stundenzahl als die Frage, ob Updates, Backups, Funktionsprüfungen und Dokumentation tatsächlich regelmäßig erledigt werden. \nWer diese Aufgaben intern übernimmt, braucht dafür Zeit, Zugriff und genug Routine für Fehlerfälle. Wer sie extern vergibt, braucht einen klaren Leistungsrahmen. In beiden Fällen sollte benannt sein, wer prüft, dokumentiert und bei Problemen entscheidet. \nDas Wissens-Problem: Du weißt nicht, was du nicht weißt \nWartung ist nicht nur Arbeit, sondern auch Expertise. Du musst verstehen, wie WordPress funktioniert. Du musst wissen, welche Updates sicher sind und welche Probleme verursachen könnten. Du musst erkennen, wenn etwas verdächtig aussieht. Du musst im Notfall schnell und richtig reagieren. \nAll das zu lernen kostet Zeit. Und selbst dann: Machst du das täglich, entwickelst du Routine. Machst du es gelegentlich, vergisst du die Details. Ein Profi, der Dutzende Websites wartet, sieht Muster, die dir entgehen. Er weiß, welches Plugin notorisch Probleme macht. Er erkennt die Symptome eines Hacks, bevor es offensichtlich ist. \nDas Risiko: Wenn etwas schiefgeht \nDu installierst ein Update. Die Website ist kaputt. Was nun? Du hast kein Backup. Oder du hast eins, aber weißt nicht genau, wie man es wiederherstellt. Oder die Wiederherstellung klappt nicht, weil das Backup unvollständig war. \nIst die Website nach einem Update offline, braucht es einen nachvollziehbaren Rückweg. Ohne getestetes Backup und Dokumentation wird aus einer Routineaufgabe schnell eine ungeplante Bereinigung. \nIm zusammengesetzten Beispiel wäre die Lage mit einem geprüften Backup und benannter Zuständigkeit leichter einzugrenzen gewesen. Der relevante Vergleich ist nicht eine erfundene Schadenssumme, sondern die Reaktionsfähigkeit des tatsächlichen Setups. \nWarum sich Betreuung nicht sinnvoll als Paketpreis erklären lässt \nViele Anbieter verkaufen “Wartung” wie ein starres Abo. Das Problem: Unter diesem einen Wort landen plötzlich völlig verschiedene Dinge. \nRoutine-Support ist etwas anderes als Projektarbeit \nZu laufender Betreuung gehören typischerweise Updates, Backups, Funktionschecks und kleine technische Aufgaben, die regelmäßig anfallen. \nWenn aber ein Formularsystem ersetzt, ein Theme aufgeräumt, ein Relaunch vorbereitet oder ein kompletter Bereich neu gebaut werden muss, ist das keine Routine-Wartung mehr. Das ist Projektarbeit. \nTechnische Sonderfälle sind ebenfalls eine eigene Kategorie \nSecurity-Prüfungen, Vendor Reviews, DSGVO-Fragen, Vorfälle, Datenflüsse oder Go-live-Risiken entstehen oft aus einem scheinbaren Wartungsthema heraus. Trotzdem sind sie kein unsichtbarer Gratis-Anteil eines kleinen Retainers, sondern eine eigene Wert- und Arbeitskategorie. \nDie bessere Frage ist deshalb nicht: “Was kostet Wartung pro Monat?” \nSondern: \n \nWas fällt bei dir wirklich laufend an? \nWas ist nur aufgeschobene Bereinigung? \nWo endet Routine und wo beginnt Projekt- oder Oversight-Arbeit?  \nErst danach lässt sich sauber sagen, was laufende Betreuung ist und was separat scoped werden sollte. \nWas Betreuung dir tatsächlich spart \nNicht jeder Monat produziert einen sichtbaren Aha-Effekt. Aber Betreuung reduziert die Wahrscheinlichkeit, dass aus einem liegengebliebenen Update, einem kaputten Formular oder einem toten Backup irgendwann ein Notfall wird. \nDer praktische Vorteil: weniger offene Zuständigkeiten \nLaufende Betreuung nimmt nicht jedes Risiko weg. Sie sorgt dafür, dass vereinbarte Aufgaben und Eskalationswege nicht bei jedem Problem neu geklärt werden müssen. \nDu weißt, wer Updates prüft, wie Backups kontrolliert werden und welche Aufgaben außerhalb des Monatsrahmens liegen. Diese Klarheit ist der eigentliche Nutzen. \nFazit: Wartung braucht einen konkreten Verantwortungsrahmen \nWebsite-Wartung ist weder eine Garantie gegen Ausfälle noch automatisch ein vollständiger Security-Audit. Sie kann Updates, Backups, zentrale Funktionsprüfungen und kleine technische Aufgaben verlässlich abdecken, wenn Systeme, Rhythmus und Grenzen vorher feststehen. \n“Läuft doch” ist keine Strategie. Es verschiebt das Risiko nur nach hinten – bis ein kleines Problem plötzlich teuer, stressig und zeitraubend wird. \nOb dafür ein laufender Vertrag sinnvoll ist, hängt vom Zustand der Website und den tatsächlich wiederkehrenden Aufgaben ab. \nWenn du unsicher bist, ob bei dir gerade laufende Betreuung reicht, erst Bereinigung nötig ist oder die Website strukturell nicht mehr tragfähig ist, dann ist genau das die eigentliche Frage. \nTechnische Betreuung ansehen  \nHäufige Fragen zur Website-Wartung \n“Kann ich Wartung nicht einfach selbst machen?” \nTechnisch gesehen: ja. Praktisch heißt das aber auch, dass du Verantwortung für Updates, Backups, Formularzustellung, Fehlerbilder und den Ernstfall übernimmst. Für manche ist das okay. Für viele ist es genau der technische Ballast, den sie eigentlich loswerden wollen. \n“Mein Hoster macht doch Backups – reicht das nicht?” \nViele Hoster bieten Backups an, aber: Funktionieren sie wirklich? Wurden sie jemals getestet? Sind sie aktuell genug? Sind sie vollständig? Hoster-Backups sind ein Anfang, aber keine Garantie. Professionelle Wartung bedeutet: Backups werden regelmäßig erstellt, extern gespeichert UND getestet. Du weißt, dass sie funktionieren – bevor du sie brauchst. \n“Wie oft sollten Updates eingespielt werden?” \nDas hängt von der Art des Updates ab. Kritische Sicherheitsupdates sollten zeitnah geprüft und eingespielt werden. Kleinere Feature-Updates können gebündelt werden, etwa wöchentlich oder monatlich. Wichtig ist: Updates sollten in einer Testumgebung geprüft werden, bevor sie live gehen. Genau das macht professionelle Wartung. \n“Was passiert, wenn ein Update etwas kaputt macht?” \nGenau deshalb gibt es Backups und Testumgebungen. Professionelle Wartung bedeutet: Vor jedem größeren Update wird ein Backup erstellt. Das Update wird in einer Testumgebung geprüft. Erst wenn alles funktioniert, geht es live. Sollte trotzdem etwas schiefgehen, lässt sich die Website in vielen Fällen deutlich schneller wiederherstellen. \n“Brauche ich wirklich jeden Monat Wartung? Meine Seite ändert sich doch kaum.” \nSicherheitslücken entstehen unabhängig davon, ob du deine Seite änderst oder nicht. Neue Schwachstellen werden ständig entdeckt. Updates werden ständig veröffentlicht. Auch ruhige Websites brauchen regelmäßige Kontrolle, weil sich Software, Hosting und Abhängigkeiten trotzdem weiter verändern. \n“Was ist, wenn ich mit der Wartung aufhöre?” \nDu behältst volle Kontrolle über deine Website. Alle Zugänge, alle Daten – alles gehört dir. Wenn du die Wartung beendest, kannst du selbst weiterarbeiten oder zu einem anderen Dienstleister wechseln. Es gibt keine technischen Abhängigkeiten. Aber: Ohne Wartung steigt das Risiko von Hacks, Ausfällen und Performance-Problemen schnell wieder. \n“Wie schnell reagierst du im Notfall?” \nBei kritischen Problemen priorisiere ich solche Fälle. Wie schnell das konkret geht, hängt vom Kontext, vom bestehenden Setup und von der vereinbarten Betreuung ab. Wichtig ist: Ein Notfall ist etwas anderes als laufende Routine, und genau so sollte er auch behandelt werden. \nWenn es gerade akut ist, brauchst du keinen Wartungsvertrag, sondern eine Bereinigung oder Reparatur: WordPress gehackt, WordPress kaputt nach Update, kein Zugang zur Website oder Mails landen im Spam. Betreuung ist die Antwort danach, nicht mittendrin. \n“Kann ich zwischen Wartungsplänen wechseln?” \nEntscheidend ist nicht der Planname, sondern ob der Umfang noch zu dem passt, was bei dir wirklich laufend anfällt. Wenn sich die Website oder deine Anforderungen ändern, muss die Betreuung neu sortiert werden. Manchmal bedeutet das mehr laufende Verantwortung, manchmal weniger und manchmal erst einmal eine Projektphase statt weiterer Routine.  \nWebsite-Wartung ist keine Garantie gegen alle Probleme. Sie reduziert Risiken, verbessert Reaktionsfähigkeit und macht es wahrscheinlicher, dass kleine Probleme klein bleiben."
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/blog/website-wartung-investition/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Startseite",
          "item": "https://contegus.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Website-Wartung: Warum 'läuft doch' teuer wird"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/blog/wordpress-gehackt-was-tun/#webpage",
      "url": "https://contegus.com/blog/wordpress-gehackt-was-tun/",
      "name": "WordPress gehackt: Was du jetzt tun solltest",
      "description": "WordPress gehackt: Was du jetzt tun solltest, welche Fehler du vermeiden solltest und wann ein technischer Website-Check sinnvoll ist.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "dateModified": "2026-05-19T00:00:00.000Z",
      "breadcrumb": {
        "@id": "https://contegus.com/blog/wordpress-gehackt-was-tun/#breadcrumb"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://contegus.com/blog/wordpress-gehackt-was-tun/#article",
      "headline": "WordPress gehackt: Was du jetzt tun solltest",
      "description": "WordPress gehackt: Was du jetzt tun solltest, welche Fehler du vermeiden solltest und wann ein technischer Website-Check sinnvoll ist.",
      "mainEntityOfPage": {
        "@id": "https://contegus.com/blog/wordpress-gehackt-was-tun/#webpage"
      },
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "datePublished": "2026-05-19T00:00:00.000Z",
      "dateModified": "2026-05-19T00:00:00.000Z",
      "author": {
        "@type": "Person",
        "name": "Kevin Kulik"
      },
      "articleBody": "WordPress gehackt: Was du jetzt tun solltest \n19.5.2026 · Kevin Kulik \n      \nWenn deine WordPress-Website gehackt wurde, zählt zuerst Ruhe und Reihenfolge. Nicht jedes Problem ist gleich ein Totalschaden. Aber planloses Klicken, wahlloses Löschen oder ein blindes Plugin-Update kann Spuren zerstören und die Bereinigung schwieriger machen. \nDieser Artikel ist eine praktische Erste-Hilfe-Checkliste. Er ersetzt keine forensische Analyse und keine Rechtsberatung. Er hilft dir, die Lage zu stabilisieren und die richtigen nächsten Schritte einzuleiten. \nWenn du das nicht selbst machen willst oder es gerade brennt: Auf der Seite WordPress gehackt: Soforthilfe und Bereinigung steht, wie eine Bereinigung bei mir abläuft, was sie kostet und wie schnell die Seite wieder sauber online ist. \nWoran du einen WordPress-Hack erkennst \nManche Hacks sind offensichtlich: \n \nDie Website zeigt Spam, fremde Werbung oder Weiterleitungen. \nGoogle warnt vor Malware oder Phishing. \nDer Browser meldet eine unsichere Website. \nDie Startseite ist ersetzt oder zeigt nur noch Fehler. \nKunden schreiben, dass sie auf dubiose Seiten weitergeleitet werden.  \nAndere Fälle sind leiser: \n \nIm WordPress-Backend tauchen unbekannte Admin-Nutzer auf. \nNeue Dateien liegen in wp-content, die niemand angelegt hat. \nDie Website versendet Spam-Mails. \nDie Search Console zeigt gehackte Seiten oder japanische Spam-URLs. \nDer Hoster sperrt die Website wegen verdächtiger Aktivität.  \nWenn mehrere dieser Punkte passen, solltest du die Website nicht einfach weiterlaufen lassen. \nSofortmaßnahme 1: Website stabilisieren \nWenn die Website aktiv Malware ausliefert, Besucher weiterleitet oder Spam verbreitet, sollte sie kurzfristig aus dem Verkehr gezogen werden. Das kann über den Hoster, eine Wartungsseite oder eine temporäre Sperre passieren. \nWichtig ist: Nicht einfach alles löschen. Wenn später geklärt werden muss, was passiert ist, können Logs, Dateien und Zeitpunkte wichtig sein. Erst stabilisieren, dann strukturiert prüfen. \nSofortmaßnahme 2: Zugangsdaten sichern \nÄndere nicht nur dein WordPress-Passwort. Prüfe alle Zugänge, die mit der Website zusammenhängen: \n \nWordPress-Administratoren \nHosting-Panel \nFTP/SFTP/SSH \nDatenbank-Zugang \nE-Mail-Postfächer \nCloudflare oder DNS-Zugänge \nGoogle Search Console  \nUnbekannte WordPress-Nutzer sollten deaktiviert oder entfernt werden. Wenn du nicht sicher bist, wer welchen Zugang braucht, erst dokumentieren und dann handeln. \nSofortmaßnahme 3: Backup-Lage prüfen \nEin Backup hilft nur, wenn es sauber, vollständig und alt genug ist. Viele Website-Betreiber stellen zu schnell ein Backup wieder her und merken später: Das Backup war bereits infiziert. \nPrüfe deshalb: \n \nWann gab es die ersten Auffälligkeiten? \nGibt es Backups von davor? \nEnthalten die Backups Dateien und Datenbank? \nWurde schon einmal erfolgreich aus einem Backup wiederhergestellt? \nLiegen Backups getrennt vom kompromittierten Server?  \nWenn der Zeitpunkt des Angriffs unklar ist, braucht es erst eine technische Einordnung. \nSofortmaßnahme 4: Updates nicht blind einspielen \nVeraltete Plugins, Themes oder WordPress-Versionen sind häufig die Ursache. Trotzdem ist ein sofortiger Update-Klick nicht immer der richtige erste Schritt. \nWarum? Wenn die Website bereits verändert wurde, kann ein Update Symptome überdecken, ohne die Hintertür zu schließen. Außerdem können Updates eine ohnehin instabile Seite weiter beschädigen. \nSinnvoller Ablauf: \n \nZustand sichern. \nAuffälligkeiten dokumentieren. \nUrsache eingrenzen. \nBereinigung planen. \nDanach Updates und Härtung sauber einspielen.  \nWas meistens bereinigt werden muss \nEine gehackte WordPress-Seite besteht selten nur aus einer einzelnen schädlichen Datei. Häufig betroffen sind: \n \nWordPress-Core-Dateien \nThemes und Child-Themes \nPlugins \nUpload-Verzeichnisse \nDatenbankeinträge \nAdmin-Nutzer \nWeiterleitungen in .htaccess oder Server-Konfiguration \nCronjobs oder versteckte Skripte  \nWenn nur die sichtbare Spam-Seite entfernt wird, bleibt die eigentliche Hintertür oft bestehen. Dann kommt der Hack nach kurzer Zeit zurück. \nGoogle Search Console prüfen \nWenn Google bereits Warnungen zeigt oder Spam-URLs indexiert wurden, solltest du die Search Console prüfen: \n \nSicherheitsprobleme \nManuelle Maßnahmen \nIndexierte Spam-Seiten \nUngewöhnliche Suchanfragen \nSitemap und Abdeckung  \nNach der Bereinigung kann eine erneute Überprüfung beantragt werden. Das sollte erst passieren, wenn die Ursache wirklich behoben ist. \nWas kostet eine Hack-Bereinigung? \nDas hängt stark vom Zustand ab. Eine kleine, früh entdeckte Infektion ist etwas anderes als eine monatelang kompromittierte WooCommerce-Seite mit Kundendaten, kaputten Backups und unbekannten Zugängen. \nTypische Kostentreiber sind: \n \nunklare Zugriffslage \nfehlende oder infizierte Backups \nviele Plugins und alte Themes \nkompromittierte Datenbank \nMalware in Uploads \nHosting-Sperre oder Blacklisting \nanschließende Härtung und Monitoring  \nManchmal ist Bereinigung sinnvoll. Manchmal ist ein sauberer Neubau wirtschaftlicher, besonders wenn die Website technisch ohnehin am Ende ist. \nWann ein Website-Check sinnvoll ist \nEin Website-Check ist sinnvoll, wenn du nicht sicher weißt: \n \nob die Website noch bereinigt werden kann \nob ein Backup vertrauenswürdig ist \nwoher der Angriff kam \nob die Seite wieder online gehen sollte \nob WordPress weiterhin die richtige Grundlage ist \nob laufende Wartung künftig reicht  \nGenau diese Einordnung verhindert, dass du Geld in die falsche Richtung steckst. \nTechnische Bestandsaufnahme und nächste Schritte klären \nWie du Wiederholungen vermeidest \nNach der Bereinigung ist die wichtigste Frage: Warum konnte das passieren? \nMeist geht es um eine Kombination aus veralteten Plugins, schwachen Passwörtern, fehlender Wartung, schlechten Backups und unklarer Verantwortung. Eine gehärtete Website braucht: \n \nregelmäßige Updates \ngetestete Backups \nstarke Zugänge und Zwei-Faktor-Login \nreduzierte Plugin-Angriffsfläche \nMonitoring auf Auffälligkeiten \nklare Zuständigkeit für Wartung und Pflege  \nWenn deine Website grundsätzlich tragfähig ist, kann laufende Wartung danach sinnvoll sein. Wenn die Grundlage zu fragil ist, sollte erst bereinigt oder neu gebaut werden. \nGehackte WordPress-Seite bereinigen lassen \nTechnische Betreuung ansehen"
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/blog/wordpress-gehackt-was-tun/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Startseite",
          "item": "https://contegus.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "WordPress gehackt: Was du jetzt tun solltest"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/en/#webpage",
      "url": "https://contegus.com/en/",
      "name": "Investigate systems.Solve problems.",
      "description": "White-label technical support for agencies and teams: troubleshooting, security reviews, Linux infrastructure and repair of existing AI-generated projects.",
      "inLanguage": "en",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/impressum/#webpage",
      "url": "https://contegus.com/impressum/",
      "name": "Impressum",
      "description": "Betreiber- und Kontaktangaben von Contegus, Kevin Kulik in Ennepetal.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/#webpage",
      "url": "https://contegus.com/",
      "name": "Technik prüfen.Probleme lösen.",
      "description": "Fehlersuche, Sicherheitsprüfung, Infrastruktur, KI-Projekte sowie Anwendungen und Automatisierung für Unternehmen und Agenturen.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/kontakt/#webpage",
      "url": "https://contegus.com/kontakt/",
      "name": "Welche technische Aufgabe steht an?",
      "description": "Technisches Problem, Sicherheitsfrage, KI-Projekt oder Entwicklung: Schilder Kevin Kulik kurz dein Anliegen und die beteiligten Systeme.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/leistungen/anwendungen-automatisierung/#webpage",
      "url": "https://contegus.com/leistungen/anwendungen-automatisierung/",
      "name": "Interne Anwendungen und Automatisierungen für einen konkreten Arbeitsablauf.",
      "description": "Interne Anwendungen, Schnittstellen und Automatisierungen für konkrete Arbeitsabläufe, mit nachvollziehbarer Fehlerbehandlung und KI, wenn sie zur Aufgabe passt.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/leistungen/anwendungen-automatisierung/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/leistungen/anwendungen-automatisierung/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Leistungen",
          "item": "https://contegus.com/leistungen/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Anwendungen und Automatisierung"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/leistungen/#webpage",
      "url": "https://contegus.com/leistungen/",
      "name": "Technische Unterstützung für bestehende Systeme und neue Anwendungen.",
      "description": "Fehlersuche und Sicherheitsprüfung, Infrastruktur, KI-Projekte reparieren und fertigstellen sowie Entwicklung und Integration für Unternehmen und Agenturen.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/leistungen/ki-projekte-fertigstellen/#webpage",
      "url": "https://contegus.com/leistungen/ki-projekte-fertigstellen/",
      "name": "KI-Projekte reparieren und fertigstellen",
      "description": "Vorhandene KI-Projekte prüfen, Fehler beheben, fehlende Funktionen ergänzen und das Deployment vorbereiten. Für Unternehmen und Agenturen.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/leistungen/ki-projekte-fertigstellen/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/leistungen/ki-projekte-fertigstellen/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Leistungen",
          "item": "https://contegus.com/leistungen/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "KI-Projekte fertigstellen"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/leistungen/website-neu-bauen/#webpage",
      "url": "https://contegus.com/leistungen/website-neu-bauen/",
      "name": "Eine neue Website – wenn ein Neubau wirklich sinnvoll ist.",
      "description": "Neue Websites mit klarer Anfrageführung, schneller Technik und zugänglicher Bedienung. Für den ersten Auftritt oder einen sinnvollen Relaunch.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/leistungen/website-neu-bauen/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/leistungen/website-neu-bauen/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Leistungen",
          "item": "https://contegus.com/leistungen/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Website-Neubau"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/projekte/ferienwohnung-voerde/#webpage",
      "url": "https://contegus.com/projekte/ferienwohnung-voerde/",
      "name": "Einen festgefahrenen Bestand wieder ordnen.",
      "description": "Projektbeispiel: Einen WordPress-Bestand stabilisieren und die lokale Sichtbarkeit wiederherstellen.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/projekte/ferienwohnung-voerde/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/projekte/ferienwohnung-voerde/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Projekte",
          "item": "https://contegus.com/projekte/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Ferienwohnung Voerde"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/projekte/heson/#webpage",
      "url": "https://contegus.com/projekte/heson/",
      "name": "Produkte finden. Gemeinsam anfragen.",
      "description": "Projektbeispiel: Ein B2B-Produktkatalog für HESON als belastbare technische Plattform.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/projekte/heson/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/projekte/heson/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Projekte",
          "item": "https://contegus.com/projekte/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "HESON"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/projekte/#webpage",
      "url": "https://contegus.com/projekte/",
      "name": "Technische Arbeit aus Kundenprojekten.",
      "description": "Ausgewählte Projekte zu Anwendungen, Infrastruktur, Sicherheitsprüfungen, technischen Übernahmen und Websites.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/projekte/kindbridge/#webpage",
      "url": "https://contegus.com/projekte/kindbridge/",
      "name": "Verantwortung über einzelne Aufträge hinaus.",
      "description": "Projektbeispiel: Laufende technische Betreuung und Security-Reviews für Kindbridge.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/projekte/kindbridge/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/projekte/kindbridge/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Projekte",
          "item": "https://contegus.com/projekte/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Kindbridge"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/projekte/psychologische-beratung/#webpage",
      "url": "https://contegus.com/projekte/psychologische-beratung/",
      "name": "Barrierefreiheit von Anfang an mitdenken.",
      "description": "Projektbeispiel: Eine Praxiswebsite mit klarer Anfrageführung und Barrierefreiheit als Maßstab.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/projekte/psychologische-beratung/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/projekte/psychologische-beratung/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Projekte",
          "item": "https://contegus.com/projekte/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Psychologische Beratung"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/technik-uebernahme/#webpage",
      "url": "https://contegus.com/technik-uebernahme/",
      "name": "Bestehende Anwendungen und Infrastruktur übernehmen und stabilisieren.",
      "description": "Bestehende Anwendungen und Infrastruktur übernehmen: Konfiguration, Abhängigkeiten, Deployment, Backups und Fehler prüfen, beheben und dokumentiert übergeben.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/technik-uebernahme/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/technik-uebernahme/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Leistungen",
          "item": "https://contegus.com/leistungen/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Übernahme und Stabilisierung"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/technische-betreuung/#webpage",
      "url": "https://contegus.com/technische-betreuung/",
      "name": "Unterstützung für Server, Anwendungen und den laufenden Betrieb.",
      "description": "Linux, Server, Hosting, Deployments, Monitoring und Backups: technische Unterstützung, Fehleranalyse und Weiterentwicklung für Unternehmen und Agenturen.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/technische-betreuung/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/technische-betreuung/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Leistungen",
          "item": "https://contegus.com/leistungen/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Technische Betreuung"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/ueber-mich/#webpage",
      "url": "https://contegus.com/ueber-mich/",
      "name": "Ich arbeite an der Technik, die dein Unternehmen braucht.",
      "description": "Kevin Kulik untersucht, sichert und entwickelt bestehende Anwendungen und Infrastruktur als direkter technischer Ansprechpartner.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://contegus.com/wordpress-gehackt/#webpage",
      "url": "https://contegus.com/wordpress-gehackt/",
      "name": "WordPress gehackt?",
      "description": "Hilfe bei gehackten WordPress-Websites: Befall prüfen, Malware und Hintertüren entfernen, Ursache schließen und Ergebnis nachprüfen.",
      "inLanguage": "de",
      "isPartOf": {
        "@id": "https://contegus.com/#website"
      },
      "breadcrumb": {
        "@id": "https://contegus.com/wordpress-gehackt/#breadcrumb"
      }
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "@id": "https://contegus.com/wordpress-gehackt/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Akute Hilfe",
          "item": "https://contegus.com/akuthilfe/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "WordPress gehackt"
        }
      ]
    }
  ]
}