Gedanken zu SEO, Stichwort: Doppelter Content

[Michael_G]

Vielen lieben Dank, Olaf!

Das werde ich heute Abend gleich ausprobieren und ich freue mich auch schon sehr auf die später folgende Zusammenstellung!
(kein Stress, das waren eben bestimmt die entscheidenden Codezeilen, die ich jahrelang gesucht hatte!)

[cmb]

Code: Select all

# Umgezogene Seiten melden:
RedirectPermanent /Computer/CMS https://domain.tld/Computer/Software/CMS

# Nicht mehr vorhandene Seiten aus dem Index nehmen lassen:
Redirect gone /Gibbetnetmehr/

Wenn das bei URLs mit Fragezeichen funktionieren würde, wäre Moved_XH obsolet.

Moved_XH tut eigentlich nichts, was nicht auch mit Apache-Modulen bewerkstelligt werden könnte. Allerdings stehen diese nicht jedem zur Verfügung, und auch deren Nutzung ist nicht unbedingt einfach – daher das Plugin. (Und auch ein bisschen, um den Webmastern klar zu machen, dass man Seiten nicht einfach löschen sollte, weil eben externe Links dann ins Leere laufen.)

Konkret: du nutzt Redirect* Anweisungen, die soweit ich weiß von Apache immer unterstützt werden. Die weit mächtigeren Rewrite* Anweisungen von Olaf sind nur verfügbar, wenn mod_rewrite aktiviert ist (ggf. beim Provider um Aktivierung bitten).

[Holger]

Hallo zusammen!

Interessanter Thread.

Nur eine kurze Frage zum kanonischen Link:

Code: Select all

<link rel="canonical" href="http://domain.tld/">

Was ist, wenn die Seite mit Query-Parametern aufgerufen wird?

Sollte

Code: Select all

http://domain.tld/?Startseite&parm=1

nicht den Link

Code: Select all

<link rel="canonical" href="http://domain.tld/?&param=1">

generieren .

LG
Holger

[svasti]

Könnten wir nicht in 1.7 überhaupt einbauen, dass
http://domain.tld/?Startseite zu
http://domain.tld/ wird?

Vielleicht könnte man die interne Verlinkung mit $u[0] = BasisURL setzen?

[cmb]

Was ist, wenn die Seite mit Query-Parametern aufgerufen wird?

Ich bin der Meinung, dass das vom jeweiligen Fall abhängt. Z.B. sind Parameter bei Realblog, Forum, und allgemein bzgl. einer Paginierung sehr wichtig für den kanonischen Link. Manche Parameter (z.B. print) hingegen sollten auf keinen Fall im kanonischen Link auftauchen. Eine wirklich saubere Lösung, um das zu unterscheiden, wäre erstrebenswert, aber da müssten wohl Plugins entsprechend mitarbeiten. Ansonsten fällt mir nichts besseres ein als die Lösung, die schon seit langem auf 3-magi.net läuft:

Code: Select all

/**
 * Returns the canonical link tag.
 *
 * @param string $prefix  'www' or ''.
 * @param array $ignore_keys
 * @return string
 */
function canonical($prefix, $ignore_keys = array()) {
    global $sn, $su, $u;

    $params = $_GET;
    if (count($params) > 0 && key($params) == $su)
    array_shift($params);
    ksort($params);
    if (!empty($prefix)) $prefix .= '.';
    $rsn = preg_replace('/index.php$/i', '', $sn);
    $server_name = preg_replace('/^www./i', '', $_SERVER['SERVER_NAME']);
    $rsu = $su == $u[0] ? '' : $su;
    $url = 'http://'.$prefix.$server_name.$rsn;
    $query = $rsu;
    foreach($params as $key => $val) {
    if (!in_array($key, $ignore_keys)) {
        $query .= '&'.$key;
        if (!empty($val)) $query .= '='.$val;
    }
    }
    if (!empty($query)) $url .= '?'.$query;
    $link = tag('link rel="canonical" href="'.$url.'"')."\n";
    return $link;
}

Aufgerufen wird die Funktion im Template:

Code: Select all

<?php echo canonical('', array('login'))?>

(Und wie ich sehe, müsste ich da wohl mal nachbessern.)

Könnten wir nicht in 1.7 überhaupt einbauen, dass
http://domain.tld/?Startseite zu
http://domain.tld/ wird?

Bin nicht ganz sicher, da ohne explizite Angabe der Startseite ja wieder das leidige $s Problem auftritt. Falls wir letzteres nicht für XH 1.7 in den Griff bekommen, dann wäre vielleicht die umgekehrte Variante eine Lösung, obwohl das wohl erst recht Probleme macht.

[Holger]

Ich bin der Meinung, dass das vom jeweiligen Fall abhängt. Z.B. sind Parameter bei Realblog, Forum, und allgemein bzgl. einer Paginierung sehr wichtig für den kanonischen Link.

Sehe ich auch so.

Manche Parameter (z.B. print) hingegen sollten auf keinen Fall im kanonischen Link auftauchen.

Gut, aber welche genau? Welche Parameter erzeugen denn nicht die gleichen Ausgabe beim Aufruf der Domain gegenüber dem Aufruf der ersten Inhaltsseite?

