Der Inhalt erhält keinen weiteren seitlichen Einzug. Der Header des aufklappbaren Bereichs bleibt per Tastatur bedienbar.

Ziel: In wenigen Sekunden erklären, wofür doIT steht, Vertrauen schaffen und Besucher zu den relevanten Leistungs- oder Kontaktseiten führen.

Hero: klare Positionierung; Technik, Geschäftsprozesse und Menschen; kein klassisches ‚Wir sind ein IT-Systemhaus‘-Wording; direkte, verständliche Sprache.

Leistungen: Überblick über die wichtigsten Leistungsbereiche, nicht zu viele Einzelthemen; Weiterleitung auf Detailseiten.

Wie wir arbeiten / Prozess: verständlicher Ablauf; nicht nur Produkte verkaufen; erst verstehen, dann eine Lösung entwickeln.

Vertrauen / Referenzen: Kundenbezug, echte Wirkung statt reiner Produktwerbung, Kundenstimmen bzw. Referenzen.

Haltung / gemeinsame Verantwortung: Prozesse, Dokumentation, sinnvolle KI-Basis, Verantwortung von Kunde und IT-Partner. IT als Investition statt als Kostenstelle betrachten.

CTA: heller Abschlussbereich vor dem Footer; direkte Kontaktaufnahme, kein übertriebener Sales-Druck.

Ziel: Nicht mit Benefits oder Stellenanzeigen beginnen, sondern zeigen, welche Wirkung die Arbeit bei doIT hat und welche Haltung gesucht wird.

Hero: ‚Mach IT, die im Alltag wirklich hilft.‘ Echte Arbeit, Menschen und IT-Alltag zeigen; keine sterile Stockfoto-Welt.

Was Deine Arbeit bewirkt: ‚Du löst keine Aufgaben. Du schaffst Entlastung.‘ Sechs Kacheln: Technik, die Menschen entlastet; Lösungen mit Bestand; Verantwortung, die Kunden spüren; Menschen, mit denen man gerne arbeitet; Weiterentwicklung mit Vertrauen; Erfolg, den man gemeinsam feiert.

Karten/Kacheln, bestehende Icons und Mouseover-Effekt beibehalten. Keine schmalen Textspalten daraus machen. Die Wirkung der Arbeit steht im Mittelpunkt.

Haltung / Wen wir suchen: ‚Nicht Perfektion. Sondern Haltung.‘ Der Satz ‚Denn Fachwissen kann man lernen‘ wurde bewusst entfernt: zu erklärend, bereits in der Hauptaussage enthalten, keine belehrende Tonalität.

Wir suchen Menschen …: kurze Aussagen nach dem Aufbau ‚… die …‘, ‚… die …‘, ‚… die …‘, ‚… um …‘. Fokus auf Persönlichkeit, Eigenverantwortung, Zusammenarbeit, Kundenorientierung und Lernbereitschaft.

Kultur / Team: Zusammenarbeit, Freude im Team, Lob von Kunden und Erfolgserlebnisse. Keine künstliche Employer-Branding-Sprache.

Übergang zu offenen Stellen: klare Weiterleitung auf konkrete Stellen.

Ziel: Sehr übersichtliche Darstellung der aktuell gesuchten Rollen. Zwei konkrete Stellenkarten und eine Karte für Initiativbewerbungen.

Initiativbewerbung sinngemäß: ‚Ich habe Erfahrung im IT-Business und würde gerne bei Euch mitarbeiten.‘

Gleiche Designsprache wie Karriere; übersichtliche Karten; keine überfrachteten Stellenanzeigen auf der Übersichtsseite. Details erst nach Klick; klare CTA-Logik.

Ziel: Nicht einfach erzählen, wie toll doIT ist. Die Seite beantwortet: Wer sind wir? Wo kommen wir her? Wofür stehen wir? Wie arbeiten wir? Warum kann man uns vertrauen?

Hero · Fertig: Schloss Raesfeld steht für Tradition, Werte, regionale Verwurzelung, die Brücke zum Münsterland und das Tor zum Ruhrgebiet. Innovation und Bodenständigkeit schließen sich nicht aus. Eyebrow: ÜBER UNS. Headline: ‚IT ist für uns kein Selbstzweck.‘

Hero-Text: ‚Wir verbinden Technik, Prozesse und individuelle Betreuung – damit IT im Alltag wirklich funktioniert.‘ Weitere Aussagen: ‚Verwurzelt im Münsterland. Verbunden mit dem Ruhrgebiet. Innovativ im Denken. Bodenständig im Handeln. Persönlich. Verständlich. Wertschätzend.‘

Unsere Haltung · Fertig: ‚Wir sagen, was geht. Und was nicht.‘ Heller Bereich, große Headline links, erklärender Text rechts; keine Karten, ruhige Typografie.

Haltung-Text: ‚Gute IT beginnt für uns nicht mit Produkten, sondern mit Zuhören. Wir wollen verstehen, wie ein Unternehmen arbeitet, wo Prozesse stocken und welche Lösung wirklich weiterhilft. Dabei sprechen wir verständlich, empfehlen nur, was sinnvoll ist, und bleiben auch nach der Umsetzung erreichbar.‘

Unsere Geschichte · Feinschliff: ‚Unsere Geschichte begann lange vor doIT.‘ Persönliche Geschichte statt anonyme Firmenchronik. Portraits: Andreas Johannes Greiner, genannt AJ, und Olaf Becker.

