Seitencache für Odoo: Shop und Blog aus RAM oder Datei – schnell für Besucher, Suchmaschinen und KI

10. November 2026  |  Eigenentwicklung  |  Odoo, Performance und Suchmaschinen

Eine Odoo-Webseite rendert jede Seite bei jedem Aufruf neu: Datenbankabfragen, Templates, Übersetzungen, Preise. Für einen einzelnen Besucher ist das unauffällig. Wenn aber Suchmaschinen und KI-Indexer Hunderte oder Tausende Seiten in vielen Sprachen abrufen, wird daraus Dauerlast, und echte Kunden warten mit. Wir haben dafür das Odoo-19-Modul website_page_cache entwickelt und als Open Source (LGPL-3) auf GitHub veröffentlicht: Anonym aufgerufene Shop- und Blogseiten kommen quasi statisch aus einem Cache, entweder aus Dateien oder aus dem Arbeitsspeicher (RAM), und jede Änderung – auch an einer Übersetzung – entfernt die betroffenen Seiten automatisch wieder aus dem Cache.

Wichtig für alle, die gefunden werden wollen: Das Modul sperrt keine Suchmaschine und keinen KI-Crawler. Alle Indexer bekommen dieselben Inhalte wie jeder Besucher, nur schneller. Dieser Beitrag erklärt, wie der Cache arbeitet, wie das Dashboard aussieht (mit Bildschirmfotos), wie Sie erkennen, ob Ihre Seiten in den Arbeitsspeicher passen und wie viel RAM zusätzlich nötig wäre, welche Sicherheitsregeln gelten und wie Sie das Modul installieren.

Kurzfassung

Das Problem: Crawler-Last auf Odoo-Webseiten

Odoo ist ein vollständiges ERP-System, die Webseite ist eines von vielen Modulen. Jede Seite, die ein Besucher oder ein Roboter aufruft, durchläuft denselben Weg: Anfrage verarbeiten, Datenbank befragen, Produkt- und Preisdaten laden, das QWeb-Template rendern, Übersetzungen einsetzen und das Ergebnis ausliefern. Das dauert je nach Seite einige Hundert Millisekunden und belegt in dieser Zeit einen der wenigen Arbeitsprozesse.

Für Suchmaschinen und KI-Indexer ist das ein Dauerthema:

• Viele Sprachen, viele Adressen: Eine Seite, die in 46 Sprachen vorliegt, sind für einen Crawler 46 verschiedene Adressen.
• Jede Adresse wird einzeln abgerufen, oft von vielen verteilten Absendern gleichzeitig. Ein klassischer Browser-Cache hilft dabei nicht, weil jeder Abruf eine neue Adresse betrifft.
• Wenige Arbeitsprozesse: Ein Odoo-Dienst läuft typischerweise mit einer Handvoll Prozessen. Sind sie mit Crawler-Anfragen belegt, warten echte Besucher in der Schlange.
• Gleicher Inhalt, immer wieder neu: Ein Blogbeitrag ändert sich selten, wird aber bei jedem Abruf aufwendig neu zusammengebaut.

Der naheliegende Ausweg – Crawler aussperren – ist für eine Firma, die gefunden werden will, keine Option. Sichtbarkeit in Suchmaschinen und in KI-Antworten ist wertvoll. Besser ist es, die Seiten so schnell auszuliefern, dass die Last kaum noch ins Gewicht fällt. Genau das macht der Seitencache.

So funktioniert der Seitencache

Das Modul hängt sich an den Anfrage-Eingang von Odoo (ir.http). Bei jedem Seitenabruf entscheidet es in Bruchteilen einer Millisekunde, ob die Seite aus dem Cache kommen darf, und liefert sie dann ohne Datenbank, ohne Template und ohne Rendering aus.

1. Prüfung: Nur ein anonymer GET-Abruf ohne Suchparameter auf einem erlaubten Pfad (Shop, Kategorien, Produkte, Blog) kommt in Frage. Alles andere läuft wie immer durch Odoo.
2. Cache-Schlüssel: Er besteht aus Webseite, Host, Sprache, Pfad, Preisliste, Steuerposition und dem Cookie-Zustimmungsstatus. Besucher, die etwas anderes sehen würden, teilen sich deshalb nie einen Eintrag.
3. Treffer: Gibt es einen aktuellen Eintrag, wird er ausgeliefert. Das CSRF-Token in der Seite wird dabei pro Anfrage neu gesetzt. Aufrufe von Blogbeiträgen werden weiter gezählt.
4. Fehlgriff: Fehlt der Eintrag oder ist er veraltet, rendert Odoo die Seite wie gewohnt. Ist das Ergebnis cachefähig (Status 200, HTML, kein Cookie, keine Sitzungs-ID im Text), wird es gespeichert; der nächste Abruf ist ein Treffer.
5. Sichtbar im Header: Jede Antwort trägt den Header X-Page-Cache: HIT oder MISS. So lässt sich mit jedem Werkzeug prüfen, was passiert ist.

