webconsul

Vermutungen gibt es aktuell zu hauf, dass Google schnelle Websites puscht und besser rankt.

Seit ein paar Tagen optimiere ich fleißig an meinem Blog und ja, ich habe es bemerkt und es lässt sich ganz einfach bestätigen.
Der Graph in der Google Webmaster Zentrale (Link) hat sich seit diesem Beitrag nicht aktualisiert, müsste aber weiter nach unten gegangen seit.

Google Analytics zeigt in den letzten Tagen einen enormen Peak:

Aber das untrüglichste Zeichen ist es, wenn auch andere auf den Zug aufspringen, Google zu den unterschiedlichsten Themen crawlen und innerhalb von weniger als 24 Stunden man folgenden Dashboard-Auszug sieht:

»» Ja, Google rankt jetzt schon schnellere Websites besser. Punkt.

Soeben habe ich es im WordPress Deutschand-Blog gefunden und kann dem Artikel memory size of xxx bytes exhausted – es nervt langsam gewaltig aus vollem Herzen zustimmen!

Lest die Analyse von Heiko Rabe durch und werft auch mal einen Blick auf seine anderen Entwicklungen!
Der Junge ist in Sachen WordPress echt fit und hat einiges auf dem Kasten und teilt das auch.
Also husch husch, rüber zu ihm

Jeder der sich schonmal überlegt hat ein WordPress Theme zu schreiben, egal ob als Webdesigner, Programmierer, Admin oder User ist bestimmt schon an den gleichen Faktoren gescheitert bzw. hängen geblieben:
5 things to know before starting to design a WordPress theme

Warum liebe WordPress-Entwickler gibt es nicht überall Funktionen analog zu the_title() wie get_title() der den Titel nicht in das Theme schreibt sondern zur Weiterverwendung als String im Layout zurückgibt?
Das würde es stark vereinfachen ein gutes Webdesign für WordPress zu gestalten.

Nicht nur alle Theme-Designer werden sich freuen, auch die Admins von WordPress-Blogs freuen sich und der Programmierer zuletzt, da er selbige Funktionen nicht händisch in der Theme-eigenen functions.php einbinden muss.
Schließlich soll es so Freaks geben, die aus Geschwindigkeitsgründen lediglich eine style.css sowie eine index.php in ihrem WordPress Theme Verzeichnis liegen haben.

Ja und ich gehöre mit fast allen meinen Blogs dazu
Gerade in Blogs in denen man nicht einfach WP-Cache oder ähnliche WordPress-Plugins verwenden kann, erspart man sich so diverse Includes, Festplatten- und Prozessorlast.
Falls das einer liest, denkt mal drüber nach

Seit einiger Zeit bemerke ich höhere Bot-Aktivität in meinem webconsul-Blog, weshalb ich vor einiger Zeit schon Scraperbots anhand deren User-Agents aus meinem Blog ausgeschlossen habe.

Will man aber nun Blogs/Seiten finden, die den eigenen Content übernehmen, sei es über den RSS-Feed (den man nur gekürzt ausliefern sollte) oder über Yahoo! Pipes oder was auch immer, dann kann man seine Artikel mit einem einfachen Trick in Google wiederfinden.

Dazu müsst ihr nur in eurem Theme-Verzeichnis die Artikel-Seite (index.php, page.php, article.php, single.php, …) öffnen und jeweils vor oder nach dem Aufruf von the_content() foldendes einfügen:

echo "<!-- ".md5(the_title())." -->";

Oder entsprechend mit umschließenden PHP-Tags:

<?php echo "<!-- ".md5(the_title())." -->"; ?>

Damit könnt ihr dann später nach dem jeweiligen MD5-String suchen.

Das ist der neu eingefügte String im obig verlinkten Artikel.

Diesen tippt ihr einfach in die Google-Suche ein und falls ihr fündig werdet, wisst ihr, dass eure Content auch auf anderen Seiten publiziert wurde.

Sollte dies geschehen, solltet ihr je nach Lust und Laune einen RSS-Cloaker installieren, der je nach IP-Adresse anderen Content ausliefert. Den bösen Jungs jubelt ihr dann einfach eure SEO-Links oder Spam-Content unter, sodass sie entweder euch einen Gefallen tun oder selbst aus Google fliegen.

Be creative

PS: Ja, es gibt Möglichkeiten dies zu umgehen, aber ich will an dieser Stelle nicht erklären, wie man PHPs strip_tags() oder reguläre Ausdrücke verwendet

Seit einiger Zeit tummeln sich diverse Crawler auf meinem Blog, die meine Inhalte übernehmen und auf anderen Seiten veröffentlichen.
Das wäre ja kein Problem, wenn man das entsprechend mit angibt.

Daher habe ich nun folgende drei Schritte unternommen um automatisches Scrapen zu erschweren:

1. RSS-Feed auf Kurzfassung umgestellt: Admin-Panel -> Einstellungen -> Lesen -> Newsfeed Kurzfassung
2. Yoasts RSS Footer Plugin um einen Link und eine Ursprungsnotiz hinzuzufügen
3. Die index.php von WordPress folgendermaßen modifiziert:


<?php
// Bots und Scraper ausschliessen:
function botcheck($ua) {
  $matches = array("java", "libwww", "perl", "curl");
  for($i=0; $i<sizeof($matches); $i++)
    if(stristr($ua, $matches[$i])) {
      return true;
    } else {
      return false;
    }
}

if(botcheck($_SERVER['HTTP_USER_AGENT'])) {
  echo "Böser Bot: geh weg!<br/>Falls Du doch kein Bot bist, überprüfe bitte deinen User-Agent.";
} else {
  define('WP_USE_THEMES', true);
  require('./wp-blog-header.php');
}
?>


