OpenCart-SEO

Wie SEO auf OpenCart funktioniert – die selbst gehostete Open-Source-E-Commerce-Plattform, die mit standardmäßig deaktiviertem SEO ausgeliefert wird. Was der Core tatsächlich übernimmt (Canonical-Tags, eine Standard-robots.txt, Meta-Felder), was einen Schalter benötigt (SEO-URLs plus die .htaccess-Umbenennung), was sich zwischen OpenCart 3 und 4 geändert hat (die Sitemap-Regression) und was vollständig fehlt (strukturierte Daten und hreflang).

Erstveröffentlicht: 2. Juli 2026 · Zuletzt aktualisiert: 21. Aug. 2026 · Fortgeschritten
Sprachen
1 Evidenzsignal auf dieser Seite

OpenCart ist eine selbst gehostete Open-Source-PHP-E-Commerce-Plattform, die – anders als Shopify oder BigCommerce – mit standardmäßig deaktiviertem SEO ausgeliefert wird. Freundliche URLs erfordern zwei Schritte – einen „SEO-URL“-Schalter UND das Umbenennen von .htaccess.txt in .htaccess – sonst funktionieren sie nicht. SEO-Schlüsselwörter pro Entität sind manuelle, standardmäßig leere Felder. Canonical-Tags sind nativ (im Quellcode verifiziert) und lösen bereits das Problem doppelter Produkte in mehreren Kategorien, was die meisten Anleitungen falsch darstellen. Die XML-Sitemap ist versionsabhängig: OpenCart 3 enthielt eine, OpenCart 4 hat sie entfernt und benötigt eine Erweiterung. Strukturierte Daten und hreflang fehlen im Core vollständig – eine größere native Lücke als bei WooCommerce, Shopify oder BigCommerce.

TL;DR — OpenCart ist selbst gehostetes Open-Source-PHP: eine hohe SEO-Obergrenze (voller Serverzugriff, nichts strukturell blockiert), aber eine niedrige Untergrenze (SEO standardmäßig deaktiviert). Freundliche URLs benötigen den Schalter Use SEO URL = Yes und das Umbenennen von .htaccess.txt zu .htaccess mit mod_rewrite – wenn Sie eines davon verpassen, erhalten Sie 404er. SEO-Keywords pro Entität sind manuelle, standardmäßig leere Felder. Kanonische Tags sind nativ auf Produkt- und Kategorieseiten (ich habe den Quellcode geprüft) und neutralisieren bereits das Problem doppelter Produkte in mehreren Kategorien, sodass die meisten Ratschläge “installieren Sie eine Kanonische-Erweiterung” unnötig sind. Die XML-Sitemap ist versionsabhängig: OpenCart 3 enthielt einen Google-Sitemap-Feed, OpenCart 4 hat ihn entfernt und benötigt eine Erweiterung. Strukturierte Daten und hreflang fehlen im Kern vollständig.

Evidence for this claim OpenCart's SEO URL feature requires enabling the setting and configuring the server rewrite file. Scope: OpenCart installations using the documented Apache-style setup; server configuration can differ. Confidence: high · Verified: OpenCart documentation: SEO URL Evidence for this claim OpenCart features and bundled extensions vary by major version and should be verified against the installed release. Scope: OpenCart source repository and release-specific behavior. Confidence: high · Verified: OpenCart GitHub repository

Der Rahmen: Was ist nativ, was ist ein Schalter, was ist eine Erweiterung

Der meiste OpenCart-SEO-Content ist entweder eine Liste eines Erweiterungsanbieters, der den Artikel als Vorwand nutzt, um Ihnen ein Sitemap-Plugin zu verkaufen, oder ein Forenthread, der in einer alten OpenCart-1,5/2.x-Denkweise erstarrt ist. Der sinnvolle Ansatz ist ein anderer: Gehen Sie direkt zum ausgelieferten Quellcode von OpenCart und sortieren Sie jede Funktion in drei Kategorien.

Nativ und bereits korrekt: Canonical-Tags auf Produkt- und Kategorieseiten; eine statische Standard-robots.txt; Meta-Titel-/Beschreibungsfelder auf Store-Ebene und pro Entität; serverseitig gerenderte PHP/Twig-Ausgabe (von Haus aus crawlbar).

Nativ, aber deaktiviert – Sie betätigen einen Schalter: SEO-URLs (der Umschalter plus die .htaccess-Umbenennung); SEO-Keywords pro Produkt/Kategorie/Seite (manuell, standardmäßig leer).

