Das Putzlowitsch Test- und SEO-Blog

Contentbär SEO-Wettbewerb mit Umlautproblem

Contentbääääääär

Umlaute waren und sind immer noch ein Problem in URLs. Seit längerer Zeit funktionieren sie zumindest im Pfadteil der URL dank Unicode (UTF-8) und URL-Encoding technisch recht gut. Moderne Browser haben damit kein Problem mehr.

Auch im Domainnamen dürfen seit einiger Zeit ÄäÖöÜüß verwendet werden. Damit das funktioniert, werden sie im sogenannten Punycode kodiert und für den Domainnamen noch mit dem Präfix „xn--“ versehen.

Contentbär Live-Ranking mit Umlautproblem

So sieht das dann z.B. im Contentbär-Liveranking aus, wenn man das für die Darstellung nicht zurück konvertiert.

Sowohl Beispiel 1 „xn--contentbr-vergleich-nwb.de“ als auch Beispiel 2 „/contentb%C3%A4r-21660193/“ sind nicht wirklich gut lesbar. Dabei ist die Umsetzung in lesbaren Text für die Anzeige je nach verwendeter Programmiersprache recht einfach. In PHP z.B. gibt es dafür die Funktionen

idn_to_utf8()
urldecode()

Auch bei meinem Contentbär Ranking-123 hatte ich mit dem Problem zu tun, obwohl es nicht der erste SEO-Contest mit Umlauten im Keyword ist. Bereits 2011 träumte so mancher SEO seine Kubaseoträume. Damals gab es meine Seite Ranking-123 in der Form aber noch nicht.

Wie auch immer, ich habe die entsprechenden Anpassungen am PHP-Code vorgenommen und nun werden die Umlaute ordentlich dargestellt.

6 contentbär-vergleich.de/
68 www.reddit.com/r/contentbaer/comments/np39ws/contentbär_halbzeit/
88 de.quora.com/wie-gewinnt-man-den-seo-contest-für-den-begriff-contentbär
118 pixabay.com/de/users/contentbär-21660193/
131 podcasts.apple.com/mx/podcast/contentbär-alle-infos-news-zum-seo-contest-2021/id1567047693?l=en
140 www.amazon.de/contentbär-bärenstarke-seo-contest-2021-wettbewerb-ebook/dp/b095frs3zg
149 contentbär-seogewinnspiel.de/produkt/contentbaer/

Das sind aktuell (Montag, 14.06.2021 11:00) alle URLs im Ranking, die den Contentbär mit ä enthalten. Sind gar nicht so viele, an die echten Umlaute traut sich kaum jemand ran. Immerhin gibt es aber mit contentbär-vergleich.de eine Umlautdomain im Ranking.

Contentbär Keyword-Domain mit oder ohne Umlaut?

Mal davon abgesehen, daß dem Vernehmen nach Keyword-Domains keinen Rankingvorteil mehr haben, werden sie gerade bei SEO-Wettbewerben immer noch gerne verwendet. Warum das so ist, keine Ahnung.

Bei einem Umlaut im Suchbegriff stellt sich nun die Frage, was als Keyworddomain betrachtet werden kann. Gut, Contentbär mit „ä“ ist ja exakt der Suchbegriff, also wäre z.B. contentbär.de in jedem Fall eine EMD (Exact-Matsch-Domain).

Aber was ist mit der durchaus gebräuchlichen Ersetzung ä => ae? Streng genommen ist das keine Keyword-Domain, weil der Suchbegriff ja nicht genau so im Domainnamen vorkommt. Allerdings sind diese Umlautumschreibungen sehr verbreitet und daher auch beliebt.

Aktuell findet man im Contentbär-Ranking folgende Keyword-Domains (EMD, PMD, EMS und PMS):

6 contentbär-vergleich.de/
34 contentbaer-in.jimdosite.com/
38 contentbaer.myportfolio.com/
48 contentbaer.wordpress.com/
56 contentbaer.puzl.com/
62 contentbaer-in.weebly.com/
67 www.contentbaer.com/
109 dercontentbaer.de/
125 contentbaer-contest.de/
142 contentbaer.rocks/
148 contentbaerseo.de/
149 contentbär-seogewinnspiel.de/produkt/contentbaer/
152 contentbaeren.de/nahrung
156 contentbaer-gewinner.de/
157 www.contentbaer-seocontest.com/
159 www.contentbaer-seo.com/