Und warum eigentlich "&print"?
http://domain.tld/?Startseite&print ist doch genau identisch mit http://domain.tld/?&print. Warum also den kanonischen Link zum erstgenannten Url hier gerade nicht setzen? Es erscheint mir unlogisch, für http://domain.tld/?Startseite&print den kanonischen Link http://domain.tld/ zu setzen. In der Druckversion einer Seite fehlen doch alle Inhalte / Links oder Pluginausgaben aus dem Template... . Für mich sind das keine identische Seiten.

Nochmal zur Klarstellung: ich rede hier ausschließlich nur vom DC-Problem mit der ersten Inhaltsseite.

[cmb]

Nochmal zur Klarstellung: ich rede hier ausschließlich nur vom DC-Problem mit der ersten Inhaltsseite.

Upps, da hatte ich den Kontext aus den Augen verloren. Sorry!

[Holger]

Hallo zusammen!

Hier mal der Entwurf eines Plugins, mit dem man die hier im Thread dargestellten DC-Probleme auch lösen kann.
http://holgerirmler.de/temp/adc_0.1beta.zip

Realisiert sind 301 Redirects für Requests
- per http oder https
- mit www oder ohne www
- entfernen von index.php

Außerdem wird auf der ersten Content-Seite ein kanonischer Link nur zu Domain/Pfad/ mit ansonsten komplettem Query-String generiert.

Das ist zwar alles nicht so elegant wie mit .htaccess, aber unerfahrenere User können sich so einfacher die gewünschte Konfiguration zusammen klicken, denke ich.
Und vielleicht wird das DC-Problem damit dann öfter angegangen und (hoffentlich auch) behoben.

BTW: beim konstruieren der URLs habe ich, soweit noch halbwegs sinnvoll, nur str*() - Funktionen anstatt preg*() - Funktionen verwendet. Angeblich soll das ja "besser" (bzw. schneller) sein. Macht das im konkreten Fall denn Sinn? Wenn nicht könnte man am Code auch noch zwei, drei Zeilen sparen...

LG
Holger

[olape]

Hallo,

oje, da habe ich ja wieder was angerichtet.

Im Ernst, ich finde es prima, dass sich jetzt doch wieder einige Leute verstärkt Gedanken um das Thema machen.

@Holger

Für mich sind das keine identische Seiten.

Doppelter Content ist wohl auch schon, wenn sich grosse Teile des Inhaltes gleichen.
Was bei der Druckansicht der Fall wäre.
Ausserdem finde ich es nicht sinnvoll, wenn die Druckansicht überhaupt gelistet werden würde. (Das ist mir mit dem originalen CMSimple von Peter oft passiert. Wobei zur der Zeit, glaube ich, noch keiner so richtig über doppelten Content nachgedacht hat.)
Von daher kann die Suchmaschine also ruhig erfahren, das die eigentliche URL eine andere ist.
Davon abgesehen, steht in der Druckansicht bereits noindex.
Theoretisch sollte also aus der Richtung eh nix passieren. Aber schaden würde der kanonische Link sicher auch nicht.

Webshopbetreibern beispielsweise, wird nahe gelegt, bei gleichartigen Artikeln darauf zu achten, dass sich nicht auch die Beschreibung in grossen Teilen gleicht. Der Bequemlichkeit halber, da nehme ich mich nicht aus, wird oft ein Artikel kopiert und dann nur geringe Teile angepasst. Auch das ist der Sache aus dieser Sicht wohl eher abträglich.

Klar ist, es gibt recht viele, oft auch sehr unterschiedliche Meinungen.
Man sollte das ganze auch nicht übertreiben.
Eine Lösung, die es so gut wie es möglich umsetzt, wäre schon viel Wert.

Gruss Olaf

[cmb]

Hier mal der Entwurf eines Plugins, mit dem man die hier im Thread dargestellten DC-Probleme auch lösen kann.

Super!

BTW: beim konstruieren der URLs habe ich, soweit noch halbwegs sinnvoll, nur str*() - Funktionen anstatt preg*() - Funktionen verwendet. Angeblich soll das ja "besser" (bzw. schneller) sein. Macht das im konkreten Fall denn Sinn? Wenn nicht könnte man am Code auch noch zwei, drei Zeilen sparen...

Schneller sind die str_* Funktionen im Zweifel schon, aber es kommt natürlich immer auf den konkreten Fall an, und libpcre ist schon sehr aufwendig optimiert, und ext/pcre hat auch noch zusätzlich einen Cache für kompilierte Ausdrücke, so dass zumindest bei mehrfacher Verwendung des selben Ausdrucks und gerade wenn pcre.jit=1 (gibt's ab PHP 7.0.0) ist, der Performance-Unterschied nicht mehr allzu groß sein dürfte.

Wenn Du trotzdem bei str_* Funktionen bleiben möchtest, dann könntest Du folgende Ersetzung in Erwägung ziehen:

Code: Select all

if (strtolower(substr($path, -9)) == 'index.php') {

wird zu:

Code: Select all

if (strripos($path, 'index.php', -9) == strlen($path) - 9) {

Das erspart die Konstruktion eines neuen Strings (durch substr()), und strlen() ist ziemlich schnell (O(1)), da die Länge des Strings gespeichert ist (und nicht wie z.B. bei C erst ermittelt werden muss).