Cache Parameter "?m=" und SEO
Cache Parameter "?m=" und SEO
Hallo,
im Zuge einer SEO Optimierung haben wir von einem SEO Spezialisten erfahren, dass sich der ?m Parameter für das Caching, negativ auf das Google Ranking auswirkt.
Nun stellt sich uns die Frage:
Ist es möglich diesen Parameter für we:css, we:js und we:img rauszufiltern/auszustellen?
Oder sogar generell ausstellen?
Grüße
im Zuge einer SEO Optimierung haben wir von einem SEO Spezialisten erfahren, dass sich der ?m Parameter für das Caching, negativ auf das Google Ranking auswirkt.
Nun stellt sich uns die Frage:
Ist es möglich diesen Parameter für we:css, we:js und we:img rauszufiltern/auszustellen?
Oder sogar generell ausstellen?
Grüße
-
- webEdition Partner
- Beiträge: 1825
- Registriert: Di 7. Mär 2006, 16:50
- Wohnort: Wien
- Kontaktdaten:
Re: Cache Parameter "?m=" und SEO
Hallo Peter,
Das würde mich sehr wundern. Die konkrete Argumentation dazu würde mich jedenfalls interessieren. Haben die "SEO Spezialisten" belegte Quellen diesbezüglich genannt?
Liebe Grüße,
Sascha
Das würde mich sehr wundern. Die konkrete Argumentation dazu würde mich jedenfalls interessieren. Haben die "SEO Spezialisten" belegte Quellen diesbezüglich genannt?
Liebe Grüße,
Sascha
Re: Cache Parameter "?m=" und SEO
ich hätte nie gedacht das man damit so ein Faß aufmacht - im Gegenteil, sorgt es doch gerade dafür das endlich sichergestellt ist das die Seite so aussieht wie sie soll und nicht das Bild von gestern noch aus dem Cache geholt wird...
Aber ja, die Argumentation würde ich auch gerne mal hören...
Aber ja, die Argumentation würde ich auch gerne mal hören...
webEdition-Kern-Entwickler
- Carrear
- webEdition Partner
- Beiträge: 646
- Registriert: Do 17. Jan 2013, 03:02
- Wohnort: Hannover
- Kontaktdaten:
Re: Cache Parameter "?m=" und SEO
Die kenne ich zufälligerweise auch ;P
Es geht darum, dass eine Ressource unter verschiedenen URL's indiziert wird, welche letztendlich alle auf den gleichen Inhalt verweisen - laut dem Spezialisten also Duplicate Content. Ich habe mehrfach versucht die clientseitigen Vorteile bzgl. Caching zu erläutern. Bevorzugt wird vom Spezialisten aber doch eher die Caching Zeit für betroffene Ressourcen auf einen Tag runterzudrehen und dafür den Parameter zu entfernen.
Es geht darum, dass eine Ressource unter verschiedenen URL's indiziert wird, welche letztendlich alle auf den gleichen Inhalt verweisen - laut dem Spezialisten also Duplicate Content. Ich habe mehrfach versucht die clientseitigen Vorteile bzgl. Caching zu erläutern. Bevorzugt wird vom Spezialisten aber doch eher die Caching Zeit für betroffene Ressourcen auf einen Tag runterzudrehen und dafür den Parameter zu entfernen.
Re: Cache Parameter "?m=" und SEO
Ich vermute, wenn die URL anstelle von
/js/datei.js?m=xy
einfach /js/xy/datei.js lautet oder /js/datei-xy.js
dann ist das Problem entschärft. Letzlich könnten die SEO-URL Funktionen für einen internen Rewrite genutzt werden.
Ich habe bei einzelnen Projekten das schon so umgebogen. Die ?m= Dinger abfangen, in die URL mit einweben und mittels htaccess umschreiben. Klappte da ganz gut, ist aber keine einfache Lösung.
/js/datei.js?m=xy
einfach /js/xy/datei.js lautet oder /js/datei-xy.js
dann ist das Problem entschärft. Letzlich könnten die SEO-URL Funktionen für einen internen Rewrite genutzt werden.
Ich habe bei einzelnen Projekten das schon so umgebogen. Die ?m= Dinger abfangen, in die URL mit einweben und mittels htaccess umschreiben. Klappte da ganz gut, ist aber keine einfache Lösung.
-
- webEdition Partner
- Beiträge: 1825
- Registriert: Di 7. Mär 2006, 16:50
- Wohnort: Wien
- Kontaktdaten:
Re: Cache Parameter "?m=" und SEO
Wir sprechen hier von Ressourcen, dh. Binärdaten, CSS, JavaScript, etc. Die wesentliche Frage ist, welchen spürbaren Impact das auf das Ranking haben soll. Meiner Kenntnis nach keinen.
Da ist es besser sich auf sinnvolle und nachhaltige SEO Maßnahmen - wie z.B. die Inhalte - zu konzentrieren![Wink :wink:](./images/smilies/icon_e_wink.gif)
Just my 2 cents,
Sascha
Da ist es besser sich auf sinnvolle und nachhaltige SEO Maßnahmen - wie z.B. die Inhalte - zu konzentrieren
![Wink :wink:](./images/smilies/icon_e_wink.gif)
Just my 2 cents,
Sascha
- Carrear
- webEdition Partner
- Beiträge: 646
- Registriert: Do 17. Jan 2013, 03:02
- Wohnort: Hannover
- Kontaktdaten:
Re: Cache Parameter "?m=" und SEO
Erzähl das unserem Kunden, der sich einen Spezialisten zu Rate gezogen hat.
- Carrear
- webEdition Partner
- Beiträge: 646
- Registriert: Do 17. Jan 2013, 03:02
- Wohnort: Hannover
- Kontaktdaten:
Re: Cache Parameter "?m=" und SEO
Ja, zumal in dem Fall auf Anraten schon etliche Rewrites stattfinden. Sonst wäre die Lösung sicher ein paar Gedanken wert für diesen Fall.ThomasGoebe hat geschrieben:Die ?m= Dinger abfangen, in die URL mit einweben und mittels htaccess umschreiben. Klappte da ganz gut, ist aber keine einfache Lösung.
Re: Cache Parameter "?m=" und SEO
Hallo Martin,
so kompliziert ist das auch wieder nicht. Im Grunde braucht es drei Custom Tags, welche die Standardausgabe von we:js, we:css, we:img "durchreichen" und dort die ?m= ersetzen.
Mit einer geeigneten Verzeichnisstruktur ist das dann auch nur eine rewrite Regel.
Bleibt noch ein eigner we:textarea, der dort für images auch so vorgeht.
Alternativ per hook etwas bauen...
Ob das ganze sinnvoll ist, sei mal dahin gestellt.
so kompliziert ist das auch wieder nicht. Im Grunde braucht es drei Custom Tags, welche die Standardausgabe von we:js, we:css, we:img "durchreichen" und dort die ?m= ersetzen.
Mit einer geeigneten Verzeichnisstruktur ist das dann auch nur eine rewrite Regel.
Bleibt noch ein eigner we:textarea, der dort für images auch so vorgeht.
Alternativ per hook etwas bauen...
Ob das ganze sinnvoll ist, sei mal dahin gestellt.
-
- webEdition Partner
- Beiträge: 1825
- Registriert: Di 7. Mär 2006, 16:50
- Wohnort: Wien
- Kontaktdaten:
Re: Cache Parameter "?m=" und SEO
Ich habe jetzt noch die folgenden Links zum Thema "Query String & Caching" gefunden:
Liebe Grüße,
Sascha
- File Caching: Query string vs Last-Modified?
- A practical guide to web resource caching, part 1
- Strategies for Cache-Busting CSS
Liebe Grüße,
Sascha
- Carrear
- webEdition Partner
- Beiträge: 646
- Registriert: Do 17. Jan 2013, 03:02
- Wohnort: Hannover
- Kontaktdaten:
Re: Cache Parameter "?m=" und SEO
Nicht zu vergessen: we:url, we:link und betroffene we:field - Tags. Das halte ich schon für einen ganz schönen Akt. Man muss sich aus meiner Sicht wirklich die Aufwand-Nutzen-Frage stellen.ThomasGoebe hat geschrieben:Hallo Martin,
so kompliziert ist das auch wieder nicht. Im Grunde braucht es drei Custom Tags, welche die Standardausgabe von we:js, we:css, we:img "durchreichen" und dort die ?m= ersetzen.
Mit einer geeigneten Verzeichnisstruktur ist das dann auch nur eine rewrite Regel.
Bleibt noch ein eigner we:textarea, der dort für images auch so vorgeht.
Alternativ per hook etwas bauen...
Ob das ganze sinnvoll ist, sei mal dahin gestellt.
Re: Cache Parameter "?m=" und SEO
Also mal ganz ehrlich: SEO-Experte ist nun auch kein geschützter Begriff - jeder von uns kann sich so nennen und Unfug erzählen.
Die Rewrites von Thomas sind ne nette Idee machen am Ende die Zugriffszeiten aber wieder höher.
Duplicate content ist doch auch Unsinn. Das wäre ja nur, wenn mit unterschiedlichen Parametern der gleiche Inhalt ausgeliefert würde - das ist aber doch hier nicht der Fall. Sobald du die Datei speicherst lieferen alle dyn. Seiten den gleichen m-Parameter.
Den Zeitstempel in den Dateinamen oder Pfad einzuweben finde ich wirklich keine sinnvolle Idee. Noch dazu dürfte ja auch hier google mit duplicate content kommen - ich denke ja nicht das du dann prüfst das der Zeitstempel stimmt und wenn nicht 404 zurücklieferst. Also hast du auch hier 2x den gleichen Inhalt über unterschiedliche URLs.
@Sascha: die Links sind interessant, das Caching im Proxy würde ich mal vernachlässigen und dann ist der Param die beste Lösung. In dem anderen Artikel ist die Argumentation zum Thema eTag ein wenig veraltet - es ist im Gegenteil eine wirklich gute Idee das angeschaltet zu lassen.
Wenn ich das richtig verstehe ist es den Kunden lieber, das ihre Kunden im Zweifel falsche Inhalte sehen als dafür angeblich bei google heruntergestuft zu werden. Ich denke gerade mal an eine Nachrichtenseite bei der dann das Bild nicht zum Text paßt, oder ein Bild nicht zum Angebot.
Ich finde es schon traurig das wir jeder dämlichen Idee von google hinterherlaufen - ist ja nicht so das sie nicht auch schon diverse angeblich tolle Ideen wieder begraben hätten.
Die Rewrites von Thomas sind ne nette Idee machen am Ende die Zugriffszeiten aber wieder höher.
Duplicate content ist doch auch Unsinn. Das wäre ja nur, wenn mit unterschiedlichen Parametern der gleiche Inhalt ausgeliefert würde - das ist aber doch hier nicht der Fall. Sobald du die Datei speicherst lieferen alle dyn. Seiten den gleichen m-Parameter.
Den Zeitstempel in den Dateinamen oder Pfad einzuweben finde ich wirklich keine sinnvolle Idee. Noch dazu dürfte ja auch hier google mit duplicate content kommen - ich denke ja nicht das du dann prüfst das der Zeitstempel stimmt und wenn nicht 404 zurücklieferst. Also hast du auch hier 2x den gleichen Inhalt über unterschiedliche URLs.
@Sascha: die Links sind interessant, das Caching im Proxy würde ich mal vernachlässigen und dann ist der Param die beste Lösung. In dem anderen Artikel ist die Argumentation zum Thema eTag ein wenig veraltet - es ist im Gegenteil eine wirklich gute Idee das angeschaltet zu lassen.
Wenn ich das richtig verstehe ist es den Kunden lieber, das ihre Kunden im Zweifel falsche Inhalte sehen als dafür angeblich bei google heruntergestuft zu werden. Ich denke gerade mal an eine Nachrichtenseite bei der dann das Bild nicht zum Text paßt, oder ein Bild nicht zum Angebot.
Ich finde es schon traurig das wir jeder dämlichen Idee von google hinterherlaufen - ist ja nicht so das sie nicht auch schon diverse angeblich tolle Ideen wieder begraben hätten.
webEdition-Kern-Entwickler
- Carrear
- webEdition Partner
- Beiträge: 646
- Registriert: Do 17. Jan 2013, 03:02
- Wohnort: Hannover
- Kontaktdaten:
Re: Cache Parameter "?m=" und SEO
Im Großen und Ganzen stimme ich dir zu - bis auf den zitierten Absatz. Wie groß die Auswirkungen sind kann ich nicht beurteilen. Aber wenn eine Datei in der alten Version mit:mokraemer hat geschrieben:Duplicate content ist doch auch Unsinn. Das wäre ja nur, wenn mit unterschiedlichen Parametern der gleiche Inhalt ausgeliefert würde - das ist aber doch hier nicht der Fall. Sobald du die Datei speicherst lieferen alle dyn. Seiten den gleichen m-Parameter.
style.css?m=1
indexiert ist und später in einer anderen Version mit:
style.css?m=2
noch einmal indexiert wird, dann verweist zum Schluss doch auch style.css?m=1 auf die neue Ressource, oder sehe ich das falsch?
Re: Cache Parameter "?m=" und SEO
Hallo Marc,
es gibt hier ja gar kein Schwarz Weiß. Warum nicht beide Bedürfnisse erfüllen? Beide sind legitim. D.h. eine optimales Ergebnis bei google Pagerank / Speed erreichen und das falsche Caching verhindern. Nur, weil wir vielleicht nicht alle der Bedürfnisse teilen oder sinnvoll finden, sind sie dennoch nicht als falsch zu bewerten.
Also liegt da die Herausforderung: wie kann beides gleichzeitig ermöglicht werden?
Die Rewrites sind z.B. nur so lange ein (kleines) Performanceproblem, wie sie nötig sind. D.h. wenn webEdition beim Abspeichern der Ressourcen z.B. direkt einen anderen Dateinamen nutzt (inkl. Zeitstempel) aber im Backend weiterhin den Dateinamen ohne Zeitstempel anzeigt, könnte das auch eine Lösung sein. Wie gesagt: könnte! Ich bin nicht in der Position, das im Detail zu wissen und zu bewerten. Es wird da auch noch massiv andere Lösungen geben. Wie machen es andere Systeme? Was hat sich bewährt? Es ist sicher immer sinnvoll, an solchen Stellen nicht nur in den eigenen Ideenwelten zu suchen.
Die Herausforderung für ein CMF sollte doch sein, die verschiedenen Bedürfnisse elegang zu lösen. Bislang hat webEdition dem Template Ersteller (ausser bei listview Navigationen und userinputs) die volle Kontrolle über den generierten Quelltext überlassen. Das ist nun durch ?m= ganz leicht aufgeweicht. Ist das sinnvoll? Die Rückmeldungen zeigen doch, dass es (neben google) da auch noch das Bedürfnis gibt, den Quellcode "aufgeräumt" zu haben etc.
Also: statt ideologisch zu sagen: was google da will ist quatsch, zumindest einmal überlegen, ob es nicht machbar wäre. Denn was nützt eine Newsseite mit aktuellem Bild, wenn sie bei dem de facto Suchmaschinen Standard nicht gefunden wird?
Ich klinke mich hier wieder aus, letzlich ist es Eure Entscheidung als webEdition Entwicklungsteam, welche Anforderungen an heutige Websites out-of-the-box unterstützt werden und welche nicht.
Ich wünsche Euch gute Ideen!
Thomas
es gibt hier ja gar kein Schwarz Weiß. Warum nicht beide Bedürfnisse erfüllen? Beide sind legitim. D.h. eine optimales Ergebnis bei google Pagerank / Speed erreichen und das falsche Caching verhindern. Nur, weil wir vielleicht nicht alle der Bedürfnisse teilen oder sinnvoll finden, sind sie dennoch nicht als falsch zu bewerten.
Also liegt da die Herausforderung: wie kann beides gleichzeitig ermöglicht werden?
Die Rewrites sind z.B. nur so lange ein (kleines) Performanceproblem, wie sie nötig sind. D.h. wenn webEdition beim Abspeichern der Ressourcen z.B. direkt einen anderen Dateinamen nutzt (inkl. Zeitstempel) aber im Backend weiterhin den Dateinamen ohne Zeitstempel anzeigt, könnte das auch eine Lösung sein. Wie gesagt: könnte! Ich bin nicht in der Position, das im Detail zu wissen und zu bewerten. Es wird da auch noch massiv andere Lösungen geben. Wie machen es andere Systeme? Was hat sich bewährt? Es ist sicher immer sinnvoll, an solchen Stellen nicht nur in den eigenen Ideenwelten zu suchen.
Die Herausforderung für ein CMF sollte doch sein, die verschiedenen Bedürfnisse elegang zu lösen. Bislang hat webEdition dem Template Ersteller (ausser bei listview Navigationen und userinputs) die volle Kontrolle über den generierten Quelltext überlassen. Das ist nun durch ?m= ganz leicht aufgeweicht. Ist das sinnvoll? Die Rückmeldungen zeigen doch, dass es (neben google) da auch noch das Bedürfnis gibt, den Quellcode "aufgeräumt" zu haben etc.
Also: statt ideologisch zu sagen: was google da will ist quatsch, zumindest einmal überlegen, ob es nicht machbar wäre. Denn was nützt eine Newsseite mit aktuellem Bild, wenn sie bei dem de facto Suchmaschinen Standard nicht gefunden wird?
Ich klinke mich hier wieder aus, letzlich ist es Eure Entscheidung als webEdition Entwicklungsteam, welche Anforderungen an heutige Websites out-of-the-box unterstützt werden und welche nicht.
Ich wünsche Euch gute Ideen!
Thomas
-
- webEdition Partner
- Beiträge: 1825
- Registriert: Di 7. Mär 2006, 16:50
- Wohnort: Wien
- Kontaktdaten:
Re: Cache Parameter "?m=" und SEO
IMHO kommt das gar nicht von Google & Co., sondern aus einer Fehlinterpretation der Optimierungsvorschläge und -möglichkeiten. Die Maßnahmen sind in vielen Fällen auch grundsätzlich sinnvoll. Man kann und soll das aber nicht im blinden Gehorsam auf alles und jedes anwenden.
Im konkreten Fall geht es um Ressourcen (JS, CSS, Images). Hier kann man maximal bei Bildern duplicate Content erzeugen. Für die meisten Sites wird das nicht relevant sein. Also selbst wenn hier mit dem Parameter potentiell Duplikate erzeugt werden, wird das den Page Rank in keinster Weise beeinflussen!
Ob der .htaccess Workaround gerechtfertigt ist, kommt stark auf die konkreten Anforderungen an. Sobald diese Methode im großen Stil missbraucht wird, werden die Suchmaschinen reagieren und den Einsatz der Methode sanktionieren.
Für mich ergibt sich daher folgendes Bild:
Liebe Grüße,
Sascha
Im konkreten Fall geht es um Ressourcen (JS, CSS, Images). Hier kann man maximal bei Bildern duplicate Content erzeugen. Für die meisten Sites wird das nicht relevant sein. Also selbst wenn hier mit dem Parameter potentiell Duplikate erzeugt werden, wird das den Page Rank in keinster Weise beeinflussen!
Ob der .htaccess Workaround gerechtfertigt ist, kommt stark auf die konkreten Anforderungen an. Sobald diese Methode im großen Stil missbraucht wird, werden die Suchmaschinen reagieren und den Einsatz der Methode sanktionieren.
Für mich ergibt sich daher folgendes Bild:
- Der m-Parameter kann aktuell nicht deaktiviert bzw. gesteuert werden.
- Es spricht aktuell nichts handfestes gegen den Einsatz des m-Parameters für Ressourcen.
- Ja, der m-Parameter könnte optional gemacht werden. Jeder ist eingeladen entsprechenden Code beizusteuern oder zumindest einen Feature Request zu machen.
Liebe Grüße,
Sascha
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 27 Gäste