Da findet man nur eine echte Umlautdomain, den oben schon erwähnten Contentbär-Vergleich, alle anderen setzen auf die „ä -> ae“-Substitution, sei es nun Domain oder Subdomain. Vielleicht sollte ich mal wieder meine keintext-Subdomain an den Start bringen, mit echtem Umlaut natürlich.

Na mal sehen, was daraus wird…

(Cimtamtpör)

Weitere Artikel mit Bezug zu diesem:
8 Kommentare »

Contentbär-Rankings bei ranking-123.de als XML und JSON

Contentbär und Linkbulle

Wie schon letztes Mal gibt es auch beim aktuellen SEO-Wettbewerb Contentbär die Ranking-Daten von ranking-123.de im XML- und JSON-Format.

Die URLs lauten:

Der Aufbau ist recht einfach und weitestgehend selbsterklärend. Im Kopf gibt es drei Datenfelder:

  • nam – Name
  • wrd – Suchbegriff (z.B. Contentbär)
  • upd – Datum und Zeit des letzten Updates der Liste
  • cnt – Anzahl der Google-Suchergebnistreffer (nicht Listeneinträge!)

Es folgt in rnk eine Liste der Suchergebnisse mit folgenden Datenfeldern:

  • pos – Position in den Suchergebnissen
  • url – URL der Seite
  • typ – Typ des Suchergebnisses, mögliche Werte
    • txt – normales Suchergebnis
    • new – Google-News
    • img – Universal Search Bilder
    • vid – Video
    • rec – Rezept
  • img – URL des Bildes, wenn Typ img ist (optional)
  • aut – Name des Autors/Rezeptdaten, falls verfügbar (optional)
  • lpo – letzte Position, 1000 falls neu in der Liste

Bei der Position für Universal-Search Ergebnisse wird eine Unternummerierung vorgenommen. Das erste Ergebnis bekommt .01, das zweite .02, das dritte .03 usw. an die eigentliche Position angehängt. Befinden sich zum Beispiel vier Bilder an der Position 13, so erhalten sie die Positionen 13.01, 13.02, 13.03 und 13.04 in pos zugeordnet.

Die Daten werden stündlich zu vollen Stunde erhoben. Es dauert aber ein paar Minuten, bis sie dann tatsächlich vorliegen. Also sollten die Daten ein paar Minuten nach der vollen Stunde abgefragt werden. Den aktuellen Zeitpunkt der Daten sieht man ja in den Kopfdaten.

Das Top-10 Diagramm im PNG-Format liegt auch zu diesem Zeitpunkt vor. Es gibt ein 24-Stunden-Diagramm und ein 3-Wochen-Diagramm:

Ihr könnt die Daten und Bilder auf euren Webseiten nutzen und einbinden.

Viel Erfolg beim Contentbär-Contest! :-)

(Cimtamtpör)

Weitere Artikel mit Bezug zu diesem:
Keine Kommentare »

Frohe Ostern 2021

Frohe Ostern 2021

Frohe Ostern 2021

Auch wenn auf dem Balkon 20 cm Schnee liegen und die Temperatur -12 °C beträgt, Ostern ist nicht mehr weit. Der Ostersonntag ist dieses Jahr am 4. April, also in genau 53 Tagen. Ich hoffe mal, daß das Wetter bis dahin schöner, also wärmer, sonnniger und niederschlagsärmer wird.

Das Bild oben mit den Osterglocken, dem Osterhasen und dem Text „Frohe Ostern 2021“ ist übrigens ein transparentes PNG-Bild. Das ermöglicht es, den Hintergrund des Bildes per CSS farblich zu animieren, also einfache Farbwechsel darzustellen. Und wenn ich schon mal dabei bin, tauche ich den Seitenhintergrund in ein zartes Grün.

Diese Farbeffekte habe ich erstmals für den Valentinstag verwendet. Dort sind es narürlich eher ein zartes Rosa und weitere Rottöne, passend zu den roten Herzen.

Letztendlich geht es mit aber hier um das Bild selbst. Alles andere ist Spielerei. Ich will sehen, ob Google die Metadaten z.B. zum Uhrheber auch aus PNG-Bildern ausliest und in der Bildersuche anzeigt. Leider kann man im PNG-Format nicht alle notwendigen Informationen unterbringen. Der Kontrollbegriff für diese Aktion ist Istarbmgpuld. Na mal sehen… :-)

Keine Kommentare »

Google Bildersuche – Anzeige des Originalbildes verhindern

Der Inhalt

  1. Problem
  2. Lösung
  3. Umsetzung
  4. Technik
  5. Ergebnis

Das Problem