Wie viel schneller?

In unserem Testsystem (Kopie unserer Webseiten, einige Hundert Seiten) lag die durchschnittliche Renderzeit einer Seite bei rund 490 Millisekunden, die Auslieferung aus dem Cache bei rund 23 Millisekunden: etwa das Zwanzigfache. Je aufwendiger eine Seite ist, desto größer der Gewinn. Das Dashboard rechnet aus beiden Werten außerdem die geschätzt gesparte Serverzeit aus.

Datei oder RAM: Speicherort wählen

Der Cache kennt zwei Speicherorte. Beide sind für alle Odoo-Arbeitsprozesse gemeinsam sichtbar, jede Seite liegt also nur einmal vor, nicht einmal je Prozess.

Für die meisten Installationen ist Automatisch die richtige Wahl: Sie bekommen RAM-Geschwindigkeit, wenn der Platz da ist, und fallen sonst ohne Eingriff auf Dateien zurück.

Passt die Webseite in den Arbeitsspeicher? Und wie viel RAM fehlt?

Ob ein RAM-Cache möglich ist, hängt von drei Dingen ab: von der Zahl der Seiten, von ihrer durchschnittlichen Größe und vom verfügbaren Speicher. Das Dashboard rechnet das für Sie vor:

• Seitenzahl: Pro Webseite zählt es veröffentlichte Produkte, Shop-Listenseiten, Kategorien, Blogbeiträge und Bloglisten und multipliziert mit der Anzahl der Sprachen.
• Seitengröße: Sobald Seiten im Cache liegen, wird der tatsächliche Durchschnitt gemessen; bis dahin gilt ein Annahmewert.
• Platz für den Cache: der kleinste Wert aus dem eingestellten RAM-Budget, der Größe des tmpfs und der Hälfte des verfügbaren Arbeitsspeichers. Der Server soll nie wegen des Caches in Speichernot geraten.
• Urteil: „passt mit Reserve“, „knapp“, „zu groß“ oder „RAM-Cache nicht verfügbar“. „Passt“ gilt, wenn der Bedarf höchstens 80 Prozent des verfügbaren Platzes beträgt.

Neu: Wie viel zusätzlicher RAM wäre nötig?

Passt der Cache nicht, will man wissen, was man ändern muss. Das Dashboard nennt deshalb unter dem Urteil eine konkrete Zeile: „Zusätzlicher RAM für einen RAM-Cache: etwa … mehr Arbeitsspeicher auf diesem Server“ – oder „keiner“, wenn der Platz bereits reicht. Falls statt des Servers nur eine Einstellung zu klein ist, steht darunter, welche: das RAM-Budget des Moduls oder die Größe des tmpfs (/dev/shm).

Die Rechnung dahinter ist einfach und nachvollziehbar:

1. Bedarf = Seiten × durchschnittliche Seitengröße.
2. Mit Reserve = Bedarf geteilt durch 0,8. Dieser Wert muss ins RAM-Budget und ins tmpfs passen, damit das Urteil „passt“ lautet.
3. Freier Speicher: Weil der Cache höchstens die Hälfte des verfügbaren Arbeitsspeichers nutzen darf, braucht der Server mindestens das Doppelte des Werts aus Schritt 2 als frei verfügbaren Speicher. Fehlt etwas, ist die Differenz der zusätzlich nötige RAM.

Das Beispiel im Bild (12.000 Seiten zu je 25 KB) ist eine Rechenhilfe, keine Messung unserer Seiten. Bei kleinen Webseiten genügen schon wenige Dutzend Megabyte; die Beispieldaten in den Bildschirmfotos kamen mit rund 13 MB aus.

Wichtig zur Einordnung: Die Schätzung zählt keine zusätzlichen Preislisten- oder Länderfassungen. Wer viele davon nutzt, plant etwas Reserve ein. Und: Ein zu kleines RAM-Budget ist der häufigste Grund, warum die Automatik bei Dateien bleibt – nicht fehlender Arbeitsspeicher. Das Dashboard zeigt in diesem Fall genau diese Zeile an.

Änderungen und Übersetzungen räumen den Cache auf