Im Kern nicht vorhanden – Erweiterung oder benutzerdefinierter Theme-Code: XML-Sitemap bei OpenCart 4; strukturierte Daten jeglicher Art; hreflang / rel=alternate-Tags.

Diese Einteilung ist der gesamte Artikel. Alles unten zeigt, in welche Kategorie was fällt und warum.

SEO-URLs aktivieren – die Zwei-Schritte-Falle

Standardmäßig liefert OpenCart Query-String-URLs aus. Die eigene Dokumentation der Plattform verwendet genau dieses Beispiel für den „Vorher“-Zustand: “Set to Yes to enable friendly URLs (e.g., /iphone instead of /index.php?route=product/product&product_id=42).” (Übersetzung) „Stellen Sie die Option auf Ja, um benutzerfreundliche URLs zu aktivieren, beispielsweise /iphone statt /index.php?route=product/product&product_id=42.“ Das Aktivieren lesbarer URLs ist ein Zwei-Schritte-Prozess, und das Überspringen des zweiten Schritts ist das häufigste OpenCart-SEO-Supportmuster überhaupt.

Schritt 1 – die Einstellung. Öffnen Sie System → Einstellungen → Server, stellen Sie SEO-URL verwenden auf Ja und speichern Sie die Änderung.

Schritt 2 – das Server-Rewrite. OpenCart liefert die Rewrite-Regeln in einer Datei namens .htaccess.txt aus, und Apache liest sie unter diesem Namen nicht. Laut Dokumentation: “Apache: Rename htaccess.txt to .htaccess in your root directory and ensure mod_rewrite is enabled.” (Übersetzung) „Apache: Benennen Sie htaccess.txt im Stammverzeichnis in .htaccess um und stellen Sie sicher, dass mod_rewrite aktiviert ist.“ Ich habe bestätigt, dass OpenCart 4 die Datei weiterhin als .htaccess.txt ausliefert – die ausgelieferte Datei beginnt mit der wörtlichen Anweisung, sie umzubenennen. Die Dokumentation ist unmissverständlich, was passiert, wenn Sie es überspringen: “SEO URLs require proper server rewrite configuration. Without it, your friendly URLs will return 404 ‘Not Found’ errors.” (Übersetzung) „SEO-URLs erfordern eine korrekte Server-Rewrite-Konfiguration. Ohne sie liefern Ihre benutzerfreundlichen URLs 404-Fehler vom Typ ‚Nicht gefunden‘.“

Zwei Dinge, die sonst niemand erwähnt:

  • Die Umbenennungsanforderung ist aktuell, kein Relikt aus alten Zeiten. Ältere Anleitungen stellen die .htaccess-Umbenennung als ein Relikt aus OpenCart 1,5/2.x dar. Das stimmt nicht – die Anforderung gilt unverändert in der aktuellen Version (OpenCart 4.1.0.3). Wenn eine Anleitung behauptet, neuere Versionen erledigten das automatisch, ist sie falsch.
  • Es ist eine Upgrade-Falle. Jedes große Versions-Upgrade liefert .htaccess.txt erneut aus, was bei einem Update eine angepasste .htaccess stillschweigend überschreiben kann. Sichern Sie Ihre Datei vor dem Upgrade und vergleichen Sie anschließend die alte mit der neu ausgelieferten Fassung.

Wenn ein bestimmtes Produkt nach beiden Schritten immer noch product_id= zeigt, ist der übliche Übeltäter, dass das Produkt schlicht noch kein SEO-Keyword ausgefüllt hat – das ist der nächste Abschnitt.

SEO-Keywords – das manuelle, standardmäßig leere Feld

OpenCart erstellt keine automatischen Slugs aus Produkt- oder Kategorienamen. Das Keyword jeder Entität ist ein manuell auszufüllendes Feld, das über OpenCarts Schlüssel-/Wert-/Keyword-System zugeordnet wird. Die Dokumentation beschreibt eine typische Produktzuordnung: “For a typical product page, you would have two entries: 1. Key: route, Value: product/product 2. Key: product_id, Value: 42.” (Übersetzung) „Für eine typische Produktseite gibt es zwei Einträge: 1. Schlüssel: route, Wert: product/product; 2. Schlüssel: product_id, Wert: 42.“ Anschließend ordnen Sie diesem Routen-/ID-Paar ein Keyword zu.

