Cursor .cursorignore: Vollständiger Leitfaden – 3 Strategien für Index-Optimierung in großen Projekten

Aktualisiert am 2026-06-08: Gegen Cursors offizielle Docs (Juni 2026) geprüft. Cursor respektiert bereits .gitignore plus eine eingebaute Standard-Ignore-Liste (node_modules, Lockfiles, Build-Artefakte, Binär-/Mediendateien werden meist schon nicht indexiert), daher ist .cursorignore vor allem eine harte Zugriffssperre plus Zusatz-Ausschlüsse; .cursorindexingignore blockiert nur die Indexierung, per @-Erwähnung bleibt die Datei lesbar. Außerdem ist die einzelne Root-Datei .cursorrules jetzt legacy (im Agent-Modus ignoriert) — Projektregeln gehören in .cursor/rules/*.mdc.

Letzten Dienstagnachmittag öffnete ich das Firmen-Monorepo mit über 500.000 Zeilen Code. Unten rechts drehte sich das Syncing-Symbol von Cursor. Nach 5 Minuten noch aktiv. Nach 10 Minuten immer noch Indexierung. Ich holte einen Kaffee – beim Zurückkommen drehte sich das Icon weiter.

Schlimmer kam danach: Nach dem Index bat ich die KI, eine React-Komponente zu optimieren. Der Vorschlag: „Ändern Sie direkt node_modules/react-dom/cjs/react-dom.development.js.“ Drei Sekunden Stille vor dem Bildschirm – die KI hielt Dependency-Code für Projektcode.

Kurz dachte ich, Cursor taugt nicht für große Repos. Dann entdeckte ich .cursorignore – und vieles änderte sich: Index von 12 auf 3 Minuten, keine Empfehlungen mehr, node_modules anzufassen.

Wenn Sie langsame Indizes oder falsches KI-Verständnis kennen, hilft dieser Artikel. Drei sofort wirksame Strategien plus eine kopierbare Vorlage.

Warum Ihr Cursor-Index so langsam ist

Cursor erstellt beim Öffnen Embeddings – eine numerische Repräsentation des Codes für die KI. Jede Datei wird gelesen, vektorisiert und gespeichert. Mehr Dateien bedeuten längere Wartezeit.

Die Frage: Muss die KI wirklich jede Datei verstehen?

In den meisten Projekten gibt es große, zahlreiche Verzeichnisse mit wenig Nutzen für KI-Assistenz:

node_modules – das Dependency-Loch
Ein mittleres Frontend-Projekt kann Zehntausende Dateien in node_modules haben. Cursor indexiert Third-Party-Code – brauchen Sie wirklich das Innenleben von lodash?

dist/build – Build-Müll
Komprimierte, oft einzeilige Bundles sind für die KI unlesbar und wertlos.

.git – Historie
Die Git-Historie kann Hunderte MB bis GB umfassen – reine Zeitverschwendung beim Index.

Große statische Assets
Videos, Bilder, Fonts – die KI kann sie nicht sinnvoll nutzen.

Test: Next.js-Projekt mit ~100.000 Zeilen, vollem node_modules und .next – Index ~8 Minuten. Mit .cursorignore für diese Ordner ~2 Minuten. Faktor vier.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Genauer wird es wichtig: Voller node_modules-Kontext verwirrt die KI – Vorschläge für Dependency-Dateien oder fremde APIs als eigene Funktionen.

.cursorignore – vollständige Konfiguration

Gute Nachricht: Die Syntax entspricht .gitignore. Wer Git-Ignore beherrscht, kann .cursorignore sofort schreiben.

Kurzüberblick Syntax

Im Projektroot .cursorignore anlegen (mit führendem Punkt):

# Kommentar mit #

# Einzelne Datei
config.json

# Verzeichnis (Schrägstrich am Ende)
node_modules/
dist/

# Wildcards
*.log          # alle Log-Dateien
**/*.test.js   # Tests in allen Ebenen

# Negation (wieder einschließen)
!important.log

Sofort nutzbare Vorlage

Basis-Konfiguration für die meisten Projekte:

# Dependencies
node_modules/
.pnp/
.pnp.js
vendor/
packages/

# Build-Artefakte
dist/
build/
out/
.next/
.nuxt/
.cache/
.vite/
.turbo/