Ein Cache ist nur dann brauchbar, wenn er nie veraltete Seiten ausliefert. Ein reines Zeitlimit („alle zwölf Stunden verwerfen“) wäre zu grob: Ein geänderter Preis oder ein korrigierter Tippfehler müsste bis zu zwölf Stunden warten. Das Modul arbeitet deshalb inhaltsbezogen.

1. Datenbank-Trigger: Auf allen Tabellen, die eine Seite beeinflussen können (Produkte, Varianten, Bilder, Bestand, Attribute, Kategorien, Preise, Steuern, Preislisten, Blogbeiträge und Schlagwörter, Partner- und Firmendaten, Ansichten, Assets, Menüs, Sprachen, Webseiten-Einstellungen), sitzen PostgreSQL-Trigger. Sie tragen jede Änderung in ein Änderungsjournal ein.
2. Abhängigkeiten und Datenbankstand: Jede gecachte Seite merkt sich, welche Datensätze sie zeigt, und den Datenbankstand, mit dem sie erzeugt wurde.
3. Abgleich: Gibt es einen Journaleintrag, der nach diesem Stand entstand und einen dieser Datensätze betrifft, ist die Seite veraltet.
4. Neu cachen: Beim nächsten Abruf wird die veraltete Seite verworfen, neu gerendert und wieder gespeichert.

Auch Übersetzungen sind abgedeckt

Odoo 19 speichert übersetzte Texte im selben Datensatz wie den Originaltext (als JSON-Feld). Eine geänderte Übersetzung ist für die Datenbank daher eine ganz normale Zeilenänderung – und der Trigger sieht sie. Das gilt gleichermaßen für die Bearbeitung über die Oberfläche, für Importe, für Schnittstellen und für Skripte, die direkt in die Datenbank schreiben. Eine automatische Übersetzung von 46 Sprachen entwertet also genau die Seiten, deren Text sich geändert hat, und nicht mehr.

• Gezielt statt pauschal: Ein geändertes Produkt entwertet dessen Seiten, die Listen, in denen es steht, und die zugehörige Kategorie. Der Rest bleibt im Cache.
• Globale Änderungen (Templates, Assets, Sprachen, Menüs, Steuern, Währungen) entwerten alles auf einmal, weil sie jede Seite betreffen können.
• Zähler bleiben außen vor: Der Aufrufzähler von Blogbeiträgen ändert sich bei jedem Besuch; er löst bewusst keine Entwertung aus, sonst wäre der Cache bei beliebten Beiträgen wirkungslos.
• Sicherheitsnetz: Zusätzlich gibt es ein Höchstalter je Seite (Standard 12 Stunden).
• Kein Schreibfehler durch den Cache: Ein Fehler innerhalb eines Triggers wird als Warnung protokolliert und lässt die eigentliche Speicherung nicht scheitern.

Dashboard und Statistik

Alles, was Sie zum Betrieb brauchen, steht an einer Stelle: in Odoo unter Website → Berichte → Seitencache. Der Abschnitt Übersicht ist das Dashboard (mit den Einstellungen), der Abschnitt Verlauf zeigt die Zahlen je Tag und Webseite.

Bildschirmfoto aus einem Testsystem mit Kopien unserer Webseiten; die Webseitennamen wurden durch Platzhalter ersetzt.

Einstellungen

Status und Statistik

Der Status zeigt den aktiven Speicherort samt Grenze, die Zahl und Größe der gecachten Seiten und die Änderungsverfolgung: wie viele Änderungen in den letzten 24 Stunden registriert wurden und wie viele Tabellen überwacht werden. Fehlt eine Überwachung, warnt das Dashboard deutlich, denn dann darf dem Cache nicht vertraut werden. Die Schaltflächen oben erlauben, die Wartung sofort auszuführen, den Cache zu leeren oder die Trigger zu prüfen und bei Bedarf neu anzulegen.

Die Statistik (Heute, 7 Tage, 30 Tage) enthält:

• Aus dem Cache und Gerendert: Treffer und Fehlgriffe, daraus die Trefferquote
• Entfernt (geändert/abgelaufen): wie viele Seiten wegen Änderung oder Ablauf verworfen wurden
• Renderzeit und Cache-Zeit: der Durchschnitt je Seite im Vergleich
• Geschätzt gesparte Serverzeit und Datenmenge aus dem Cache

Die Zahlen sammelt jeder Arbeitsprozess für sich und schreibt sie einmal pro Minute; Zeilen, die älter als 90 Tage sind, räumt der Wartungsjob ab.

Verlauf als Diagramm, Pivot und Liste

Unter Verlauf stehen die Tageswerte je Webseite zur Verfügung – als Diagramm, als Pivot-Tabelle oder als Liste. So sehen Sie, ob die Trefferquote nach einem Neustart oder nach einer großen Änderung wieder steigt, und welche Webseite den meisten Verkehr aus dem Cache erhält.