1968–1988 / GEMEINSAME ANFÄNGE: AJ und Ingo 1968 im Marienhospital Marl geboren; gemeinsame Kindheit; ab Klasse 5 gemeinsam GSW Wulfen; ab Klasse 9 Olaf im Freundeskreis; VC20 und C64; C64-ComputerClub Dorsten; Computer-AG an der Schule; Projektwochen mit Computerthemen.

1991–2017 / DER BERUFLICHE WEG: AJ und Olaf gründen 1993 B&G EDV-Systeme. Ingo beginnt 1991 bei CompuNet in Essen, wechselt 1999 zu B&G. Christian Hösch kommt 2018 als Auszubildender zum Unternehmen. Die Zuordnung bleibt wie im Masterplan vorgegeben.

2017–2019 / ABSCHIED UND NEUANFANG: ‚2017 und 2018 verloren wir Andreas und Olaf. Damit endete nicht nur ein gemeinsamer beruflicher Weg, sondern eine Freundschaft, die bereits in unserer Kindheit begonnen hatte.‘ Juli 2018 Gründung der Funke Medical IT Solutions GmbH gemeinsam mit Thorsten Ortmeier und Funke Medical AG. Ende 2019 Ausscheiden des Hauptgesellschafters; Thorsten und Ingo übernehmen vollständig; Umfirmierung zur doIT GmbH.

2019–2025 / DER WANDEL ZUR doIT: Entwicklung vom klassischen Break-&-Fix-Systemhaus zum modernen Managed Service Provider. Microsoft 365, IT-Security, Entwicklung, Digitalisierung und Geschäftsprozess-Automatisierung mit und ohne KI.

2026 / FÜHRUNG IN NEUER HAND: Im September 2026 scheiden Thorsten Ortmeier und Ingo Klug aus der Geschäftsführung aus. Christian Hösch übernimmt die Geschäftsführung. Familie Klug wird Hauptgesellschafter der doIT GmbH.

Abschlussstatement: ‚Was sich verändert hat, sind Technologien und Geschäftsmodelle. Was geblieben ist, sind persönliche Verantwortung, Verlässlichkeit und der Anspruch, Unternehmen wirklich weiterzubringen.‘

Geschichte-Gestaltung: Accordion, dezente vertikale Linie, Punkte an den Stationen. Nur Trennlinien zwischen den Stationen, keine obere/untere Begrenzungslinie. Portraits visuell zur Höhe des Accordions ausrichten. Fließtext nicht kleiner machen, aber leichteres Font-Weight; wenig Fettschrift.

Wofür doIT steht · Als Nächstes: Werte nicht nur nennen, sondern ihre Bedeutung im Alltag erklären. PERSÖNLICH bedeutet menschliche, direkte Zusammenarbeit, nicht einen garantierten festen persönlichen Ansprechpartner. VERSTÄNDLICH bedeutet nachvollziehbare Entscheidungen, keine technische Sprache um der Technik willen. WERTSCHÄTZEND bedeutet Zusammenarbeit auf Augenhöhe sowie Anforderungen und Menschen ernst zu nehmen. Keine generische Werte-Kartenwand.

Unternehmen und Menschen · Offen: doIT heute zeigen. Inhabergeführt / Gesellschafterstruktur, regional verwurzelt, kurze Wege, kleines Team, direkte Kommunikation, technische Schwerpunkte und Menschen hinter der Technik. Keine klassische ‚Wir sind seit X Jahren Ihr kompetenter Partner‘-Sektion.

Wie wir arbeiten · Offen: VERSTEHEN → EINORDNEN → VERBESSERN → UMSETZEN → BEGLEITEN. Nicht mit einem Produkt beginnen, sondern mit dem Geschäftsprozess bzw. dem tatsächlichen Bedarf.

Abschluss / CTA · Offen: kurzer Abschluss, keine weitere große Inhaltssektion. Übergang zur Kontaktaufnahme, sinngemäß: ‚Passt unsere Art zu arbeiten zu Deinem Unternehmen? Dann sollten wir miteinander sprechen.‘

Gemeinsame Designsprache: starke Hero-Sektion, klare Eyebrow und Headline, keine Textwand am Anfang. Inhalt über Abschnitte, Bilder, Statements und gegebenenfalls Cards strukturieren. Klare visuelle Hierarchie; gleiche Abstände und Typografie über alle Unterseiten.

Keine beliebigen Stockfotos. Reale bzw. glaubwürdige Situationen bevorzugen. Aussagen stets aus Sicht des Kundennutzens formulieren.

IT-Sicherheit und IT-Betreuung / Managed Services sind als eigenständige Leistungsseiten vorgesehen. Weitere Detailthemen: Microsoft 365, Security, Entwicklung, Geschäftsprozess-Automatisierung, Digitalisierung sowie KI / Automatisierung mit und ohne KI.

Arbeitsstand vom 05.09.2026 zur Prüfung durch Ingo Klug. Diese private Seite ist die gemeinsame Referenz für einen Neuaufbau von bgweb.de: nachgewiesener Bestand, redaktionelle Leitlinien, technische Anforderungen und noch benötigte Entscheidungen.

