Noch mehr zu “WordPress-Themes optimieren”

Nachdem ich in den letzten beiden Artikeln (N Gedanken zu “WordPress-Themes optimieren” und Mehr zu “WordPress-Themes optimieren”) vor allem den Einbau der wichtigsten Elemente des HTML-Headers beschrieben habe, welche bei einem WordPress-Theme in der Regel (ohne Einsatz eines entsprechenden SEO-Plugins) fehlen, will ich heute die restlichen Elemente des Header besprechen. Sie sind teilweise nicht ganz unwichtig für die Suchmaschinenoptimierung.

Auch die heutigen Codes können wieder in die functions.php oder – noch besser – in ein Custom Plugin eingepflegt werden, welches alle bisher angesprochenen Funktionalitäten enthalten sollte. Ich denke, dass die bisherigen Beispiele auch eine gute Diskussionsgrundlage darstellen. Wer sich also berufen fühlt, Änderungen vorzuschlagen oder Details der vorgeschlagenen Lösungen in Frage zu stellen, kann das gern in den Kommentaren tun. Ich bin an einem Dialog, der die Thematik weiter beleuchtet und vertieft, sehr interessiert.

7. wp_head entschlacken (reloaded)

Man sollte den Header von Einträgen zu befreien, die man nicht unbedingt braucht. Ich hatte das schon in älteren Artikeln erwähnt, bin dort aber nicht so ins Detail gegangen. Wer sich den Header ansieht, den eine WordPress-Installation standardmäßig so „ausspuckt“, der steht vermutlich vor der Frage, ob man die Einträge braucht oder ob man sich nicht einfach dieser Dinge entledigen kann. Schließlich will man sich kein neues Problem schaffen, indem man einen vielleicht wichtigen Eintrag einfach entfernt.

<meta name="generator" content="..."/>

Dieser Eintrag verrät die Version der WordPress-Installation, was vermutlich nur für Cracker interessant ist. Mit

remove_action ('wp_head', 'wp_generator');

wird die Ausgabe unterbunden. Falls kein Blog-Client verwendet wird, der den RSD-Link benötigt, kann der entsprechende Eintrag mit

remove_action ('wp_head', 'rsd_link');

entfernt werden. Den WLWManifest-Link, der – meines Wissen nach – nur vom Windows Live Writer verwendet wird, wird man mit

remove_action ('wp_head', 'wlwmanifest_link');

los. Die zusätzlichen Feed-Links können mit den Anweisungen

remove_action ('wp_head', 'feed_links', 2);
remove_action ('wp_head', 'feed_links_extra', 3);

vermieden werden. Dazu komme ich später noch einmal. Die zusätzlichen Links im Kopfbereich sind Angaben, die Relationen zu anderen Seiten des Blogs anzeigen. Meines Wissens nach werden die Links nur von Opera als einzigem Browser unterstützt. Zudem ist der Nutzen bei den meisten Blogs für mein Empfinden eher zweifelhaft. Mit den Anweisungen

remove_action ('wp_head', 'index_rel_link');
remove_action ('wp_head', 'start_post_rel_link', 10, 0);
remove_action ('wp_head', 'parent_post_rel_link', 10, 0);