Sicherheit: Was nie aus dem Cache kommt

Ein Seitencache darf nie dazu führen, dass jemand die Inhalte eines anderen sieht. Das Modul geht deshalb nach dem Grundsatz vor: Im Zweifel nicht cachen.

• Nur anonyme Besucher: Wer angemeldet ist, einen Warenkorb hat oder einen anderen Sitzungszustand mitbringt, bekommt immer die normal gerenderte Seite.
• Nur GET ohne Suchparameter: Suchen, Filter, Sortierungen, Formulare, Warenkorb und Kasse bleiben unberührt.
• Nur Status 200 und HTML: Fehlerseiten, Weiterleitungen und Dateien werden nicht gespeichert.
• Keine Sitzungs-IDs im Cache: Eine Seite, die eine Sitzungs-ID enthält oder ein Cookie setzt, wird nicht gespeichert (und als Warnung protokolliert).
• CSRF-Token pro Anfrage: Das Token in der gecachten Seite ist ein Platzhalter und wird bei jeder Auslieferung neu eingesetzt.
• Feiner Schlüssel: Webseite, Sprache, Preisliste, Steuerposition und Cookie-Zustimmung gehören zum Cache-Schlüssel; wer Anderes sieht, bekommt einen anderen Eintrag.
• Mehrere Datenbanken: Jede Datenbank hat eigene Einträge, ein eigenes Journal und eigene Statistik.
• Kein Datenabfluss: Der Cache liegt lokal auf dem Server (Datei oder RAM). Es werden keine Daten an Dritte übertragen.

Suchmaschinen und KI-Indexer: nichts wird gesperrt

Manche Betreiber reagieren auf Crawler-Last mit Sperren. Das schützt den Server, kostet aber Sichtbarkeit. Das Modul wählt den umgekehrten Weg:

• Gleiche Inhalte für alle: Suchmaschinen, KI-Indexer und Besucher bekommen dieselbe Seite. Es gibt keine eigene „Crawler-Version“ und keine Erkennung nach Browserkennung.
• Schnellere Antworten helfen der Indexierung: Eine Seite, die in 20 statt 500 Millisekunden antwortet, belastet das Crawl-Budget weniger, und Crawler können in derselben Zeit mehr Seiten erfassen.
• Aktuelle Inhalte: Weil Änderungen die Seiten sofort entwerten, sehen Crawler nie eine veraltete Fassung – wichtig, wenn Sie Inhalte für Suche und KI-Antworten pflegen.
• Strukturierte Daten bleiben erhalten: JSON-LD, Meta-Angaben und hreflang-Verweise sind Teil der gecachten Seite; Sitemaps und Dateien werden vom Cache nicht angefasst.

Wenn Sie zusätzlich Last begrenzen wollen, ist das eine getrennte Entscheidung, die Sie bewusst treffen können – das Modul zwingt sie Ihnen nicht auf.

Installation und Einstellungen

1. Modul holen: Quellcode von GitHub herunterladen und in einen Addons-Pfad Ihrer Odoo-19-Installation legen: github.com/Alex0176/odoo-website-page-cache
2. Installieren: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Dabei entstehen das Änderungsjournal, die Trigger und der Wartungsjob (alle 10 Minuten).
3. Dienst neu starten, damit alle Arbeitsprozesse das Modul laden.
4. Dashboard öffnen: Website → Berichte → Seitencache. Prüfen, ob die Änderungsverfolgung vollständig ist, und den Speicherort wählen (Voreinstellung: automatisch).
5. Kontrollieren: Eine Shop- oder Blogseite zweimal abrufen und den Header X-Page-Cache ansehen: beim ersten Mal MISS, danach HIT.

Die Einstellungen liegen als Systemparameter vor (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) und werden normalerweise im Dashboard gepflegt. Das Modul ist auf Deutsch übersetzt. Deinstallieren entfernt Trigger, Journal und alle gecachten Seiten wieder vollständig.

Tipp für den RAM-Cache: Das RAM-Budget im Dashboard und die Größe des tmpfs (/dev/shm, Mount-Option size=) müssen zum Bedarf passen. Beides nennt Ihnen die Prüfung „Passt es in den Arbeitsspeicher?“ mit konkreten Werten.

Grenzen, die Sie kennen sollten