Quellen: WordPress REST API mit authentifizierter Abfrage von Seiten, Medien, Themes, Plugins und Einstellungen; öffentlich ausgelieferte Seiten und HTTP-Prüfungen; lokale Theme-Arbeitskopie mit style.css, functions.php, theme.json, Editor-Dateien und Patterns; die von Ingo bereitgestellten Leitlinien und bisherigen Gestaltungsentscheidungen.

Die Einschätzungen zu Wettbewerbern stammen aus Ingos bereitgestellter Analyse. Sie wurden für diese Dokumentation nicht nochmals unabhängig geprüft. Bestehende lokale Architekturtexte und die weiter unten erhaltenen Designmuster sind historische Referenzen. Bei Abweichungen gilt der hier datiert dokumentierte Befund; für einen Neuaufbau werden offene Entscheidungen ausdrücklich freigegeben.

Diese Dokumentation ist kein vollständiges wiederherstellbares Website-Backup. Dafür werden Datenbank, Medien, Theme-Dateien, Plugins und Konfiguration gemeinsam benötigt.

• Zweck und Zielgruppen: IT-Betreuung und Prozessoptimierung für Unternehmen sowie Gewinnung passender Mitarbeitender. Benötigt werden zusätzlich priorisierte Zielgruppen, gewünschte Anfragen und messbare Erfolgskriterien. Die qualitative Positionierung ist durch Ingos Leitlinien vorgegeben.
• Informationsarchitektur: vollständige Seitenliste, Navigation, Abschnittsreihenfolge, interne Verknüpfungen, Weiterleitungen und Suchverhalten. Der veröffentlichte Seitenbestand und die aktuelle Hauptnavigation wurden ermittelt; gewünschte künftige Detailseiten sind zu bestätigen.
• Inhalte: freigegebene Texte, Leistungsumfang, Belege, Referenzen, Ansprechpartner, Kontaktwege und Rechtstexte. Bestehende Texte bleiben die Quelle. Fehlende Leistungsinformationen und belastbare Kundenergebnisse werden nicht erfunden.
• Design: Logo-Dateien, Palette, Schriften mit Lizenz, Typografie, Abstände, Bildsprache, Breakpoints und Interaktionszustände. Konfigurierte Werte sind dokumentiert; fehlende Font-Dateien und Lizenznachweise bleiben offen.
• Medien: Originale, Varianten, Zuschnitt, Fokuspunkt, Alternativtext, Urheber- und Nutzungsrechte. Mediathek-IDs und zentrale Dateien sind ermittelt; Rechte sind durch Dateinamen oder Erreichbarkeit nicht nachgewiesen.
• Funktionen: Header, Suche, Accordion, Kontakt- und Bewerbungswege, gegebenenfalls Quick-Check und Analysewerkzeuge. Aktuelle Code-Funktionen sind beschrieben. Ein Quick-Check ist eine Konzeptoption, noch keine vorhandene Anwendung.
• Redaktion: Standardblöcke, Patterns, globale Komponenten, Benutzerrollen, Freigabe und Verantwortlichkeiten. Gutenberg soll die Unterseiten vollständig wartbar halten.
• Betrieb: Hosting, Laufzeit, Datenbank, DNS, TLS, Mailversand, Sicherung, Wiederherstellung, Staging und Bereitstellung. Administrative Zugänge und Geheimnisse werden separat verwahrt; Ansprechpartner und Verfahren müssen noch ergänzt werden.

doIT führt den Besucher von Problem → Verstehen → Analyse → Lösung → Nutzen → Begleitung. Wir zeigen, wie Probleme gelöst werden und warum eine Lösung empfohlen wird. Technik ist Werkzeug, kein Selbstzweck.

Die Differenzierung entsteht durch die Arbeitsweise: zuhören, verstehen, analysieren, strukturieren, priorisieren, verbessern, umsetzen und begleiten. Technik, Prozesse und Menschen werden zusammen betrachtet.

Der wiederkehrende kommunikative Faden lautet: VERSTEHEN → STRUKTURIEREN → VERBESSERN → UMSETZEN → BEGLEITEN.

Der gewünschte Eindruck: doIT versteht, wie unser Unternehmen arbeitet, erkennt Zusammenhänge und setzt Technik dort ein, wo sie einen echten Nutzen bringt.

• Technik ist Werkzeug, kein Selbstzweck. Erst verstehen, dann lösen. Prozesse kommen vor Produkten.
• Gute IT schafft Klarheit und Struktur. Nicht jede neue Software löst ein Problem.
• Lösungen müssen zum Unternehmen und seinen Abläufen passen. Technik, Prozesse und Menschen gehören zusammen.
• Wir erklären IT verständlich und betrachten Zusammenhänge statt Einzelprobleme.
• Nach der Umsetzung hört unsere Arbeit nicht automatisch auf. Wir wollen langfristig verbessern, nicht kurzfristig verkaufen.
• Wir hören zuerst zu, betrachten das Ganze, erklären verständlich, empfehlen, was sinnvoll ist, setzen sauber um und bleiben Ansprechpartner.

Quelle dieses Kapitels: Ingos bereitgestellte Analyse. Ziel ist eine eigenständige doIT-Systematik, keine Kopie eines Wettbewerbers.