if (!remove_action ('wp_head', 'adjacent_posts_rel_link', 10, 0))
    remove_action ('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0);

wird man auch diese Zeilen los. Die letzten beiden Zeilen sind auf eine Umbenennung der WordPress-Action zurückzuführen, die ich nicht sofort bemerkt hatte. Ich habe mich dafür erst an Frank Bültge gewendet, der schon vor einiger Zeit einen Artikel zum Thema verfasst hatte. Allerdings war ihm wohl das Problem, welches mit WordPress 3.0 dann scheinbar aktuell wird, noch nicht bekannt, sodass ich mir die Quellen genauer angesehen habe, um dann schließlich diesen Fakt festzustellen.

8. Der „gesäuberte“ WordPress-Header

Nachdem die Säuberungsaktion durch ist, sollten wir uns noch einmal den Header ansehen. Der Quelltext ist im Template-Verzeichnis in der header.php zu finden. Ein Vergleich der Sourcen mit der Ausgabe im Browser ist jetzt durchaus sinnvoll. Je nach WordPress-Theme ist die Datei header.php mehr oder weniger umfangreich. Im Augenblick will ich mich aber weiterhin nur auf die Angaben bis zum einleitenden <body>-Tag konzentrieren, was in etwa so aussehen kann:

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
 </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That’s an error.</ins>
  <p>The requested URL <code>/svn/trunk/examples/header.php</code> was not found on this server.  <ins>That’s all we know.</ins>

Die ersten Angaben sind natürlich von Blog zu Blog verschieden. Ich benutze hier XHTML 1.1, was vermutlich reine Geschmackssache ist. Auffällig ist wahrscheinlich die Angabe für den IE8 vor dem Title, über den ich schon im letzten Jahr gemeckert habe. Als nächstes fallen eventuell die Sprachangaben auf. Ich halte es für wichtig, die  Suchmaschinen dabei zu unterstützen, die Sprache feststellen zu können.

Nach dem Title und noch vor der Anweisung wp_head() wird das CSS eingebunden, um die Styles aus Performance-Gründen noch vor dem JavaScript zu laden. Aber dazu komme ich im nächsten Abschnitt noch. Weiter unten folgen dann die Verweise zum RSS-Feed der Artikel und zum Commentar-Feed und am Ende wird das Favicon eingebunden. Sicher gehört das Icon nicht zu den wichtigsten Angaben. Aber es ist auch nicht ganz unwichtig.

Falls ihr nicht vorhabt, WordPress mehrsprachig zu verwenden, können alle Werte, wo bloginfo() notiert wurde, auch mit festen Pfadangaben ersetzt werden, um noch ein oder zwei Millisekunden zu sparen. Ansonsten ist der Header soweit optimiert, dass man diese Arbeiten ausführen und dann vergessen kann, weil vorläufig an dieser Front nichts mehr zu tun ist. Abgesehen von einer Sache …

9. CSS und auch JavaScript-Datei zusammenführen

Ich hatte es ja eben schon angesprochen, dass ich das CSS vor dem JavaScript laden möchte. Das wird mit einigen Plugins natürlich reichlich witzlos. Um nicht nach jedem Plugin-Update diesem Problem hinterherzuhetzen, könnte man versuchen, hier in irgendeiner Form einzugreifen, was ich natürlich schon ausgiebig (und erfolglos) getestet habe. In jedem Fall würde das nur eine speziell auf das Blog bezogene Optimierung darstellen, die eher unbefriedigend läuft.

Im Augenblick setze ich dafür ein Plugin ein. Autoptimize ist das entsprechende Plugin, welches von Emilio López stammt und auf das ich vor einiger Zeit durch einen Artikel von my GettoWEB.DE aufmerksam gemacht wurde. Autoptimize ist in der Lage die CSS-Files  und alle JavaScript-Files zusammenzufassen. Außerdem verschiebt es das JavaScript an das Ende des HTML-Documents. Zudem können alle Ausgaben bei Bedarf komprimiert werden. Im Moment macht es hier einen ganz guten Eindruck.

An der Stelle schließe ich den heutigen Artikel. Der Header ist soweit abgeschlossen. Ob es einen nächsten Teil gibt, muss ich erst einmal sehen. Eventuell fasse ich nur das bisher  Geschriebene noch einmal zusammen und verlinke zu Quellen, die weiterführende Themen beschreiben. Mal schauen, was sich so ergibt.

N Gedanken zu “WordPress-Themes optimieren”

Wenn man sich so durch die Suchergebnisse klickt, die man erhält, wenn man nach Möglichkeiten sucht, dass eigene Theme onpage zu optimieren, wird man von den Tipps geradezu erschlagen. Die vorgeschlagenen Änderungen, um ein Blog für die Suchmaschinen fit zu machen, reichen von kleineren Modifikationen in den Template-Files selbst bis hin zur Installation eines SEO-Plugins.

Im Gegensatz zum Plugin, wo man im Regelfall davon ausgehen kann, dass es seinen Zweck sofort erfüllen wird, ist das Schreiben in den Dateien des eigenen Themes nicht ganz ungefährlich, (vor allem) wenn man noch unerfahren ist. Andererseits sollte man eventuell auch mehr über die Einstellungsmöglichkeiten eines Plugins wissen, wenn man sich denn für den Einsatz einer solchen Erweiterung entscheidet. Oft werden die Grundeinstellungen ausreichend aber nicht unbedingt optimal sein.

Zudem ist die Optimierung ja eigentlich nie abgeschlossen. Im besten Fall hat man an den Templates und den Einstellungen nur noch wenig zu schrauben. Oftmals ist es dann sogar besser, diesen Teil der Optimierung für eine Weile zu vergessen und sich mehr auf den Content und die (externe  oder interne) Verlinkung zu konzentrieren.

1. Immer schön vorsichtig bleiben

Wer sich für die Optimierung des Blogs ohne Plugin entscheidet, sollte die vorangegangen Überlegungen immer im Hinterkopf behalten. Zudem sollte alle Änderungen immer erst auf einer Testinstallation durchgeführt werden. Ob nun lokal oder mit einer weiteren Worpress-Installation auf einem Subhost des Zielsystems ist dabei vom persönlichen Geschmack abhängig.

Bei der Testinstallation sollte auf jeden Fall darauf geachtet werden, dass sowohl die Datenbank-Inhalte als auch die verwendeten Plugins weitgehend mit dem Zielsystem übereinstimmen. Wenn man möglichst nah an der eingesetzten Lösung bleibt, kann man sich einige Überraschungen schon im Vorfeld ersparen.

2. Wo sind die Änderungen durchführen?

Die meisten Tipps, die mir bisher so über den Weg gelaufen sind, zielen auf Änderungen in den Template-Dateien oder auf Erweiterungen in der functions.php des verwendeten WordPress-Themes. Das halte ich so pauschal gesagt für falsch. Der Grund dafür ist folgender:

Früher oder später gefällt einem das seit Ewigkeiten eingesetzte Theme vielleicht nicht mehr und der Wunsch zu wechseln wird immer stärker. Unter Umständen ist das Unterfangen aber gar nicht mehr so einfach durchzuführen, weil viele der lieb gewonnenen Funktionalitäten inzwischen so fest im alten Theme „verankert“ sind, dass ein Wechsel fast einem Neuanfang gleicht.

Bevor also ohne großes Nachdenken los programmiert wird, sollte man sich erst einmal fragen: Ist das tatsächlich eine Änderung, die nur diese eine Datei betrifft? Dies betrifft beispielsweise oft nur die (noch zu besprechende) Korrektur der Anweisung wp_title() in der header.php. Als nächstes sollte man sich fragen, ob man die Funktionalität eventuell öfter brauchen könnte bzw. ob die geplante Änderung auch noch benutzt werden soll, wenn man irgendwann einmal ein anderes WordPress-Theme einsetzt.

Stellt sich heraus, dass die geplante Optimierung, Erweiterung oder Funktionalität auch in zukünftigen Themes Verwendung finden kann, bietet sich das Auslagern der Funktionalitäten in ein Custom Plugin an, was sich erst einmal viel schwieriger anhört, als es in Wirklichkeit ist.

Eine Datei, die sich im Verzeichnis /wp-content/plugins befindet und einen bestimmten Header aufweist, wird automatisch als Plugin erkannt und ist aktivierbar, wenn der Code keine Fehler hervorruft. Einen Einstieg bietet das BlueLight-Plugin, dass ich bereits vor einiger Zeit vorgestellt hatte.

3. Das Title-Tag ist das A und O

Das mit Abstand wichtigste Element ist der Titel einer jeden Seite. Es gibt immer noch tonnenweise Websites, deren Seiten „Unbenannt“, „Unbekannter Titel“ oder so ähnlich heißen. Mal abgesehen davon, dass der Titel aller Seiten einer Website einzigartig sein sollte, verspüren wohl nur die wenigsten Suchenden Lust, auf so ein Ergebnis zu klicken, wenn es denn überhaupt den Weg in die Suchergebnisse schafft.

Mit WordPress hat man hier schon etwas mehr Glück, trotzdem gibt es noch einiges nachzubessern. Ich will hier keineswegs die Frage beantworten, wie man das Title-Tag schlussendlich optimal gestaltet. Da gibt es ganz sicher weit qualifiziertere Antworten von anderer Seite. Wie dieser Titel von WordPress bereitgestellt werden kann, ist für mich im Augenblick viel spannender. Einen ersten Vorschlag soll folgender Code veranschaulichen, der sowohl in der functions.php oder noch besser in einem Custom Plugin Verwendung finden könnte:

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
 </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That’s an error.</ins>
  <p>The requested URL <code>/svn/trunk/examples/my_title.php</code> was not found on this server.  <ins>That’s all we know.</ins>

An meinem Lösungsvorschlag sollten mindestens zwei Dinge auffällig sein. Erstens habe ich den Blog-Claim an das Ende des Titels gestellt. Ich nehme an, dass die wenigsten Blogger Probleme damit haben, ihren gewählten (und hoffentlich) einzigartigen Blog-Namen an die Spitze der Suchergebnisse zu bekommen. Dass sich wichtige Schlüsselwörter zudem auch im Title-Tag befinden sollten, ist sicher weder ein Geheimnis noch eine Überraschung.

Die Seitentitel werden von den Suchmaschinen in der Regel gekürzt, wenn sie eine bestimmt Länge überschreiten (zwischen 60 und 70 Zeichen). Deshalb bietet sich dieses Vorgehen schon einmal an. Schließlich soll der Titel den Suchenden zum Klicken animieren und gleichzeitig die Suchmaschine von der Relevanz der Seite überzeugen.

Außerdem lese ich die Information aus, ob es sich um eine Folgeseite bei den Archiven oder Kategorien handelt. Ich hatte ja vorher schon angemerkt, dass ein Seitentitel immer einzigartig sein sollte. Das ist in diesem Fall sichergestellt. Zumindest habe ich auf meinem Blog bisher nichts Gegenteiliges feststellen können.

An dieser Stelle schließe ich erst einmal den Artikel. Es gibt doch mehr zu dem Thema zu sagen, als ich ursprünglich angenommen hatte. Nach mehr als 800 Wörtern liegt aber die Entscheidung nahe, eine Artikelserie zu starten. Für den nächsten Artikel habe ich geplant, die Meta-Tags zu besprechen. Dort gibt es ja auch noch einiges zu tun!

wp_head() entschlacken

Das ist auch wieder so ein Tipp, den ich mir gleich mal aufschreiben muss. Zur Zeit beschäftigt mich bei dem Projekt Reisen nach Sizilien auch die Code to Text Ratio, die das Verhältnis von Quellcode zum tatsächlichen Text beschreibt und vermutlich nicht nur für die Suchmaschinenoptimierung interessant ist. Die Größe der Seiten wird am Ende des Unterfangens viel kleiner sein und kürzere Ladezeiten sind sicher.  Ich setzte bei einigen Projekten auf WordPress als CMS. Aber was da so in den Kopfbereich jeder Seite „geschmiert“ wird, stört mich schon länger.

Ein weiteres Argument, welches im Artikel wp_head aufräumen des WordPress-Magazin zu Sprache kam, ist der Sicherheitsaspekt. Tatsächlich sollte man nicht jedem potentiellen Angreifer helfen, in dem man die genaue Version der WordPress-Installation verrät. Der im Artikel gelieferte Code beseitigt schon einiges. Ich wollte zudem den zusätzlichen Link zum Stylesheet des WP-Pagenavi-Plugins unterbinden und habe gleich noch

[code lang=“php“]remove_action(‚wp_head‘, ‚pagenavi_css‘);[/code]

hinzugefügt. Einen anderen Tipp hatte ich zuvor im Artikel wp_head-Hakeleien des Expertinnen-Web gefunden habe. Mal abgesehen davon, dass der Artikel schon recht alt ist, gefällt mir die Idee nicht so gut, den entsprechenden Aufruf direkt im Code eines Plugins auszukommentieren. Man müsste dann bei jedem Update die entsprechende Zeile auf’s neue heraussuchen, was auch schnell einmal vergessen wird.

Have fun!