Google-Bildersuche mit Originalbild

In der „neuen“ Google-Bildersuche wird beim Klick auf ein Ergebnis das Bild direkt in der Bildersuche in voller Auflösung geladen und angezeigt. Das dürfte viele Nutzer davon abhalten, die Ursprungsseite zu besuchen.

Um den Benutzer zu motivieren, dennoch die Originalseite zu besuchen, könnte man dem Nutzer innerhalb der Google-Bildersuche eine Bild in schlechter Qualität (unscharf/verpixel) mit einem zusätzlichen Hinweistext anzuzeigen. Das findet aber Google nicht so toll, es wird möglicherweise als Bilder-Cloaking gewertet. Das könnte wiederum eine manuellen Maßnahmen zur Folge haben.

Die Lösung

Seit einiger Zeit bietet Google im oben verlinkten Hinweis zum Bilder-Cloaking eine „legale“ Lösung für das Problem an

Bild in den Suchergebnissen minimieren oder blockieren

  • Sie können verhindern, dass das Bild auf der Google-Suchergebnisseite in Originalgröße angezeigt wird, indem Sie das Inline-Linking deaktivieren.

So deaktivieren Sie das Inline-Linking:

  • Wenn Ihr Bild angefordert wird, prüfen Sie den HTTP-Verweis-URL-Header in der Anfrage.
  • Falls die Anfrage von einer Google-Domain stammt, antworten Sie entweder mit HTTP 200 oder mit HTTP 204, „keine Inhalte“.

Google crawlt Ihre Seite und sieht das Bild weiterhin. In den Suchergebnissen wird jedoch nur das Miniaturbild angezeigt, das während des Crawlings generiert wurde. Die Funktion kann jederzeit deaktiviert werden. Die Bilder einer Website müssen dazu nicht noch einmal verarbeitet werden. Diese Methode wird nicht als Bild-Cloaking betrachtet und hat auch keine manuellen Maßnahmen zur Folge.

Wobei hier mit „Inline-Linking“ das gemeint ist, was allgemein als „Hotlinking“ bekannt ist. Und so ähnlich wie die berühmte Hotlink-Sperre funktioniert auch die Google-Bilder-Sperre.

Die Umsetzung

Als technische Basis setze ich einen Apache-Server mit den aktiven Modulen mod_rewrite, mod_headers und mod_setenvif voraus. Wobei das Modul mod_setenvif nicht zwingend erforderlich ist, es macht die Sache aber übersichtlicher:

<IFModule mod_headers.c>
Header	always	set    Cache-Control "no-cache, no-store, must-revalidate"	env=NO_CACHE
</IfModule>

<IfModule mod_setenvif.c>
SetEnvIf Accept "text/html"	REQ_HTML=1
SetEnvIf Referer "^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/"	DOM_REFERER=$1
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond	%{ENV:REQ_HTML} !1
RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|gif|png)$	-	[NC,C]

RewriteCond	%{ENV:DOM_REFERER}	google\.(com|de|at|ch)$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	bing\.com$ [NC]
RewriteRule	.*	/status-204.sta

RewriteRule	^status-204.sta$ -	[R=204,E=NO_CACHE:1,L]
</IfModule>

Die Technik

Zur Unterscheidung von Bildaufruf (img src=…) und Link verwende ich den Wert von „Accept“ im HTTP-Request-Header. Nach meiner Beobachtung enthält dieses Header-Feld bei Bild-Aufrufen nicht den Typ „text/html“, beim Aufruf von Links, auch zu Bildern, aber schon. Wenn also „text/html“ im Accept-Header zu finden ist, dürfte es sich um den Link zum Bild und nicht um das Laden des Bildes in der Google-Ansicht handeln.

Die Umgebung

<IfModule mod_setenvif.c>
SetEnvIf Accept "text/html"	REQ_HTML=1
SetEnvIf Referer "^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/"	DOM_REFERER=$1
</IfModule>

Den Accept-Header werte ich in einer SetEnvIf Anweisung aus und setze eine entsprechende Variable, die ich später in den Rewrite-Regeln auswerten kann. Zudem extrahiere ich in dem Block den Domain-Namen aus dem Referer, da ich diesen auch in anderen Rewrite-Regeln benötige.

Das Bild

RewriteCond	%{ENV:REQ_HTML} !1
RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|png|gif|webp)$	-	[NC,C]