# Tests & Coverage
coverage/
.nyc_output/
*.spec.js
*.test.js
__tests__/

# Logs & Temporäres
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.DS_Store
*.swp
*.swo
*~

# Umgebung (Sicherheit)
.env
.env.local
.env.*.local
credentials.json
*.key
*.pem

# Versionskontrolle
.git/
.svn/
.hg/

# IDE (optional)
.vscode/
.idea/
*.sublime-*

# Große Assets (anpassen)
*.mp4
*.mov
*.avi
*.zip
*.tar.gz
*.pdf
public/videos/

Deckt etwa 90 % ab. Danach: Einstellungen > Features > Codebase Indexing > Refresh.

Szenario-spezifische Erweiterungen

React/Vue – große Dateien unter public:

public/assets/
public/images/*.png
public/fonts/

Monorepo – nur relevante Pakete:

apps/mobile/
apps/admin/
packages/backend-utils/

Full-Stack – getrennte Sicht:

# Frontend-Fokus
server/
api/
database/
migrations/

# Backend-Fokus
client/
public/
src/components/

Unsicher, ob eine Datei ausgeschlossen ist:

git check-ignore -v [Dateipfad]

Gleiche Syntax wie bei Cursor – gut zum Debuggen.

.cursorignore vs. .cursorindexingignore

Zwei ähnliche Namen – welches Tool wann?

Kurz: .cursorignore = vollständige Sperre, .cursorindexingignore = nur kein Index.

Unterschied im Detail

.cursorignore: Kein Zugriff – nicht indexiert, nicht gelesen, nicht referenziert. Für Secrets (.env, Keys) und Unnötiges (node_modules, Builds).

.cursorindexingignore: Nicht in der Codebase-Suche, aber bei Bedarf lesbar (z. B. per @-Erwähnung oder Drag-and-drop). Später für Performance hinzugefügt, ohne harten Ausschluss.

Beispiel: Ordner legacy/ mit altem Code – nicht in jeder Suche, aber gelegentlich als Referenz nötig → .cursorindexingignore.

Szenario-Tabelle

Priorität

1. .gitignore (automatisch)
2. .cursorignore (mit ! überschreibbar)
3. .cursorindexingignore

Beispiel: logs/ in .gitignore, aber eine Debug-Log-Datei für die KI:

!logs/important-debug.log

Hierarchical Cursor Ignore (in den Einstellungen): Cursor liest auch .cursorignore in übergeordneten Ordnern – sinnvoll für Monorepo-Root plus Subprojekt-Regeln.

Praxis-Strategie

Meist reicht .cursorignore. .cursorindexingignore ist Feintuning für sehr große oder komplexe Repos.

Vorgehen:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

1. Nur .cursorignore mit klaren Ausschlüssen
2. Eine Woche beobachten
3. Bei Bedarf .cursorindexingignore ergänzen

Nicht zu früh überkomplizieren.

Drei Strategien für Monorepos

Monorepos überfordern Cursor leicht: Web, API, Mobile, Admin in einem Repo – die KI vermischt Grenzen.

Aus einem 12-App-Monorepo: KI empfahl eine Backend-Utility für Frontend – logisch klingend, aber zur Laufzeit nicht erreichbar.

Drei bewährte Ansätze:

Strategie 1: Index nach Arbeitsbereich

Einfachste Methode: alles ausschließen, was Sie nicht bearbeiten.

Frontend in apps/web:

# .cursorignore
apps/mobile/
apps/admin/
apps/api/
packages/backend-utils/
packages/database/
services/

Schnellerer Index, weniger Rauschen. Nur zwei eigene Pakete behalten: Index von 15 auf 4 Minuten.

Full-Stack-Wechsel: .cursorignore.frontend / .cursorignore.backend vorbereiten und je nach Task kopieren.

Strategie 2: Project Rules (.cursor/rules/)

Monorepo-Problem: Beziehungen zwischen Ordnern unklar. Lösung: Project Rules als „Karte”. Hinweis: Das alte Root-.cursorrules ist jetzt legacy und wird im Agent-Modus ignoriert — für neue Projekte .mdc-Dateien in .cursor/rules/ (nicht .cursorignore).

Im .cursor/rules/ eine Regeldatei (z. B. project-structure.mdc) mit YAML-Frontmatter (description, globs, alwaysApply):

---
description: Monorepo-Struktur und Referenzregeln
alwaysApply: true
---

# Projektstruktur

Monorepo mit:

- apps/web: Frontend (Next.js), Port 3000
- apps/api: Backend (Node.js + Express), Port 8000
- apps/admin: Admin (React), Port 3001
- packages/ui: Shared UI
- packages/utils: Shared Utils

## Referenzregeln

- web/admin nur packages/ui und packages/utils
- Frontend darf apps/api nicht direkt importieren
- packages/* dürfen nicht von apps/* abhängen

## Fokus

Aktuell apps/web – Vorschläge bitte nur Frontend.

Die KI liest das – deutlich weniger Cross-Boundary-Empfehlungen.

Strategie 3: Getrennte Fenster

Bei 20+ Sub-Apps reicht ein Fenster oft nicht.

• Fenster 1: apps/web
• Fenster 2: apps/api
• Fenster 3: packages/ui

Eigener Index und Kontext pro Fenster. Wechselkosten, aber höhere Trefferquote.

Abhängigkeit web → ui: in der Web-Session gezielt:

@folder packages/ui Prüfe die Button-Props-Definition

Leichtes Fenster, bei Bedarf Shared Code.

Kernidee Monorepo

Die KI soll nur sehen, was sie sehen muss.

Je größer das Repo, desto mehr weglassen. Grenzen setzen – dann passen die Vorschläge.

Konfiguration prüfen und pflegen

.cursorignore ist kein einmaliger Akt – prüfen und anpassen.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Wirksamkeit testen

Offensichtlich: Syncing-Dauer vor/nach der Konfiguration.

Genauer:

1. Index-Status
   Einstellungen > Features > Codebase Indexing – Dateianzahl sollte sinken.

2. KI-Kontext
   Mit @codebase fragen; nach Ausschluss von node_modules keine Komponenten aus node_modules/react.

3. Suche
   Cmd/Ctrl + P: Dateiname in ausgeschlossenem Ordner – sollte nicht erscheinen.

Wann manuell refreshen

Cursor aktualisiert inkrementell, aber Refresh nötig bei:

• Änderung an .cursorignore
• großem Branch-Wechsel
• massenhaftem Hinzufügen/Löschen
• spürbar veraltetem KI-Verständnis

Einstellungen > Features > Codebase Indexing > Refresh – warten bis Syncing fertig.

Laufende Pflege

Monatliche Checkliste:

• neue Build-Ordner (z. B. .output/ nach Framework-Upgrade)
• neue große Verzeichnisse
• tote Regeln entfernen

Team:

• Gemeinsam committen: node_modules, dist, .env, Framework-Caches
• Persönlich: Subprojekt-Ausschlüsse in .git/info/exclude oder .cursorignore.local

In .gitignore:

.cursorignore.local

Kommentare in .cursorignore helfen später:

# 2025-01-15: AI-Trainingsdaten – zu groß, kein Index
data/training/

# 2025-01-10: Performance-Tests mit vielen Logs
perf-tests/

Weiterführend

• Cursor-Codebase-Indexierung – der vollständige Leitfaden: Prinzipien, Konfiguration & @-Symbol
• Cursor in großen Projekten: den Agent in großen Repos nicht verlieren
• Cursor-Gratiskontingent – der vollständige Leitfaden

Zusammenfassung

Langsame Indizes und falsche KI-Tipps sind selten ein Tool-Problem – oft fehlt die Information, worauf die KI achten soll.

.cursorignore ist einfach und wirksam: wenige Minuten Setup, Monate weniger Wartezeit und treffendere Vorschläge.

Drei Schritte:

1. Jetzt: Basis-Vorlage aus diesem Artikel im Projektroot anlegen
2. Anpassen: React/Vue/Monorepo-Regeln ergänzen
3. Iterieren: eine Woche beobachten, Probleme notieren, Konfiguration verfeinern

Perfektion beim ersten Mal ist unnötig – 80 % mit der Basis, 20 % im Alltag.

Nutzen Sie Cursor in großen Projekten? Teilen Sie gern Erfahrungen oder offene Fragen in den Kommentaren – vielleicht hilft es anderen mit dem gleichen Syncing-Spinner.