• IT-HAUS: visuelle Ruhe und klare Hierarchie. Übernehmen: große klare Bereiche, wenige Kernaussagen, einheitliche Icons, Freiraum und schnell erfassbare Leistungen. Vermeiden: generische IT-Bilder und austauschbare Security-/Cloud-Kommunikation.
• DZI-IT: Problem → Nutzenversprechen → Erklärung → konkreter Vorteil. Beispiel: „Schluss mit langsamen Verbindungen und unerklärlichen Ausfällen.“ statt lediglich „Netzwerk-Architektur“. Technische Begriffe dürfen vorkommen, führen aber nicht die Kommunikation.
• GreenIT: nachvollziehbarer Weg von Ausgangslage verstehen über Bedarf einordnen und Umsetzung bis Betrieb und Weiterentwicklung. Die Denkweise bleibt auf doIT-Detailseiten wiedererkennbar, ohne überall identische Texte zu erzwingen.
• IT-Systemhaus Ruhrgebiet: Interaktion kann Orientierung und Qualifizierung ermöglichen. Für doIT ist ein IT-Quick-Check geeigneter als ein reiner Kostenrechner, der Preisfokus und Scheingenauigkeit erzeugen könnte.
• G2 Systemhaus: punktuelle Gegenüberstellung macht Komplexität verständlich, etwa Vorher/Nachher, unstrukturiert/strukturiert oder reaktiv/proaktiv. Reduziert gestalten, nicht wie eine Preisliste.
• HTH: konsequente Nutzenorientierung. Monitoring ist eine Leistung; weniger ungeplante Ausfälle ist der Nutzen. Planbare Kosten, kontinuierliche Betreuung und weniger interner Aufwand sind mögliche Kundenvorteile, die im konkreten Angebot belegt werden müssen.
• TEAM-IT: vollständige Dramaturgie von Problem und Herausforderungen über Lösung, Leistungsbausteine, Nutzen und Entscheidungshilfe bis Vorgehen und CTA. Monotonie durch endlose ähnliche Karten und Textmengen vermeiden; Darstellungsformen gezielt wechseln.

Die Reihenfolge beschreibt die inhaltliche Dramaturgie. Seiten dürfen unterschiedliche Sektionstypen, Umfänge und Schwerpunkte haben. Ein neuer Seitentext benötigt ein konkretes Kundenproblem, überprüfbare Leistungsgrenzen und einen passenden nächsten Schritt.

• 1. Hero: eine starke Aussage zum Problem oder Nutzen. Beispiel „Gemeinsam arbeiten, ohne Dateichaos.“ statt eines alleinstehenden Produktnamens. Thema und Relevanz müssen in wenigen Sekunden erkennbar sein.
• 2. Problem und Ausgangslage: typische Schwierigkeiten, Folgen und Handlungsanlass beschreiben. Der Besucher soll seine Situation wiedererkennen.
• 3. Unsere Sichtweise: doIT-Haltung erläutern. Beispiele: „Sicherheit entsteht nicht durch ein einzelnes Produkt. Technik, Prozesse und Menschen müssen zusammenspielen.“ und „Wir automatisieren keinen schlechten Prozess. Wir schauen zuerst, ob der Prozess überhaupt sinnvoll ist.“
• 4. Unser Vorgehen: Verstehen → Analysieren → Priorisieren → Umsetzen → Begleiten. Der Weg erklärt, warum nicht sofort Produkte angeboten werden.
• 5. Konkrete Leistungen: erst jetzt Microsoft 365, Firewall, Backup, Monitoring, Endpoint Security, Automatisierung, Netzwerk oder Cloud im jeweiligen Problemkontext benennen.
• 6. Nutzen: aus Kundensicht erklären. Patchmanagement: Systeme bleiben aktuell und bekannte Sicherheitslücken werden reduziert. Monitoring: Probleme werden möglichst erkannt, bevor sie den Arbeitsalltag beeinträchtigen.
• 7. Zusammenhänge: wo sinnvoll Beziehungen sichtbar machen, etwa zwischen Microsoft 365, Zusammenarbeit, Sicherheit, mobilem Arbeiten, Dokumentation und Automatisierung.
• 8. Entscheidungshilfe: für wen ist die Lösung geeignet, welche Ausgangslage spricht dafür und was verändert sich? Vergleiche nur dort einsetzen, wo sie das Verständnis verbessern.
• 9. CTA: ruhige Einladung zum Gespräch. „Lass uns gemeinsam herausfinden, was für Dein Unternehmen sinnvoll ist.“ Nicht jedes Problem muss mit einem Produkt enden.

• Verständlich, direkt und kundennah schreiben: kurze klare Aussagen, aktive Formulierungen, konkrete Probleme und Auswirkungen, nachvollziehbarer Nutzen und verständliche Beispiele.
• Marketingfloskeln, unnötige Superlative, Buzzwords ohne Aussage, technische Aufzählungen ohne Kontext und übertriebene Versprechen vermeiden.
• „innovativ“, „ganzheitlich“, „maßgeschneidert“, „state of the art“ und „optimal“ nur verwenden, wenn damit eine konkrete Aussage verbunden ist.
• Visuelle Hierarchie, konsistente Typografie und Abstände, einheitliche Icons, ausreichender Freiraum und klar erkennbare CTA. Wenige starke Aussagen statt Textwänden; nicht jede Information in eine Kachel setzen.
• Für längere Detailseiten Hero, Text/Bild, einzelne Karten, Prozessdarstellung, Vergleich, Nutzenübersicht, Zusammenhänge, Einzelstatement und CTA passend kombinieren. Keine endlosen Raster gleicher Karten.
• IT-Quick-Check als mögliche spätere Funktion: Fragen zu Infrastruktur, Microsoft 365, Sicherheit, Backup, Dokumentation, Prozessen, Automatisierung und Support. Ergebnis als Standortbestimmung mit Handlungsfeldern.
• Vor Umsetzung des Quick-Checks festlegen: Fragen, Auswertungslogik, Ergebnisformulierungen, Grenzen der Aussage, anonyme Nutzung oder Kontaktdaten, Speicherdauer und Übergabe an Beratung. Ein Preiskalkulator oder eine belastbare Diagnose ist damit nicht zugesagt.

