Technisches SEO Audit: Die QA-Checkliste für Entwickler

Ein Technisches SEO Audit ist oft etwas, das man nach dem Launch macht. Meistens dann, wenn der SEO-Manager panisch anruft, weil die Rankings eingebrochen sind. Der Grund ist fast immer derselbe: Ein Hotfix wurde deployed, die App läuft fehlerfrei, aber "unter der Haube" hat sich ein Fehler eingeschlichen. Vielleicht wurde das noindex-Tag aus der Staging-Umgebung versehentlich mit auf Live geschoben. Oder ein React-Update hat die H1-Überschriften zerschossen.

Das Problem an SEO ist: Es wirft keine Exceptions. Die App stürzt nicht ab. Sie wird nur unsichtbar. Deshalb müssen wir umdenken. SEO darf keine manuelle Aufgabe sein, die man "irgendwann mal" macht. Es muss Teil unserer Definition of Done sein – hart codiert in der Build-Pipeline.

Warum manuelle Audits scheitern

Wir Entwickler sind faul (im positiven Sinne). Wenn wir eine Checkliste manuell abarbeiten müssen, machen wir das beim ersten Mal gründlich. Beim zweiten Mal schnell. Und beim dritten Mal vergessen wir die Hälfte. Manuelle technische SEO Audits skalieren nicht. Ihr könnt nicht vor jedem Deployment 500 Unterseiten per Hand prüfen.

Die Lösung ist Lighthouse CI. Jeder kennt den Lighthouse-Tab in den Chrome DevTools. Aber wusstet ihr, dass man dieses Tool auch headless im Terminal laufen lassen kann?

Schritt 1: Lighthouse CI installieren

Installiert das Tool global oder als Dev-Dependency in eurem Projekt:

npm install -g @lhci/cli

Schritt 2: Die Konfiguration (lighthouserc.js)

Erstellt eine Konfigurationsdatei im Root-Verzeichnis. Hier definieren wir die Schmerzgrenze. Wir sagen: "Wenn der SEO-Score unter 90 fällt, ist der Build kaputt."

JavaScript

1module.exports = {
2  ci: {
3    collect: {
4      // Welche URLs sollen getestet werden?
5      url: ['http://localhost:3000/', 'http://localhost:3000/about'],
6      startServerCommand: 'npm run start', // Server starten
7    },
8    assert: {
9      assertions: {
10        // SEO Score muss 100 sein (1.0)
11        'categories:seo': ['error', { minScore: 1.0 }],
12        // Performance muss mindestens 90 sein
13        'categories:performance': ['error', { minScore: 0.9 }],
14        // Spezifische Checks: Ist die Seite crawlbar?
15        'is-crawlable': 'error',
16      },
17    },
18    upload: {
19      target: 'temporary-public-storage',
20    },
21  },
22};

Die Pipeline: GitHub Actions Integration

Jetzt bringen wir das Ganze in die Cloud. Wir wollen, dass bei jedem Pull Request automatisch ein technisches SEO Audit läuft. Wenn der Junior-Dev versehentlich die Meta-Descriptions löscht, soll der Merge-Button rot werden.

Hier ist ein Beispiel-Workflow für GitHub Actions (.github/workflows/seo-audit.yml):

YAML

1name: CI SEO Audit
2on: [push]
3jobs:
4  seo-check:
5    runs-on: ubuntu-latest
6    steps:
7      - uses: actions/checkout@v3
8      - name: Use Node.js
9        uses: actions/setup-node@v3
10        with:
11          node-version: 18
12      - run: npm install
13      - run: npm run build
14      
15      # Hier läuft der SEO Test
16      - name: Run Lighthouse CI
17        run: lhci autorun
18        env:
19          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Das war's. Ab jetzt ist SEO Teil eurer Unit-Tests.

Beyond Lighthouse: Was noch getestet werden muss

Lighthouse ist super für Performance und Basics. Aber es versteht eure Business-Logik nicht. Es weiß nicht, ob auf der Produktseite zwingend ein Canonical-Tag sein muss, der auf sich selbst zeigt.

Für solche spezifischen Regeln im technischen SEO Audit empfehle ich End-to-End Testing Tools wie Cypress oder Playwright.

Beispiel: Canonical-Tag Prüfung mit Cypress

JavaScript

1describe('SEO Critical Checks', () => {
2  it('Should have a self-referencing canonical tag', () => {
3    cy.visit('/produkte/super-schuhe');
4    
5    // Prüfen, ob der Tag existiert und die richtige URL hat
6    cy.get('link[rel="canonical"]')
7      .should('have.attr', 'href', 'https://example.com/produkte/super-schuhe');
8  });
9
10  it('Should NOT have noindex on product pages', () => {
11    cy.visit('/produkte/super-schuhe');
12    cy.get('meta[name="robots"]').should('not.exist');
13  });
14});

Mit diesen Tests schlaft ihr ruhiger. Ihr wisst garantiert, dass eure wichtigsten SEO-Elemente vorhanden sind, egal was im Frontend-Code geändert wurde.

Fazit: Vertrauen ist gut, CI ist besser

Ein Technisches SEO Audit ist keine einmalige PDF-Datei, die eine Agentur schickt. Es ist ein kontinuierlicher Prozess. Code ändert sich täglich, also muss auch die SEO-Prüfung täglich laufen.

Indem ihr diese Checks automatisiert, befreit ihr euch von der Angst vor dem "SEO-Unfall". Ihr gebt dem Marketing-Team die Sicherheit, dass die Technik steht – und ihr könnt euch wieder auf das konzentrieren, was Spaß macht: Features bauen.

Wir haben jetzt die Architektur, das Rendering, die Daten und die Tests im Griff. Zum Abschluss dieser Serie habe ich noch ein besonderes Schmankerl für euch.