• Kurze Verzögerung nach Änderungen: Der Index des Änderungsjournals wird alle zwei Sekunden aufgefrischt. Eine geänderte Seite kann bis dahin noch in alter Fassung ausgeliefert werden.
• Lagerabhängige Texte werden über Bestandsänderungen und das Höchstalter aktualisiert.
• Schätzung des Platzbedarfs: Zusätzliche Fassungen je Preisliste oder Land sind nicht eingerechnet; etwas Reserve einplanen.
• Kein Ersatz für alles: Der Cache entlastet Anfragen, die er bedienen darf. Angemeldete Benutzer, Suchen und Formulare laufen weiterhin durch Odoo.
• Erster Abruf bleibt langsam: Nach einem Neustart des Servers (RAM) oder einer globalen Änderung wird jede Seite einmal normal gerendert, ehe sie im Cache liegt.

Häufige Fragen

Was ist der Seitencache für Odoo?

Ein Open-Source-Modul (website_page_cache, Odoo 19, LGPL-3), das öffentliche Shop- und Blogseiten für anonyme Besucher aus einem Cache ausliefert, statt sie bei jedem Aufruf neu zu rendern. Der Cache liegt wahlweise in Dateien oder im Arbeitsspeicher.

Sperrt das Modul Suchmaschinen oder KI-Crawler?

Nein. Suchmaschinen und KI-Indexer erhalten dieselben Seiten wie jeder andere Besucher, nur schneller. Es gibt keine Sperre, keine Drosselung und keine eigene Crawler-Fassung.

Werden geänderte Seiten und Übersetzungen automatisch neu gecacht?

Ja. PostgreSQL-Trigger melden jede Änderung relevanter Tabellen an ein Journal; betroffene Seiten werden verworfen und beim nächsten Aufruf neu gerendert und gespeichert. Übersetzungen sind abgedeckt, weil Odoo 19 sie im selben Datensatz speichert.

Soll ich Datei oder RAM wählen?

In der Regel Automatisch: Das Modul nutzt den RAM, solange alle Seiten hineinpassen, und weicht sonst auf Dateien aus. Dateien eignen sich, wenn der Cache Neustarts überleben soll oder der RAM knapp ist; der RAM ist die schnellste Variante.

Wie erfahre ich, ob meine Webseite in den Arbeitsspeicher passt?

Im Dashboard unter Website → Berichte → Seitencache. Der Abschnitt „Passt es in den Arbeitsspeicher?“ zählt die Seiten je Webseite und Sprache, misst die Seitengröße und vergleicht den Bedarf mit RAM-Budget, tmpfs-Größe und verfügbarem Speicher.

Wie viel zusätzlicher RAM wird für einen RAM-Cache benötigt?

Das Dashboard nennt es als eigene Zeile. Gerechnet wird: Bedarf = Seiten × Seitengröße; mit Sicherheitsreserve durch 0,8 geteilt. Weil der Cache höchstens die Hälfte des verfügbaren Speichers nutzen darf, ist das Doppelte davon der frei benötigte Speicher; die Differenz ist der zusätzliche RAM. Ist nur das RAM-Budget oder das tmpfs zu klein, nennt das Dashboard die Einstellung samt Zielwert.

Kann der Cache jemandem fremde Inhalte zeigen?

Nein. Gecacht wird nur für anonyme GET-Abrufe ohne Suchparameter. Angemeldete Benutzer, Warenkörbe, Formulare und Suchen kommen nie aus dem Cache; Sprache, Preisliste, Steuerposition und Cookie-Zustimmung sind Teil des Schlüssels.

Wie schalte ich den Cache im Notfall ab?

Im Dashboard den Schalter „Aktiv“ ausschalten oder den Systemparameter website_page_cache.enabled auf 0 setzen. Das gilt in allen Arbeitsprozessen nach spätestens 30 Sekunden. Eine Deinstallation entfernt außerdem Trigger, Journal und gecachte Seiten.

Woran erkenne ich, ob eine Seite aus dem Cache kam?

Am Antwort-Header X-Page-Cache: HIT bedeutet aus dem Cache, MISS bedeutet frisch gerendert und gespeichert.

Unterstützung durch Biricon IT Services

Ihre Odoo-Webseite reagiert bei Crawler-Last träge, oder Sie möchten Shop und Blog schneller und sichtbarer machen? Wir unterstützen bei der Analyse der Last, bei der Einrichtung des Seitencaches, bei der Dimensionierung von Arbeitsspeicher und Arbeitsprozessen und bei der mehrsprachigen Suchmaschinenoptimierung Ihrer Odoo-Webseite. Den Quellcode des Moduls finden Sie auf GitHub.

Jetzt Kontakt aufnehmen

Stand: 10. November 2026. Messwerte stammen aus einem Testsystem mit Beispieldaten und sind keine Zusage für andere Installationen.