Am 05.09.2026 liefert die authentifizierte WordPress-Abfrage 18 veröffentlichte Seiten. Die private Design-Seite hat ID 1353 und bleibt unter /design/. Startseite: ID 6. Alle aufgeführten veröffentlichten Seiten besitzen derzeit parent=0; URL-Struktur und Navigationsstruktur sind getrennt zu betrachten.

Hauptnavigation: Start → /; IT-Betreuung → /it-betreuung; Leistungen → /managed-it-support/; Über uns → /ueber-uns/; Karriere → /karriere/; Kontakt → /kontakt/; Telefon → tel:+4928659996000.

• Karriere — ID 1464 — https://doit.gmbh/karriere/
• Datenschutzerklärung — ID 1407 — https://doit.gmbh/datenschutzerklaerung/
• Impressum — ID 1427 — https://doit.gmbh/impressum/
• AGB — ID 1350 — https://doit.gmbh/agb/
• Geschäftsprozesse — ID 231 — https://doit.gmbh/geschaeftsprozesse/
• Über uns — ID 98 — https://doit.gmbh/ueber-uns/
• Kontakt — ID 28 — https://doit.gmbh/kontakt/
• IT-Schnelltest — ID 26 — https://doit.gmbh/it-schnelltest/
• Datenschutz — ID 24 — https://doit.gmbh/datenschutz/
• Websites, Domains & SSL — ID 22 — https://doit.gmbh/websites-domains-ssl/
• Sage 100 & Prozesse — ID 20 — https://doit.gmbh/sage-100-prozesse/
• VoIP-Telefonie mit Placetel — ID 18 — https://doit.gmbh/voip-telefonie-placetel/
• Microsoft 365 & Cloud — ID 16 — https://doit.gmbh/microsoft-365-cloud/
• IT-Sicherheit & Backup — ID 14 — https://doit.gmbh/it-sicherheit-backup/
• Managed IT & Support — ID 12 — https://doit.gmbh/managed-it-support/
• IT-Dienstleister wechseln — ID 10 — https://doit.gmbh/it-dienstleister-wechseln/
• Kunde werden — ID 8 — https://doit.gmbh/kunde-werden/
• Startseite — ID 6 — https://doit.gmbh/

Live-Stand nach Überarbeitung der Referenz: aktives Child Theme doit-blocksy-child, Version 1.4.169; Parent Theme Blocksy 2.1.48. WordPress-Assets werden mit Version 7.1 ausgeliefert. Website-Titel doIT GmbH, Zeitzone Europe/Berlin, statische Startseite mit ID 6.

Aktive Plugins laut Admin-API: Antispam Bee 2.11.11, Safe SVG 2.4.0 und WP Mail SMTP 4.8.0. Akismet 5.7 ist inaktiv. Blocksy Companion ist nicht in dieser Plugin-Liste enthalten. Mailtransport, Zustellung und serverseitige Zusatzkomponenten wurden nicht getestet.

Das Child Theme deklariert mindestens WordPress 6.7 und PHP 8.1. Das sind Paketanforderungen; die tatsächlich laufende PHP- und Datenbankversion müssen über Website-Zustand oder Hosting ermittelt werden.

Die aktuelle lokale Arbeitskopie liegt unter Documents/bgweb-theme-audit-work. Sie ist eine Arbeitsquelle, kein bestätigtes vollständiges Server-Backup.

• theme.json: Palette, Inhaltsbreiten, Schriftdefinitionen, Größen und Abstands-Presets für Gutenberg.
• style.css: zentrales Erscheinungsbild, responsive Komponenten und aktuell auch seitenbezogene Regeln für Über uns und Karriere. Mehrere historisch ergänzte Regeln überschreiben einander.
• functions.php: Theme-Setup, Übernahme von Blocksy-Einstellungen, Logo-/Telefon-Ergänzungen, Editor-Assets, Patterns, Seitentitel-Erkennung, Meta-Description-Fallback, Footer und JavaScript-Einbindung.
• assets/css/editor.css und assets/js/editor.js: Darstellung und Unterstützung im Blockeditor. Vor einem Neuaufbau mit der Frontend-Darstellung abgleichen.
• assets/js/subpage-header.js: ausblendbarer Header mit Anfasser, Höhenmessung und Hell-/Dunkel-Umschalter.
• patterns/: hero.php, intro.php, text-image.php, feature-grid.php, cta.php, page-starter.php, legal-page.php, blank-page.php und global-footer.php.
• Synchronisierter Block doIT Global Footer: ID 1295, Slug doit-global-footer. Änderungen wirken auf Unterseiten. Die Startseite besitzt ihren eigenen Footer.
• Startseite: ein Custom-HTML-Block mit eingebettetem Code. Geschäftsprozesse: Inhalt ohne Gutenberg-Blockkommentare und mit drei Script-Elementen. Diese zweite Sonderseite widerspricht dem Ziel vollständig standardmäßig editierbarer Unterseiten.
• Das aktuelle Child-Stylesheet wird auch auf der Startseite geladen. Die ältere lokale Aussage, es werde dort grundsätzlich nicht geladen, stimmt nicht mehr.

