Hallo an alle,
Ich habe mich auch mal an der dynamischen Sitemap versucht, da ich finde, dass die built-in-Lösung nur sub-optimal ist. Dabei habe ich mir die originale Lösung dieses Threads (die ja nach den Aussagen hier und auch bei mir nicht funktionierte) als Vorlage genommen, es umgeschrieben, ergänzt und nun endlich zum Laufen bekommen.
Das Script erzeugt 2 Dateien: sitemap2.xml und sitemap3.xml.gz (gleicher Inhalt, nur halt gezippt). Einfach die angehängte Datei sitemap2.php in den Shop root legen und folgenden Eintrag in der .htaccess ergänzen (irgendwann nach "RewriteEngine On"):
RewriteCond %{REQUEST_URI} ^/sitemap2.xml
RewriteRule .* /sitemap2.php [L](btw: mit der Namensgebung "sitemap.xml.php" hatte mein PHP offenbar irgendein Problem).
Die sitemap2.xml (oder auch die sitemap2.php, egal) sollte bei den derzeitigen Einstellungen ($usage_hours=0.99) einmal pro Stunde per Cron aufgerufen werden, damit die Sitemap-Dateien generiert werden können. Sonst würde, wie weiter oben bereits beschrieben, der Aufruf durch einen Bot ggf. obsolet.
Die <priority> und <changefreq> Tags sollte jeder an seine eigenen Bedürfnisse anpassen.
ÄNDERUNGEN ggü. dem o. g. Skript:- Den Aufruf der configuration.php habe ich rausgeworfen und die Variable $root hinzugefügt, da die configuration.php ja auch in der includes/application_top.php aufgerufen wird und es daher zu Warnmeldungen kam.
- GZIP_COMPRESSION noch vor Aufruf der application_top.php als „false“ definiert – was unbedingt erforderlich ist und seltsamer Weise keine Warnmeldung erzeugte,
- Der Kathegorien-Teil und die Funktion "rv_get_path" sind eine Katastrophe
- insbesondere die imaginäre Variable $cat_data['code'], die bei eingeschaltetem error_reporting und display_errors eine "undefined"-Notice auswirft. Keine Ahnung, wo die ursprünglich herkommt ... Aber wenn man Sie rausschmeißen, funzt es gar nicht mehr. Wenn da bitte einer von Euch nochmal drüber schauen könnte? ... ich war einfach zu müde gestern. - Naja und ... erst mit einem "ob_start" zu beginnen und dann mitten im Script mit einem "exit" auszusteigen fand ich auch nicht schön , das habe ich geändert, sodass es nun bis zum Ende durchläuft,
- Die Variable $language habe ich umbenannt in $all_languages - nur damit es zu keinen Konflikten kommt mit bereits an anderer Stelle verwendeten, gleichnamigen Variablen.
- Die Blog-Modul-Geschichte habe ich entfernt, weil ich die nicht benötige (kann man ja bei Bedarf wieder entsprechend einbauen),
- Den Code etwas "aufgefrischt" und leserlicher gemacht (aber das war auch vorher schon ok),
- Die Reihenfolge der Tags gemäß Vorgaben geändert,
- Noch diverse andere kleinere Änderungen vorgenommen,
- Das aktuelle, offizielle Schema (http://www.sitemaps.org/schemas/sitemap/0.9) verwendet, das dann auch von anderen Suchmaschinen sicher erkannt wird (auch wenn die 0.84-Version von google-sitemaps i. A. noch unterstützt wird).
"... Since Yahoo and Microsoft support the Google Sitemaps Protocol, the schema version was changed to "Sitemap 0.90" (no other changes). Google still accepts the version 0.84, but for submissions to other search engines urlset must reference the XML schema hosted by sitemaps.org."
(Quelle: https://groups.google.com/forum/?fromgroups=#!topic/google_webmaster_help-sitemap/v4BrWDNkxSI).Da das Script nur bei ausgeschaltetem error_reporting und display_errors eine fehlerfreie (oder besser: notice-freie) Sitemap liefert, handelt es sich immer noch um eine quick-and-dirty-Lösung, die letztlich aber recht gut funktioniert (jedenfalls bei mir) … wie gesagt: die Variable $cat_data['code'] ist Schuld
,
Langfristig sollte man m. E. den Hebel aber an anderer Stelle ansetzen, denn:
"... Google bestimmt die Sprache einer Seite lediglich auf der Grundlage des sichtbaren Contents. Wir verwenden keine Sprachinformationen auf Codeebene wie lang-Attribute."
und
"... Verwenden Sie für die verschiedenen Sprachversionen Ihres Contents jeweils eine eigene URL. Verwenden Sie keine Cookies, um übersetzte Versionen der Seite anzuzeigen. Verlinken Sie nach Möglichkeit die einzelnen Sprachversionen einer Seite."
(Quelle: http://support.google.com/webmasters/bin/answer.py?hl=de&answer=182192)Ich weiss, ich schreibe hier nix, was nicht schon hinreichend bekannt wäre - aber falls Ihr (das Entwickler-Team) eine Überarbeitung des Link-Routings auf dem Zettel habt, dann sollte es ganz oben stehen
. Ist bestimmt ein leidiges Thema, aber kann man sich da nicht was bei den anderen xtc forks abgucken? Langfristig gesehen soll der modified Shop doch konkurrenzfähig bleiben. Und der Grund, warum man einen Shop aufsetzt, liegt doch bei vielen Gewerbetreibenden darin, "zusätzliche" Kunden zu generieren und nicht nur die Sowieso-Kunden von ebay und amazon auf die eigene Seite umzuleiten. Die organische Suche bei Google und Co. kann nunmal immer noch ein Erfolgsbringer sein.
Aus diesem Grunde glaube ich, dass es sinnvoller ist, nicht zu viel Zeit damit zu verbringen, weiter an diesem Skript "rumzubasteln", sondern erst mal das Routing in Angriff zu nehmen. Wenn man das Script anschließend nochmal bearbeitet, sollte man auch an die oben angesprochene 50.000 Links-Grenze einer google-sitemap denken. Wenn man z. B. 15.000 Artikel in einem 4-sprachigen Shop hat, so würden am Ende mehr als 10.000 Links nicht indexiert werden. Da müsste dann wahrscheinlich pro Sprache eine eigene Sitemap her. Man kann mich diesbezüglich gerne ansprechen, wenn ich so etwas gegen Honorar umsetzen soll.
Eigentlich müssten auch noch 2 Spalten (creation_date & last_modified) in der DB-Tabelle content_manager hinzugefügt und eine entsprechende Änderung im Code der contentmanager.php gemacht werden. Momentan steht in der Sitemap immer die aktuelle Zeit bei den Content-Links ...
Aber auch schon mit dieser Lösung hat man gegenüber der built-in-Lösung einige Vorteile:
- ALLE Produkt-, Kategorien- und Content-Seiten werden berücksichtigt (ohne doppelte Einträge),
- Die Änderung der Tag-Reihenfolge und die Aktualisierung des Sitemap-Schemas führt ggf. zu einer besseren Listung auch bei anderen Suchmaschinen (als Google),
- Alle Links haben in mehrsprachigen Shops einen angehängten lang-Parameter (was bei derzeitigem Routing noch erforderlich ist), in einsprachigen Shops keinen,
- Man läuft nicht Gefahr, dass Session-IDs an die Links angehängt werden (bei Backend-Einstellung "Cookie Benutzung bevorzugen" = false),
- Man kann bei zu großen Datenmengen bequem von der dynamischer erzeugten (sitemap2.xml) auf die gezippte Sitemap (sitemap3.xml.gz) umsteigen,
- Darüber hinaus sind die Sitemaps valide (getestet unter http://www.validome.org/xml/validate/ und http://www.xmlcheck.com/).
Und es ist nur das Aufspielen einer Datei, das Anlegen eines Cron-Jobs und ein minimaler Eingriff in die .htaccess notwendig und somit meiner Meinung nach kein Core-Hack.
Ach ja ... und wenn Ihr es Euch einbaut: nicht vergessen, die sitemap2.xml bzw. die sitemap3.xml.gz (z. B. in Eurem Google Webmaster-Tool) bekannt zu geben und möglichst auch die robots.txt entsprechend zu ändern
.
So, hoffe ich konnte helfen und freue mich auf Euer feedback,
Gruß, Ingo