Die Regeln, die zählen:

  • Format. “Use only lowercase characters (a-z), numbers (0-9), and hyphens (-) or underscores (_). Use a forward slash (/) for nested paths like electronics/phones.” (Übersetzung) „Verwenden Sie nur Kleinbuchstaben (a–z), Ziffern (0–9), Bindestriche (-) oder Unterstriche (_). Nutzen Sie für verschachtelte Pfade wie electronics/phones einen Schrägstrich (/).“ Verschachtelte Kategoriepfade sind eine manuelle Autorenentscheidung: “Use forward slashes to indicate category depth (e.g., /clothing/men/shirts)” (Übersetzung) „Verwenden Sie Schrägstriche, um die Kategorietiefe anzugeben, etwa /clothing/men/shirts.“ OpenCart baut den Pfad nicht automatisch aus Ihrem Kategoriebaum.
  • Eindeutigkeit. “Keywords MUST be unique for each store/language combination.” (Übersetzung) „Keywords MÜSSEN für jede Kombination aus Shop und Sprache eindeutig sein.“
  • Änderung = Bruch. “Changing an existing keyword will break old links. Set up 301 redirects if necessary.” (Übersetzung) „Das Ändern eines bestehenden Keywords macht alte Links unbrauchbar. Richten Sie bei Bedarf 301-Weiterleitungen ein.“ Behandeln Sie eine Slug-Änderung wie jede andere URL-Änderung: Leiten Sie die alte weiter.

Bei Kataloggröße ist das manuelle Ausfüllen mühsam, genau deshalb gibt es eine Vielzahl von Auto-Slug-Erweiterungen auf dem OpenCart Marketplace. Das ist die praktische Lösung – aber beachten Sie, dass es sich um ein Add-on handelt, nicht um eine Kernfunktion. Das ist ein deutlicherer Unterschied zu WooCommerce, Shopify oder BigCommerce, die alle automatisch aus dem Produktnamen Slugs generieren.

Canonical-Tags – nativ vorhanden, und der Mythos, den es zu korrigieren gilt

Die meisten OpenCart-SEO-Artikel stellen die folgende Erkenntnis falsch dar. Eine häufige Behauptung ist, dass OpenCart keine Canonical-Unterstützung hat und Sie daher eine Canonical-Erweiterung installieren müssen, um doppelte Inhalte zu beheben. Das ist ein Mythos, und der Quellcode klärt das. Im mitgelieferten Produkt-Controller von OpenCart 4 ruft die Seite addLink(..., 'canonical') auf, und das Canonical löst immer auf die flache Route product/product&product_id=X auf – unabhängig davon, über welche Kategorie der Besucher gekommen ist (product.php). Der Kategorie-Controller macht dasselbe auf Kategorieseiten (category.php).

Was das in der Praxis bedeutet: Ein Produkt, das in mehreren Kategorien platziert ist, erzeugt durch OpenCarts eigene Canonical-Logik kein Google-sichtbares Risiko für doppelte Inhalte, weil jeder Einstiegspfad auf dieselbe flache Produkt-URL kanonisiert. Der Kern löst bereits das klassische E-Commerce-Problem „gleiches Produkt, viele Kategorie-URLs“. Die sichtbare URL kann je nach Einstiegspfad in manchen Breadcrumb-/Theme-Konfigurationen weiterhin unterschiedlich sein – das ist ein UX-/Konsistenzproblem, kein Indexierungsproblem, da das Canonical-Tag das Ranking-Risiko neutralisiert.

Der eine echte Vorbehalt: Auf paginierten Kategorieseiten referenziert OpenCart das Canonical selbstreferenziell mit angehängtem &page=N, anstatt auf eine Alle-anzeigen-URL zu konsolidieren. Das deckt sich zufällig mit Googles eigener Empfehlung – Googles E-Commerce-Leitfaden rät, jeder paginierten Seite ihr eigenes Canonical zu geben, anstatt sie alle auf Seite eins zu verweisen – also ist es ein Vorbehalt, den man kennen sollte, kein Alarm. Denken Sie daran, dass ein Canonical ein Hinweis ist, keine Anweisung; wie Google es formuliert: “indicating a canonical preference is a hint, not a rule.” (Übersetzung) „Eine kanonische Präferenz anzugeben ist ein Hinweis, keine Regel.“