Ist zwar im Sinne der Rechenleistung und Website-Geschwindigkeit nicht optimal, aber zumindest werden alle Bots die sich im User-Agent mit Java, Perl und vielem mehr ausgeben entsprechend mit einer Meldung abserviert.
Die Modifizierung muss direkt in der Index-Datei im WordPress-Root-Verzeichnis gemacht werden, da diese die restliche Auslieferung vorantreibt. Im WordPress Theme selbst funktioniert das nicht.

Klar, das löst nicht alle Probleme, aber zumindest erschwert es die Sache etwas und plumpes Content-Scraping funktioniert damit nun nicht mehr.

Schauen wir mal, welcher Bot zuerst seinen User-Agent umstellt

PS: Natürlich werden einige Bots auch über die robots.txt blockiert, aber Scraper halten sich leider nicht daran

Um Duplicate Content in einem WordPress-Blog zu vermeiden, habe ich heute (leider etwas zu spät) folgende Erweiterung in meinem webconsul WordPress-Theme in den <head>-Tag eingefügt:

<?php
if((is_home() && ($paged < 2 )) || is_single() || is_page() || is_category()){
    echo '<meta name="robots" content="index,follow" />';
} else {
    echo '<meta name="robots" content="noindex,follow" />';
}
?>


Damit werden alle Seiten außer der Startseite, einer Beitragsseite oder einer Kategorie mit noindex geblockt und somit auch nicht von Google als Duplicate Content zu erkennen geben.

Erläuterung: Das Problem rührt daher, dass die Archiv-Seiten der jeweiligen Monate und Co entsprechend sonst die gleichen Inhalte ausliefert.
Aber ich gehe davon aus, dass Google das selbst berücksichtigt, insofern viele Blogs selbige Technik nicht verwenden, daher lasst euch nicht beunruhigen, aber wenn ihr mal 30 Sekunden Zeit habt, dann baut das mit ein.

Joost de Valk hat auf dem irländischen WordCamp eine spannende Präsentation zu WordPress SEO gehalten.

Der Live-Mitschnitt wird im wordpress.tv veröffentlicht und ist bei Joost direkt oder hier schon einsehbar:

Wie ihr über das Wochenende sicher bemerkt habt, hatte dieser Server am Wochenende mehrmals Schluckauf, was dem Speicherengpässen zuzurechnen ist.

Sowohl der Arbeitsspeicher als auch die Swap-Partition liefen regelmäßig voll, da die Requests nicht mehr bearbeitet werden konnten.

Dies ist nun über einen einfachen aber sehr wirkungsvollen Hack gelöst.
Alle 45 Minuten wird nun der jeweilige Blogindex manuell gecached und somit als statische Variante ausgeliefert.
Das funktioniert einfach in der Verbindung mit cron (*/45 * * * * /home/pw/bin/cron.sh 2>&1 /dev/null) und:

/usr/bin/wget -N -q -O /.../www/domain1.org/index.html http://www.domain1.org/ondex.php
/usr/bin/wget -N -q -O /.../www/domain2.de/index.html http://www.domain2.de/ondex.php


Das funktioniert einfach und gut. Vorher muss nur die alte index.php von WordPress in ondex.php umbenannt werden (oder ihr ändert einfach die Auslieferungsreihenfolge von index.php auf zuerst index.html) und gegebenenfalls die Permalinks abgeändert werden, in diesem Fall auf:
/ondex.php/%category%/%year%/%monthnum%/%postname%/

Der Vorteil gegenüber herkömmlichen Caching-Plugins wie WP-Cache, WP Super Cache und Co ist schlichtweg, dass alle PHP-Interpretationen und MySQL-Aufrufe eliminiert werden und so zumindest auf der jeweiligen Startseite keine unnötige Speicherbelastung vorkommt.
Die jeweiligen Unterseiten werden, zumindest bei mir, dann über WP-Cache bedient, denn dort sind die Speicheraufrufe weniger interessant, da der meiste Traffic einfach auf der Startseite ankommt.

Der 45 Minutenintervall wird verwendet, da meine Blogs meist zu diesen Zeiten geupdatet werden.

Damit könnt ihr loslegen und euch einiges an Speicher sparen.

Soeben habe ich eine menge Blogs auf das neue WordPress 3.0 mit dem Releasenamen “Thelonious” in der de_DE-Version portiert.

Bei den meisten Blogs hat das Upgrade problemlos funktioniert, nur bei einem leider nicht.
Der Blog zeigt an sich nur statische Seiten an, weswegen ich mein Template so umgebogen habe, dass es keine weiteren Funktionen gibt und lediglich eine Theme-Datei geladen werden muss.

Um möglichst viele Rechenoperationen zu sparen hatte ich im Design für die Anzeige des Contents lediglich geschrieben:

Das führte dazu, dass nach dem Update der gesamte Content nicht angezeigt wurde.

Das Problem lässt sich einfach lösen, wenn man den Inhalt mit folgendem Code anzeigt:

Rechnet zwar ein paar Millisekunden länger aber das sollte keine Probleme machen.

Daher noch ein paar Empfehlungen für eine schnelle Auslieferung:

Aktuell entwickle ich wieder an einem WordPress-Plugin um kontextabhängig Produkte aus der Zanox-API anzuzeigen.

Das ganze basiert auf über den Ajax-Callback und benötigt damit keine weiteren Serverkapazitäten (zumindest auf der Seite des Webseitenbetreibers).

Das Plugin gibt es wie die anderen dann auf der WordPress Extend Seite bei den Plugins oder hier.
Wer es vorher haben und testen will, soll mir einfach kurz eine eMail schreiben.