WordPress-Werkeleien in Sachen Performance und Social Share

In den letzten Tagen habe ich mich mal wieder der Verbesserung einiger Funktionen hier in diesem Blog  gewidmet. Es nervte mich, dass Google meine Blogs als nicht mobile-friendly einstufte, obwohl ich auf allen Blogs responsive Themes verwende.
Dann schlug Google Analytics nicht an, obwohl ich beispielsweise hier im Blog unter den “Seashell”-Theme-Einstellungen den Tracking-Code eingebunden hatte. Es lag also einiges im Argen und ich musste wohl oder übel mal wieder recherchieren, um diese Bugs zu beheben.

Trotz responsive Theme nicht mobile-friendly?

Sonderbarerweise war in den Google-Suchergebnissen in grüner Schrift bei einigen Beiträgen vermerkt, dass mein Blog nicht für mobile Geräte optimiert sei. Der selbe Hinweis erschien im Tool für den Test auf Optimierung auf Mobilgeräte. Wie kann das sein? Ich verwende mittlerweile in allen Blogs Templates, die für die mobile Ansicht optimiert sind.

Die Retterin in der Not war Judith mit ihrem Beitrag, in dem sie beschreibt, dass eine Änderung der robot.txt-Datei bei ihr zu dem gewünschten Erfolg führte. Und tatsächlich, nachdem ich meine robot.txt-Datei abgespeckt hatte, wurde diese von Google immerhin schon einmal als mobile-friendly eingestuft.

Meine robot.txt-Datei sah vorerst so aus:

User-agent: Googlebot-Image
Disallow: Allow: /*
User-agent: Mediapartners-Google
Disallow: Allow: /*

User-agent: duggmirror
Disallow: /

# global
User-agent: *
Disallow: /cache/
Disallow: /cgi-bin/
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /kommentare-abonnieren/
Disallow: */trackback/
Disallow: */comments/
Disallow: *?replytocom
Disallow: /*?
Allow: /wp-content/uploads/

Herausgenommen hatte ich die Einträge

Disallow: /wp-content/plugins/
Disallow: /wp-content/cache/
Disallow: /wp-content/themes/
Disallow: /trackback/
Disallow: /comments/

und

User-agent: Twitterbot
Disallow:/cache/
User-agent: *
Disallow:/cache/

Wobei letzteres wohl nichts mit der Problematik zu tun haben dürfte.

Verblieben waren allerdings noch Fehlermeldungen die besagten, dass Probleme beim Laden der Seite auftreten. Also recherchierte ich weiter und fand eine weitere Dokumentation zu robot.txt-Einträgen. Daraufhin ergänzte ich sie und nun sieht bei mir die Datei so aus:

User-Agent: Googlebot
Allow: .js
Allow: .css
User-agent: Googlebot-Image
Disallow: Allow: /*
User-agent: Mediapartners-Google
Disallow: Allow: /*

User-agent: duggmirror
Disallow: /

# global
User-agent: *
Disallow: /cache/
Disallow: /cgi-bin/
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /kommentare-abonnieren/
Disallow: */trackback/
Disallow: */comments/
Disallow: *?replytocom
Disallow: /*?
Allow: /wp-content/uploads/

Geschafft! Google erkennt meine Blogs nun endlich als mobilfreundlich und fehlerfrei an.

Unvollständige Anzeige beim Teilen auf Google+

Mich fuchste es, dass beim Anklicken auf den Google+-Share-Button lediglich das Bild und “sylvis-blog.de” angezeigt wurde. Es erschien weder der Beitragstitel noch ein Ansatz des einleitenden Textes. Merkwürdigerweise ist das in meinem Zweitblog nicht der Fall. Das Plugin “Shariff Wrapper” kann nicht daran schuld sein – das verwende ich auch in dem besagten Zweitblog.

Allerdings hatte ich Yoast SEO in Verdacht und noch einmal sämtliche Einstellungen darin überprüft, denn im anderen Blog ist All in One SEO Pack im Einsatz. Aber keine Chance. Auch an gegebenenfalls fehlenden Rich Snippet-Einträgen konnte es nicht liegen.

Ich hatte dann die Faxen dicke, keine Lust mehr den Bug in irgendwelchen Codes zu ergründen und bin zufällig auf das Plugin itemprop WP for SERP/SEO Rich snippets gestoßen. Mit ihm werden nun wieder Beitragstitel und Anreißertext beim Teilen ausgegeben.

Performance-Einbußen durch Jetpack

Das Herumschrauben in den Tiefen der Blogeinstellungen, um die Performance zu steigern und Sichtbarkeit bei Google zu erhöhen, hatte allerdings auch negative Folgen.

Mir fiel in Pingdom Tools auf, dass der Wert bei „Remove query strings from static resources“ signifikant in den Keller gefallen war. Ich hatte also die Performance des Blog „verschlimmbessert“.

Wie kam denn nun das wieder zustande? Ich ging im Kopf sämtliche Eingriffe noch einmal durch und konnte glücklicherweise recht schnell den Verursacher ausmachen.

Schuld daran war die Bildoptimierung für die Mediathek in Jeptack  – zu finden unter Writing. Diese hatte ich aktiviert. Ich vermute, dass sich durch anderweitige Optimierungseinstellungen – unter anderem auch für den Bildupload – diese Funktionen in die Quere gekommen sind. Aber viel hilft eben nicht immer viel. Das Deaktivieren der Bildoptimierung honorierte Pingdom Tools mit einem wesentlich besseren Wert.

Prompt befand sich „Remove query strings from static resources“ wieder im grünen Bereich.  Sollte also mal bei Euch dieser Wert nicht zufriedenstellend sein, schaut einfach mal bei dieser Jetpack-Funktion nach.

Die Anzeige alter Shares nach SSL-Umstellung – geht das?

Tja ich bin mir da momentan noch nicht ganz sicher. Auf jeden Fall fand ich diesen Beitrag im DF-Forum sehr spannend. Darin wird gefragt, ob es möglich ist, Shares vor Umstellung von http auf https zurück zu bekommen. Eigentlich werden darin nur die Facebook- und GooglePlus-Shares abgehandelt und ich habe die darin empfohlenen Scripte in .htaccess und header.php umgesetzt. Ich bin sogar noch einen Schritt weiter gegangen und habe ihn ein bisschen erweitert, obwohl ich nicht weiß, ob die von mir eingefügte Code-Zeile für Twitter überhaupt richtig ist.

Daher habe ich den Code mit der Twitter-Zeile hier bewusst nicht veröffentlicht, bevor jemand die Hände über den Kopf zusammenschlägt. ;-)

Aber probieren könnt ihr es mit diesem Code für Facebook- und Google+-Shares in der .htaccess:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_USER_AGENT} !(Facebot|facebookexternalhit/1\.1) [NC]
RewriteCond %{HTTP_USER_AGENT} !\+https://developers\.google\.com/\+/web/snippet/ [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\.
RewriteCond %{HTTP_USER_AGENT} !(Facebot|facebookexternalhit/1\.1) [NC]
RewriteCond %{HTTP_USER_AGENT} !\+https://developers\.google\.com/\+/web/snippet/ [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
...

Ggf. diese Codezeile in der header.php:

<meta property="og:url" content="http://www.deine-domain.de<?php echo $_SERVER['REQUEST_URI']; ?>" />

Natürlich müsst ihr darin Eure Domain eintragen.

Ich glaube schon, dass es bei mir die alten Facebook-und auch Twitter-Shares zurückgeholt wurden – zumindest teilweise. Allerdings lief das automatisierte Teilen meiner Beiträge bei Facebook nicht immer rund. Daher kann ich nicht mit 100%iger Sicherheit sagen, ob die alten Shares zu den neuen hinzugezählt wurden. Meine Beiträge werden aber eh sehr selten auf den Social Media-Kanälen – und bei GooglePlus so gut wie gar nicht – geteilt. Und leider zählt GooglePlus die automatisiert geteilten und dort gelikten Beiträge nicht (mehr?) mit.

Allerdings habe ich bei einer groben Durchsicht festgestellt, dass unter einigen älteren Beiträgen, die vor der SSL-Umstellung veröffentlicht wurden, Twitter-Shares angezeigt werden. Ich bin nicht unbedingt so vermessen zu glauben, dass beispielsweise ein Blümchenfoto als Ostergruß aus 2014 noch in 2017 (da habe ich auf https umgestellt) getwittert oder gelikt wurde. ;-)

Geschadet hat es zumindest nicht. Aber vielleicht ist von Euch jemand ebenso mutig und probiert die Codes bei sich aus, der wesentlich höhere Teilen-Sequenzen bei sich verzeichnet und meine doch recht subjektive Einschätzung bei sich selber objektiver bewerten kann. Ein Feedback dazu wäre toll.

Tracking-Code für Google Analytics neu eingebunden

Mir fiel siedendheiß ein, dass ich bereits vor Monaten festgestellt habe, dass in Google Analytics keine Seitenzugriffe angezeigt werden – zumindest in der Echtzeitanzeige-, hatte es aber verdrängt. Ein Blick darauf zeigte mir, dass das aktuell immer noch der Fall war. SEO-Experten werden wohl die Augen verdrehen, aber ich befasse mich nur rudimentär mit den Webmaster-Tools und Google Analytics. Aber wer weiß, was sich in dieser Hinsicht zwischenzeitlich geändert hat. Ich bin über diesen ausführlichen Beitrag gestolpert, der das Thema behandelt und habe den Tracking-Code, so wie er unter der Überschrift “Einbindung des Analytics-Codes auf der Website” beschrieben genauso im Headerbereich neu eingebunden.

Dann habe ich meine Blogs in den Webmaster-Tools von Google und Bing noch einmal neu indexieren, die Sitemaps einlesen und robot.txt testen lassen und ich denke, nun ist erst einmal wieder alles im grünen Bereich.

So, das dürfte es auch erst einmal gewesen sein an Blog-Werkeleien, aber das war mal wieder nötig. :-)