• Palette: doIT Grün #aed535; Grün dunkel #9fc131; Grün hell #d7ea6c; Grau #707070; Grau hell #a1a1a1; Tinte #0d2433; Anthrazit #171e26; Hellgrau #f4f6f7; Weiß #ffffff. Einzelne Komponenten verwenden zusätzlich #a8d62a. Vor Vereinheitlichung gestalterisch abstimmen.
• Breiten: theme.json contentSize 900px, wideSize 1380px. CSS-Grundwerte: Inhaltsbreite 1380px, Lesebreite 760px. Konkrete Komponenten können enger sein.
• Abstände in theme.json: XS 8px, S 16px, M 24px, L 48px, XL 80px, XXL 128px, 3XL 200px, 4XL 280px. customSpacingSize=false; angebotene Einheiten px, rem, %, vw und vh. Die Preset-Steuerung erklärt den begrenzten Regler, garantiert aber nicht, dass jede CSS-Regel übersteuerbar ist.
• CSS-Grundwerte: Section-Abstand clamp(72px, 8vw, 128px), Gutter 56px, Hero-Höhe 716px. Diese Werte sind Basen; media queries und Komponentenregeln können sie überschreiben.
• Technischer Altbestand: theme.json bietet Inter, Source Sans 3, Myriad Pro Light und Myriad Pro Semibold an. Die Referenzseite verwendet ausdrücklich Segoe UI Light 300; die alten Deklarationen sind keine neue Gestaltungsvorgabe. Das CSS setzt auf Unterseiten grundsätzlich Myriad Pro Light für Text und Myriad Pro Semibold für Überschriften; einzelne Komponenten überschreiben dies.
• History-Fließtext: Segoe UI Light, Segoe UI, Source Sans 3, sans-serif; 16,5px; Gewicht 300; geerbter Zeilenfaktor 1,6, rechnerisch 26,4px. Desktop-Jahreszahlen 18px/400; Accordion-Titel 20px/365. Unter 700px Jahreszahlen 15px.
• Font-Befund: Die geprüften Theme-Dateien inter-latin-300-500.woff2, source-sans-3-latin-400-600.woff2 und MyriadPro-Light.woff liefern HTTP 404. Lokal fehlt assets/fonts. Die deklarierten Schriftfamilien beweisen daher keinen tatsächlich gerenderten Schnitt. Segoe UI Light hängt von der Installation auf dem Endgerät ab.
• Für einen reproduzierbaren Neuaufbau Font-Dateien und Weblizenzen sichern, Fallbacks definieren und tatsächlich geladene Fonts prüfen. Myriad-Nutzung ist keine nachgewiesene Lizenzfreigabe.
• Responsive Logik ist komponentenbezogen. History-Desktop-Grid ab 900px, History-Header-Umschlag unter 700px; andere Komponenten verwenden weitere Breakpoints. Verbindliche Prüfansichten: 1920, 1440, 1024, 768 und 390px.