Mit den Rewrite-Regeln prüfe ich zunächst, ob es ein Bildaufruf (img src=…) ist, die Existenz der Datei (sonst soll die normale 404-Verarbeitung greifen) und über die Datei-Erweiterung, ob ein Bild aufgerufen wird. Falls nicht, wir der nächste Block der Rewrite-Regeln gar nicht erst ausgeführt.

Die Referrer

RewriteCond	%{ENV:DOM_REFERER}	google\.(com|de|at|ch)$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	bing\.com$ [NC]
RewriteRule	.*	/status-204.sta

Im zweiten Block wird eine Liste von Referrer-Domains abgearbeitet, für die die Weiterleitung erfolgen soll. In dem Fall sind es die vier Google-Domains, von denen die meisten meiner Besucher kommen und bing.com (ja, das funktioniert auch für Bing :-). Die Abfrage nach dem Referer kann man natürlich auch anders gestalten. Das hängt halt davon ab, was man damit erreichen will.

Die anschließende RewriteRule erzeugt eine internes Rewrite zur einer leeren Dummy-Datei (status-204.sta), die aber existieren muß. Das ist erforderlich, um den Cache-Header korrekt setzen zu können. Wenn der Browser die Daten cachen würde, wäre das Bild möglicherweise auch nicht auf der Webseite zu sehen.

Die Regel

RewriteRule	^status-204.sta$ -	[R=204,E=NO_CACHE:1,L]

Diese einzelne Regel setzt letzendlich den HTTP-Statuscode „204 No Content“ und triggert die Ausgabe des NoCache-Headers.

Der Cache

<IFModule mod_headers.c>
Header	always	set    Cache-Control "no-cache, no-store, must-revalidate"	env=NO_CACHE
</IfModule>

Außerdem setze ich einen Wert (NO_CACHE), mit dem am Ende geprüft wird, ob das Caching deaktiviert werden soll. Der Block mod_headers steht zwar am Anfang, der Webserver führt diese Anweisungen aber erst ganz zum Schluß aus, kurz bevor die Antwort an den Client gesendet wir. Damit wird das Caching des von Google direkt geladenen Bildes verhindert.

Das Ergebnis

Im Ergebnis lädt Google unser Bild nicht in der ausgklappten Ansicht innerhalb der Bildersuche. Stattdessen wird das vergrößerte Thumbnail des Bildes angezeigt, das Google als Vorschaubild gespeichert hat und das in der Übersicht zu sehen ist.

Das Bild ist entsprechend unscharf und verpixelt. Der Nutzer kann unser Bild auch nicht einfach per Rechtsklick und „Grafik anzeigen“ oder „Grafik speichern unter…“ ansehen oder speichern- Wenn er das Originalbild sehen oder speichern will, muß er also unsere Webseite besuchen und schon haben wir wieder einen Besucher mehr. :-)

Keine Kommentare »

Strato-Webhosting: Update durch Downgrade/Upgrade 3.0

Sicher ist sicher, mit SSL

Mittlerweile gehört https bzw. SSL bei Websites zum Standard. Das war nicht immer so und vor einigen Jahren mußte man für ein SSL-Zertifikat noch richtig viel Geld bezahlen. Zudem war man beim Shared-Webhosting von den Angeboten des Webhosters abhängig, denn in der Regel kann man da nicht so einfach selbst Zertifikate installieren.

Vor etwa 6 Jahren gab es dann auch bei Strato die Möglichkeit, ein SSL-Zertifikat zu bestellen und so habe ich zum günstigen Einführungsangebot von € 2,99 pro Monat zugeschlagen und meine Schnurpsel-Seite damit ausgestattet. Später kostete es dann 4,90 im Monat.

Nun ist aber einige Zeit ins Land gegangen und mit Let’s Encrypt hat seit Ende 2015 jeder zum Null-Tarif die Möglichkeit, seine Website mit Verschlüsselung abzusichern. Der Webhoster All-Inkl z.B. bietet seit April 2016 die Möglichkeit, so ein Zertifikat mit wenigen Klicks im Kundenmenü selbst zu installieren.

Die großen Webhoster mußten sich dem Druck beugen und bieten in aktuellen Webhostingpaketen kostenlose SSL-Zertifikate an. Bei IONOS (1&1) bekommt man pro Hostingpaket ein Wildcard-Zertifikat, das auch alle Subdomains umfaßt. Bei Strato gibt es pro Domain ein Single-Domain-Zertifikat.

Strato – ein SSL-Zertifikat pro Domain

Also warum soll ich jetzt das Zertifikat extra bezahlen, obwohl es im Pakte enthalten ist? Weil ich noch ein altes Hostingpaket „PowerWeb Plus“ habe. Das hat zwar praktisch die selben Features zum selben Preis wie das aktuelle „Hosting Plus“, nur ist es eben alt.