XML-Sitemap – die OpenCart-3-zu-4-Regression, die niemand erwähnt

Das ist eine wirklich nützliche, verifizierbare Tatsache für jeden, der einen kürzlich aktualisierten Shop prüft, und ich habe sie nirgendwo sonst klar formuliert gesehen: „Hat OpenCart eine Sitemap?“ braucht eine versionsabhängige Antwort.

  • OpenCart 3 enthielt einen nativen Google-Sitemap-Feed-Controller im Kern (extension/feed/google_sitemap) – eine einfache, aber echte, per Schalter aktivierbare XML-Sitemap unter Erweiterungen → Feed. Im 3.0.5.0-Quellcode bestätigt vorhanden (die aktuelle Version von OpenCart 3).
  • OpenCart 4 hat sie entfernt. Der entsprechende Controller existiert unter keinem der plausiblen v4-Pfade, und die alte docs.opencart.com/administration/seo/-Dokument-URL, auf die ältere Anleitungen verlinken, führt jetzt zu einem 404. Bei OpenCart 4 benötigen Sie eine Marketplace-Erweiterung, um eine Sitemap zu generieren.

Die meisten vorhandenen Anleitungen wurden für OpenCart 3 geschrieben und nie aktualisiert, daher behaupten sie selbstbewusst, OpenCart „habe eine eingebaute Sitemap“ – für 3 wahr, für 4 falsch. Unabhängig von Ihrer Version ist eine Sitemap sinnvoll: Wie Google anmerkt, “when creating a sitemap, you’re telling search engines about which URLs you prefer to show in search results,” (Übersetzung) „Wenn Sie eine Sitemap erstellen, teilen Sie Suchmaschinen mit, welche URLs Sie in den Suchergebnissen bevorzugen“, obwohl “submitting a sitemap is merely a hint.” (Übersetzung) „Das Einreichen einer Sitemap ist lediglich ein Hinweis.“ Was auch immer Ihre Sitemap generiert, sie sollte Filter-/Sortier-/Warenkorb-/Checkout-Parameter-URLs ausschließen und unter Googles Limit von 50 000 URLs / 50 MB pro Datei bleiben (verwenden Sie darüber einen Sitemap-Index).

robots.txt – ein statischer Standard, der eine manuelle Überprüfung benötigt

OpenCart liefert eine statische robots.txt im Produktstammverzeichnis. Ihre gesamte Aufgabe ab Werk besteht darin, parametrisierte Sortier-/Filter-/Paginierungs-Query-Strings vom Crawlen auszuschließen. In der aktuellen Version (OpenCart 4.1.0.3) lautet die mitgelieferte Datei:

user-agent: *
Disallow: /*?page=$
Disallow: /*&page=$
Disallow: /*?sort=
Disallow: /*&sort=
Disallow: /*?order=
Disallow: /*&order=
Disallow: /*?limit=
Disallow: /*&limit=
Disallow: /*?filter_name=
Disallow: /*&filter_name=
Disallow: /*?filter_sub_category=
Disallow: /*&filter_sub_category=
Disallow: /*?filter_description=
Disallow: /*&filter_description=
Disallow: /*?filter_group=
Disallow: /*&filter_group=

Das ist eine sinnvolle Standardeinstellung – sie entspricht direkt dem, was Google als klassische Duplikatquelle kennzeichnet: “the results of sorting and filtering functions of a category page” (Übersetzung) „die Ergebnisse der Sortier- und Filterfunktionen einer Kategorieseite“. Ein Versionshinweis ist dabei wichtig: Die aktuelle Version von OpenCart 3 (3.0.5.0) bringt eine andere Standardeinstellung mit – sie schreibt User-agent: korrekt groß und fügt ein Disallow: /*?route=product/search / &route=product/search-Paar hinzu, das OpenCart 4 nicht hat, während OpenCart 4 die filter_group-Regel hat, die OpenCart 3 nicht hat. Die beiden Standardeinstellungen waren in älteren Versionen byte-identisch; seitdem sind sie auseinandergegangen. Gehen Sie daher nicht davon aus, dass Ihre OC3- und OC4-Shops dieselbe Datei teilen, sondern prüfen Sie die tatsächlich eingesetzte Fassung. Drei weitere Dinge sollten Sie wissen:

  • Es deklariert keine Sitemap. Es gibt keine standardmäßig ausgelieferte Sitemap:-Zeile. Sobald Sie eine Sitemap-URL haben, fügen Sie eine hinzu.
  • Es wird nicht automatisch generiert oder aktualisiert. Das Aktivieren von SEO-URLs ändert daran nichts. Prüfen Sie es manuell – und denken Sie daran, dass robots.txt das Crawling blockiert, nicht das Indexieren, verlassen Sie sich also nicht darauf, um etwas zu deindexieren (das ist die Aufgabe von noindex, auf einer crawlbaren Seite).

Meta-Tags – Fallback auf Store-Ebene plus feldspezifische Angaben

OpenCart hat Meta-Titel/-Beschreibung auf zwei Ebenen. Die Felder auf Store-Ebene (System → Einstellungen → Allgemein) sind der globale Fallback; die Dokumentation nennt den Store-Meta-Titel “(Required)… critical for SEO” (Übersetzung) „erforderlich und entscheidend für SEO“ und empfiehlt eine Beschreibung mit etwa 160 Zeichen. Das Feld Meta-Keywords wird ebenfalls mitgeliefert, aber es ist überall ein totes Ranking-Signal – lassen Sie es leer. Einzelne Produkte, Kategorien und Informationsseiten haben jeweils ihren eigenen SEO-Tab mit Meta-Feldern auf Seitenebene, wo die eigentliche Arbeit liegt: Schreiben Sie einzigartige Titel und Beschreibungen für jedes wichtige Produkt und jede wichtige Kategorie, anstatt sich auf den Store-Standard zu verlassen.

Strukturierte Daten – im Kern nicht vorhanden, Punkt.

Ich habe OpenCart 4s Standard-Produktvorlage nach schema.org, application/ld+json und itemprop durchsucht – null Treffer. OpenCart Core liefert keinerlei strukturierte Daten, auf keiner Seite: kein Product-Schema mit Preis/Verfügbarkeit/Bewertung, kein BreadcrumbList, keine Organization, nichts. Das ist eine wesentlich größere Lücke als bei WooCommerce (das grundlegende native Product-JSON-LD ausgibt) oder Shopify und BigCommerce (Schema in ihren Standard-Themes integriert).

Alles ist Erweiterungs- oder Custom-Theme-Territorium. Wenn Sie Produkt-Rich-Results möchten, sind die zwei Wissenswerten Berechtigungspfade Googles Merchant Listings (feed- oder markup-basiert, preis-/verfügbarkeitslastig) und Product Snippets (bewertungs-/rezensionsbasiert) – sie haben unterschiedliche erforderliche Eigenschaften, wählen Sie also den, der zu dem Ergebnis passt, das Sie anstreben, und markieren Sie entsprechend. Fügen Sie es über eine Marktplatz-Schema-Erweiterung oder handgeschriebenes JSON-LD in der Produktvorlage Ihres Themes hinzu; JSON-LD ist das Format, das Google empfiehlt.

Mehrsprachigkeit und hreflang – ein Umschalter, keine hreflang-Tags

Seien Sie hier präzise, denn die Dokumentation ist leicht falsch zu lesen. OpenCarts Mehrsprachigkeitssystem ist ein Sprachumschalter-Dropdown, keine automatische hreflang-Implementierung. Ich habe den ausgelieferten Sprach-Controller vollständig gelesen (language.php); er baut eine Liste für einen <select>-artigen Umschalter, und es gibt keine hreflang- oder rel=alternate-Linkgenerierung irgendwo in der Datei – oder irgendwo in OpenCarts Engine-Schicht.

Die Dokumentation sagt: “OpenCart automatically handles the technical SEO aspects of multi-language URLs, but you must provide the localized keywords.” (Übersetzung) „OpenCart übernimmt automatisch die technischen SEO-Aspekte mehrsprachiger URLs, aber Sie müssen die lokalisierten Keywords bereitstellen.“ Streng gelesen bedeutet „die technischen SEO-Aspekte“ das Generieren einer sprachspezifischen URL-Variante beim Sprachwechsel – nicht das Ausgeben von <link rel="alternate" hreflang="x">-Tags im <head>, was die Quelle bestätigt, dass sie nicht existieren. Lassen Sie sich von diesem Satz nicht davon überzeugen, dass OpenCart hreflang unterstützt. Wenn Sie einen mehrsprachigen Shop betreiben, benötigen echte hreflang-Tags eine Theme-Änderung oder eine Erweiterung. (Die Mechanik finden Sie im hreflang-Deep Dive.)

Headless und die API – Flexibilität, aber SEO wird Ihr Problem

OpenCart liefert zwar eine eigene API für die Entwicklung von Custom- oder Headless-Frontends mit — die Dokumentation beschreibt sie als Ermöglichung von “integrations with inventory systems, ERP software, mobile apps, custom frontends, and other third-party services.” (Übersetzung) „Integrationen mit Inventarsystemen, ERP-Software, mobilen Apps, Custom-Frontends und anderen Drittanbieterdiensten.“ Aber es gibt kein First-Party-PWA/SSR-Produkt, das mit Shopify Hydrogen oder BigCommerce Catalyst vergleichbar wäre. Jedes „Headless-OpenCart“-Angebot ist ein Build einer Drittanbieter-Agentur, die React oder Vue auf diese API aufsetzt.

Die SEO-Erkenntnis: Ein Standard-OpenCart-Storefront ist serverseitig gerendertes PHP/Twig, was von Haus aus gut für die Crawlbarkeit ist. Headless tauscht diese native Crawlbarkeit gegen Entwicklerflexibilität und legt die Verantwortung für SSR/Rendering-Korrektheit vollständig auf die Agentur, die das Frontend entwickelt — OpenCart selbst gibt Ihnen keine Rendering-Garantien, wie es ein First-Party-Headless-Framework tun würde. Wenn Sie diesen Weg gehen, liegen die JavaScript-SEO-Regeln in Ihrer Verantwortung.

Das native Blog (CMS → Artikel)

OpenCart 4.1.0.0, veröffentlicht im Januar 2025, hat ein natives, leichtgewichtiges Blog/CMS hinzugefügt — OpenCarts eigene Versionshinweise listen “Blog system” (Übersetzung) „Blog-System“ unter den Neuerungen dieser Version. Es befindet sich im Admin unter CMS → Artikel: Jeder Eintrag unterstützt Rich Text, Bilder, Kategorisierung und — hier relevant — eigene Meta-Title-, Meta-Description- und Meta-Keywords-Felder, dasselbe Pro-Entity-SEO-Muster wie bei Produkten und Kategorien. Es schließt eine echte Lücke: OpenCart hatte zuvor kein natives Blog und zwang Nutzer auf eine separate WordPress-Installation oder eine Blog-Erweiterung aus dem Marketplace für Content-Marketing und thematische Autorität — denselben Content-Plattform-Vorteil, den WooCommerce (natives WordPress) und Shopify (natives Blog) immer hatten. Es ist schon eine Weile verfügbar, aber viele OpenCart-SEO-Leitfäden stammen noch aus der Zeit davor oder wurden für OpenCart 3 geschrieben, daher ist es immer noch erwähnenswert, wenn Sie CMS → Artikel in einem 4,1+-Store noch nicht geprüft haben.

OpenCart vs. die gehosteten Plattformen — die ehrliche Version

OpenCartShopify / BigCommerce
HostingSelbst gehostet, voller ServerzugriffVollständig gehosteter SaaS-Dienst
Freundliche URLsStandardmäßig deaktiviert (Umschalter + .htaccess-Umbenennung)Ab Installation aktiv
URL-SlugsManuell pro EntitätAutomatisch aus dem Produktnamen
Canonical-TagsNativ (Produkt + Kategorie)Nativ
XML-SitemapOC3 nativ / OC4 benötigt ErweiterungAutomatisch generiert
Strukturierte DatenKeine im CoreIm Standard-Theme
hreflangKeines im CoreManuell (BigCommerce) / App (Shopify)
ObergrenzeSehr hoch (direkter PHP-/MySQL-Zugriff)Durch die Plattform begrenzt

OpenCarts Geschichte ist das Spiegelbild der SaaS-Plattformen: Diese bieten eine starke Basis und eine begrenzte Obergrenze; OpenCart bietet eine niedrige Basis und keine Obergrenze. Nichts ist strukturell blockiert, weil Sie den Server besitzen — aber es wird auch nichts für Sie erledigt. Richten Sie SEO-URLs und die .htaccess-Umbenennung korrekt ein, füllen Sie Ihre Keywords aus, verifizieren Sie die nativen Canonicals, fügen Sie eine Sitemap hinzu (Erweiterung auf OC4), bereinigen Sie robots.txt, und legen Sie Schema und hreflang darauf — dann konkurriert ein OpenCart-Store mit allem.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.