• Unterseiten-Bausteine: Cover, Gruppe, Spalten/Spalte, Bild, Überschrift, Absatz, Buttons/Button, Liste/Listenelement und Abstandshalter. Über uns und Karriere bestehen laut gespeichertem Quelltext aus diesen Standardblöcken.
• Patterns sind redaktionelle Startpunkte. Ihre Abschnitte sollen verschiebbar, duplizierbar und löschbar bleiben. Wiederkehrende globale Inhalte über synchronisierte Patterns pflegen.
• Über uns: Cover-Hero mit Schlossbild → Unsere Haltung → Unsere Geschichte. Geschichte enthält Headline, fünf Zeitabschnitte mit Texten und AJ-/Olaf-Portraits.
• History-Vertrag: Zeitabsatz mit Klasse about-history__period unmittelbar vor Überschrift about-history__chapter; beide mit den zugehörigen Absätzen innerhalb about-history__copy. functions.php wandelt diese Struktur auf Seite 98 im Frontend in native details/summary-Elemente um.
• History-Verhalten: Zeitpunkte als Buttons mit aria-controls und aria-expanded; Öffnen eines Abschnitts schließt andere. Plus/Minus und Punktzustände entstehen durch CSS/JavaScript. Ohne diese Erweiterung stehen die redaktionellen Inhalte weiterhin im Ausgangsmarkup.
• History-Stationen: 1968–1988 / GEMEINSAME ANFÄNGE; 1991–2017 / DER BERUFLICHE WEG; 2017–2019 / ABSCHIED UND NEUANFANG; 2019–2025 / DER WANDEL ZUR doIT; 2026 / FÜHRUNG IN NEUER HAND.
• History-Desktop im lokalen Stand 1.4.166: copy margin-top = clamp(20px, 2.5vw, 36px) + 5px; Portraitgruppe = derselbe clamp-Wert + 36px; Folgezeilen erhalten 16px margin-top. Ziel ist Ausrichtung der tatsächlichen Bildkanten an erster und letzter Jahreszeile im geschlossenen Zustand. Bildgruppe einschließlich Unterschriften ist nicht dasselbe wie die reine Bildfläche; die abschließende visuelle Abnahme dieser Ausrichtung bleibt offen.
• Die Portraits sollen beim Accordion-Wechsel ihre Position halten. Bildgröße, Originale, Zuschnitt, Reihenfolge AJ vor Olaf und Bildunterschriften bleiben redaktionell geschützt vor unbeabsichtigter Änderung.
• Karriere: Hero → Wirkung der Arbeit mit sechs Nutzenpunkten → Zusammenarbeit und Anforderungen → offene Stellen und Initiativbewerbung → dreistufiger Bewerbungsablauf. Anker #offene-stellen und #initiativ erhalten.
• Karriere-Karten nutzen vorhandene Gutenberg-Gruppen/Spalten; zusätzlicher Code macht Stellenkarten über ihren Link klickbar. Initiativbewerbung öffnet derzeit ein mailto an info@doit.gmbh, kein nachgewiesenes Bewerbungsformular.
• Header-Altbestand außerhalb dieser Referenz: automatische Ausblendung beim Scrollen und Anfasser. Für die hier dokumentierte Überroll-Variante gilt dagegen das oben beschriebene Verhalten ohne automatische Ausblendung. Die neue Variante wird ausdrücklich über den Cover-Stil aktiviert und verändert andere Seiten nicht.
• Footer: Telefonnummer, E-Mail, Adresse, Geschäftszeiten, Leistungen, Einstiegspunkte, Unternehmenslinks und Unternehmensangaben. Die aktuellen Angaben werden übernommen, ihre fachliche Aktualität muss die Redaktion bestätigen.
• Kontakt und Interessenteneinstiege nutzen derzeit nachgewiesene Telefon-/E-Mail-Links. SMTP-Plugin-Aktivierung allein belegt weder ein Formular noch erfolgreiche Zustellung.

Die folgenden Originale wurden in der Mediathek identifiziert. Zusätzliche Cover-Hintergründe können als CSS-Hintergrund eingebunden sein und erscheinen nicht zwingend als img-Element. Für einen vollständigen Wiederaufbau die gesamte Mediathek samt Metadaten und Varianten sichern.

Bei allen sechs geprüften Medieneinträgen ist alt_text leer. Sinnvolle Alternativtexte oder eine bewusste dekorative Kennzeichnung müssen redaktionell entschieden werden. Nutzungsrechte und Originalquellen sind separat zu belegen.

• Medien-ID 1844: 2026/07/Schloss3-scaled.png — 2560 × 1196px — https://doit.gmbh/wp-content/uploads/2026/07/Schloss3-scaled.png
• Medien-ID 1998: 2026/08/Olaf_1366x2048.jpg — 1366 × 2048px — https://doit.gmbh/wp-content/uploads/2026/08/Olaf_1366x2048.jpg
• Medien-ID 1999: 2026/08/AJ_1366x2048.jpg — 1366 × 2048px — https://doit.gmbh/wp-content/uploads/2026/08/AJ_1366x2048.jpg
• Medien-ID 1704: 2026/07/ChatGPT-Image-30.-Juli-2026-06_42_23-1.png — 1942 × 809px — https://doit.gmbh/wp-content/uploads/2026/07/ChatGPT-Image-30.-Juli-2026-06_42_23-1.png
• Medien-ID 1420: 2026/07/mari-helin-ilSnKT1IMxE-unsplash-1-1-scaled.jpg — 2560 × 1706px — https://doit.gmbh/wp-content/uploads/2026/07/mari-helin-ilSnKT1IMxE-unsplash-1-1-scaled.jpg
• Medien-ID 1428: 2026/07/22661-20211013_132841-scaled.jpg — 2560 × 1920px — https://doit.gmbh/wp-content/uploads/2026/07/22661-20211013_132841-scaled.jpg