Hier mal die Pakete im Vergelich:

Leistung PowerWeb Plus Hosting Pus Hosting Basic
Speicherplatz 150 GB 150 GB 100 GB
Domains 6 10 5
SSL-Zertifikate 0 10 5
Subdomains 1000 1000 500
MySQL Datenbanken 50 50 25
E-Mail-Postfächer 8000 8000 4000
E-Mail-Aliasse 40000 40000 20000
E-Mail-Speicher 80 GB 80 GB 40 GB
SFTP-Zugänge 50 50 10
App-Installation 50 50 25
Laufzeit 12 Monate 12 Monate 12 Monate
Preis/Monat € 10,00 € 10,00 € 8,00

Es sollte doch möglich sein, ein Update vom alten „PowerWeb Plus“ zum neuen „Hosting Plus“ zu machen. Die befinden sich ja schließlich innerhalb der gleichen Leistungs- und Preisklasse.

Update durch Downgrade und Upgrade

Wie schon beim letzten und vorletzten mal, kann man dieses Update, oder Sidegrade, wie es der nette Mitarbeiter von „Strato hilft“ auf FaceBook nannte, nicht mit ein paar Klicks im Kundenmenü bewerkstelligen.

Ich kann ein Upgrade auf ein höheres Paket beauftragen, das wäre in meinem Fall das „Hosting Pro“ für 20 Euro im Monat, was mir aber dann doch zu teuer wäre. Und es geht auch ein Downgrade (ohne FAX :-) in das „Hosting Basic“ für 8 Euro. Ja, das würde mir von den Leistungsdaten her auch reichen, aber es geht mir ums Prinzip.

Ein Telefongespräch mit dem Support und eine E-Mail per Kontaktformular führten nur zu einer abschlägigen Antwort:

„Ich habe soeben Ihren Anliegen überprüft und möchte Sie kurz informieren, dass eine Umstellung von dem PowerWeb Plus Paket auf das neue Hosting Plus Paket Systembedingt nicht möglich ist, da das System erkennt diese Pakete als dasselbe Paket somit wird kein Upgrade noch Downgrade ermöglicht.“

Und nun? Ich hatte dann plötzlich noch so eine Idee…

Ich könnte ja erst ein Downgrade auf „Hosting Basic“ machen und anschließend ein Upgrade auf „Hosting Plus“. Dann wäre ich wieder in meinem 10 Euro Paket und hätte zudem ein paar Inklusiv-Domains dazu und vor allem die inklusiven SSL-Zertifikate.

Es mußten vorher nur zwei Fragen geklärt werden. Was passiert mit der überzähligen Domain, denn ich habe aktuell 6 Inklusiv-Domains, im Basic-Paket sind aber nur 5 enthalten. Und kann ich überhaupt so schnell hintereinander das Paket wechseln.

Das mit der Domain ist recht einfach und eindeutig:

„Sei unbesorgt, was deine Domains angeht. Diese bleibt dir weiterhin erhalten. Sofern du mehr als die maximale Anzahl an Inklusiv-Domains im Paket gebucht hast, wird jede weitere Domain als Exklusiv-Domain extra berechnet.“

Nur wollte ich keine Zusatzdomain extra bezahlen. Also habe ich kurzerhand die eine unwichtige Domain gekündigt. Dadurch war der Weg frei zum kostenlosen Downgrade ins Strato-Webhosting-Paket „Hosting Basic“

Auch zum Zeitfaktor gab es eine schnelle Antwort:

„Ein Wechsel innerhalb der Hosting-Palette ist jederzeit zu sofort möglich. D.h. in deinem Fall heute Downgrade zum Hosting Basic und morgen dann zum Hosting Plus.“

Gestern habe ich die Domain gekündigt, heute nun das Downgrade durchgeführt.

Strato-Webhosting-Paket Basic

Und wenn ich es mir recht überlege, auch das Basic-Paket reicht mir eigentlich. Damit Spare ich 2 Euro im Monat, das sind immerhin 24 Euro im Jahr und wenn ich das auf 10 Jahre hochrechne…

Upgraden kann ich dann ja später immer noch. :-)

Nachtrag: Mittlerweile habe ich doch das Upgrade durchgeführt, weil ich eine weitere Inklusiv-Domain nutzen wollte. Und soooo viel sind die 2 Euro extra im Monat nun auch wieder nicht. :-)

5 Kommentare »