• Fehlende Font-Dateien: drei geprüfte referenzierte Dateien liefern 404. Die lokale Arbeitskopie enthält keinen Font-Ordner. Vor dem nächsten vollständigen Theme-Paket Bestand, lizenzierte Originale und Paketvollständigkeit klären.
• Links /karriere/it-systemadministrator/, /karriere/it-vertriebsmitarbeiter/ und /leistungen/geschaeftsprozess-optimierung liefern in der aktuellen HTTP-Prüfung 404. Zielseiten oder Weiterleitungen festlegen. Die Navigation /it-betreuung muss ebenfalls gegen die vollständige URL-Liste geprüft werden.
• Geschäftsprozesse ist aktuell eine zusätzliche programmierte Unterseite. Für das Gutenberg-Ziel benötigt sie einen eigenen Migrationsschritt; dieser Auftrag verändert sie nicht.
• Die älteren Aussagen „keine Inline-Styles“, „keine seitenbezogenen Regeln“ und „alle Unterseiten vollständig standardmäßig editierbar“ treffen so nicht auf den Bestand zu. Gutenberg erzeugt selbst Style-Attribute; zusätzlich gibt es spezifische CSS-Regeln und Skriptverhalten.
• History-Ausführung ist an Seite 98 gebunden. Ein Duplikat mit neuer ID erhält nicht automatisch dieselbe Funktion. Für einen Neuaufbau klassengebundene, wiederverwendbare Komponenten vorsehen und Standard-Gutenberg/Blocksy vor eigenen Blöcken prüfen.
• Gutenberg soll maßgeblich für redaktionelle Breiten, Blockabstände und Reihenfolge bleiben. Bestehende !important-Regeln, Layoutselektoren und Editor-Sonderlogik sind beim Neuaufbau systematisch gegen echte Editor-Einstellungen zu prüfen.
• Die reine Computed-Style-Meldung „font-weight: 300“ beweist keinen verfügbaren Light-Font. Ebenso beweist die Messung der Portraitgruppe keine Übereinstimmung der eigentlichen Bildkanten.
• Die bestehende Datenschutzseite enthält Abschnitte zu Google Web Fonts, Google Maps und Kontaktformular. Ob diese Beschreibungen den tatsächlich eingesetzten Diensten entsprechen, muss separat geprüft werden; hier findet keine rechtliche Bewertung statt.
• Noch benötigt: Hosting-Verantwortliche, PHP-/Datenbankversion, vollständige Serverdateien, DNS-/TLS-Verwaltung, SMTP-Verfahren ohne Geheimnisse, Backup-Zyklus und Wiederherstellungsnachweis, Staging-Verfahren, redaktionelle Rollen, Bild-/Fontlizenzen sowie Verantwortliche für Rechts- und Unternehmensangaben.
• Prioritäten zur Prüfung: Positionierung und Seitenreihenfolge bestätigen; vollständige Ziel-URL-Liste festlegen; Schriften und Medienrechte klären; anschließend Komponenten und Abnahme definieren. Offene Punkte sind dokumentiert, nicht im Rahmen dieser Dokumentation behoben.

• Bestand sichern: Datenbank mit Seiten, Revisionen, Blocksy-Optionen, Navigation und synchronisiertem Footer; komplette Uploads; aktives Child Theme; Parent Theme und Plugins mit Versionen; serverseitige Konfiguration getrennt und geschützt.
• Eine getrennte, nicht öffentliche Entwicklungsumgebung aufsetzen. Live-Texte, IDs, Medienzuordnungen und URLs inventarisieren, bevor neue Strukturen entstehen.
• Zuerst zentrale Palette, lizenzierte Fonts, Typografie, Abstands-Presets und Komponenten erstellen. Keine neuen Inhalte in PHP/JavaScript fest einbauen. Gutenberg-Werte müssen sinnvolle Theme-Vorgaben überschreiben können.
• Repräsentative Seiten umsetzen: eine Leistungsdetailseite, Über uns, Karriere und eine Rechtstextseite. Anschließend weitere Inhalte migrieren; Sonderfälle Startseite und Geschäftsprozesse ausdrücklich planen.
• Je neuer Seite dokumentieren: verwendete Blöcke/Patterns; im Backend editierbare Inhalte; verschiebbare/duplizierbare Elemente; zentrale Styles; verbleibende hart codierte Inhalte.
• 1920, 1440, 1024, 768 und 390px prüfen: Texte, Umbrüche, Bildkanten, Abstände, Navigation, kein horizontaler Überlauf. Accordion geschlossen/geöffnet, Tastatur, Fokus, Header-Anfasser und Fallbacks überprüfen.
• Redaktioneller Test: eine Gruppe verschieben und duplizieren, Text/Bild austauschen, Spaltenbreite und Blockabstand ändern. Editor und Frontend müssen sich nachvollziehbar gleich verhalten.
• Kontakt/Bewerbung kontrolliert mit freigegebenem Test prüfen. Quick-Check nur nach bestätigter Auswertung und Datenverarbeitung umsetzen. Interne Links, Weiterleitungen, Metadaten, Sitemap und private Seitenzugriffe testen.
• Die bisherige Bereitstellung erfolgte durch versioniertes Child-Theme-ZIP im WordPress-Theme-Upload. Für künftige Updates zuerst vollständiges Paket und Backup prüfen, anschließend sichtbares Ergebnis kontrollieren. Ein erfolgreicher Upload ersetzt keinen Funktionstest.
• Diese Dokumentationsseite bleibt privat. Berechtigte WordPress-Benutzer können sie lesen; bloße Anmeldung irgendeines Kontos reicht nicht. Keine öffentliche Navigation, kein frei zugänglicher Export und keine Zugangsdaten im Text.

Verwendet werden Cover, Gruppen, Spalten, Bilder, Überschriften, Absätze, Listen und Details. Jeder Inhaltsabschnitt ist als Gruppe verschiebbar, duplizierbar und löschbar. Texte, Links, Zeitangaben, Bildunterschriften und Medien sind direkt in Gutenberg editierbar.

Wiederverwendbare Muster werden als nicht synchronisierte WordPress-Patterns gespeichert. Eingefügte Instanzen bleiben unabhängig redaktionell änderbar. Die Styles liegen zentral im Child Theme und in dessen Editor-Stylesheet; keine Seiten-ID-Overrides und keine neuen Inline-Styles.

Es wurden keine Seiteninhalte in PHP oder JavaScript hinterlegt. Das Hero-Bild besitzt noch die bereits vorhandene, von Gutenberg gespeicherte Hintergrundposition. Header und Footer bleiben die bestehenden Website-Komponenten. Die Seite bleibt privat und wird nicht ins öffentliche Menü aufgenommen.