Die Robots.txt dient zur Steuerung der Webcrawler diverse Suchmaschinen, primär wird dort fest gelegt welche Seiten nicht gecrawlt werden sollen.

Magento hat viele Ordner und Dateien sowie Parameter/Filter, etc. welche nicht gescannt werden sollten, sei es aus Sicherheitsgründen als auch um das Duplicate Content Problen in den Griff zu bekommen:

## robots.txt for Magento Community and Enterprise

## GENERAL SETTINGS

## Enable robots.txt rules for all crawlers
User-agent: *

## Crawl-delay parameter: number of seconds to wait between successive requests to the same server.
## Set a custom crawl rate if you’re experiencing traffic problems with your server.
# Crawl-delay: 30

## Magento sitemap: uncomment and replace the URL to your Magento sitemap file
# Sitemap: http://www.example.com/sitemap/sitemap.xml

## DEVELOPMENT RELATED SETTINGS

## Do not crawl development files and folders: CVS, svn directories and dump files
Disallow: CVS
Disallow: .svn
Disallow: .idea
Disallow: .sql
Disallow: .tgz

## GENERAL MAGENTO SETTINGS

## Do not crawl Magento admin page
Disallow: /admin/

## Do not crawl common Magento technical folders
Disallow: /app/
Disallow: /downloader/
Disallow: /errors/
Disallow: /includes/
Disallow: /lib/
Disallow: /pkginfo/
Disallow: /shell/
Disallow: /var/

## Do not crawl common Magento files
Disallow: /api.php
Disallow: /cron.php
Disallow: /cron.sh
Disallow: /error_log
Disallow: /get.php
Disallow: /install.php
Disallow: /LICENSE.html
Disallow: /LICENSE.txt
Disallow: /LICENSE_AFL.txt
Disallow: /README.txt
Disallow: /RELEASE_NOTES.txt

## MAGENTO SEO IMPROVEMENTS

## Do not crawl sub category pages that are sorted or filtered.
Disallow: /*?dir*
Disallow: /*?dir=desc
Disallow: /*?dir=asc
Disallow: /*?limit=all
Disallow: /*?mode*

## Do not crawl 2-nd home page copy (example.com/index.php/). Uncomment it only if you activated Magento SEO URLs.
## Disallow: /index.php/

## Do not crawl links with session IDs
Disallow: /*?SID=

## Do not crawl checkout and user account pages
Disallow: /checkout/
Disallow: /onestepcheckout/
Disallow: /customer/
Disallow: /customer/account/
Disallow: /customer/account/login/

## Do not crawl seach pages and not-SEO optimized catalog links
Disallow: /catalogsearch/
Disallow: /catalog/product_compare/
Disallow: /catalog/category/view/
Disallow: /catalog/product/view/

## SERVER SETTINGS

## Do not crawl common server technical folders and files
Disallow: /cgi-bin/
Disallow: /cleanup.php
Disallow: /apc.php
Disallow: /memcache.php
Disallow: /phpinfo.php

## IMAGE CRAWLERS SETTINGS

## Extra: Uncomment if you do not wish Google and Bing to index your images
# User-agent: Googlebot-Image
# Disallow: /
# User-agent: msnbot-media
# Disallow: /

Verschiedene versionen der robots.txt pro domain/store per htaccess ausliefern – so geht’s

Mit hilfer der folgenden Einträge in der .htaccess-Datei könnt ihr anhand der Domain/Subdomain verschiedene robots.txt ausliefern:

 RewriteEngine on

RewriteCond %{HTTP_HOST} ^.*?domain2\.tld$ [NC]
RewriteRule ^robots\.txt$ robots.version1.txt

RewriteCond %{HTTP_HOST} ^.*?domain1\.tld$ [NC]
RewriteRule ^robots\.txt$ robots.version2.txt

Die folgende Funktion erzeugt euch für die einzelnen Stores bei Mehrsprachigkeit dieser ein Array mit den Markup-Links für Multilingual content:

public function countryStoresAlternateLinks()
{
/*      e.g.
<link rel="alternate" hreflang="es" href="http://www.example.com/" />
<link rel="alternate" hreflang="es-ES" href="http://es-es.example.com/" />
<link rel="alternate" hreflang="es-MX" href="http://es-mx.example.com/" />
<link rel="alternate" hreflang="en" href="http://en.example.com/" />
*/
$stores = Mage::app()->getStores(false);
if (!$stores) {
return false;
}
$countryAlternateLinks = '';
foreach($stores as $store) {
$countryAlternateLinks[] = '<link rel="alternate" hreflang="' . substr(Mage::getStoreConfig('general/locale/code', $store->getId()), 0, 2) . (Mage::getStoreConfig('general/country/default', $store->getId()) != '' ?  "-" . Mage::getStoreConfig('general/country/default', $store->getId()) : '') .  '" href="' . $store->getBaseUrl() . '" />' . "\n";
}
return $countryAlternateLinks;
}

Die erzeugte Liste könnt ihr dann entsprechend im Template verarbeiten/ausgeben.

Idealerweise solltet ihr die Funktion in eine erweiterte Klasse der Mage_Page_Block_Html_Head packen.

Magento leitet interne Links per 302-Status-Code weiter. Das ist in Bezug auf Suchmaschinenoptimierung nicht gerade optimal, besser wäre eine 301-Weiterleitung.

Um das zu ändern sollte beim Aufruf der Funktion „_redirect“ jeweils als zweiten Parameter der korrekte Status-code „301“ mit gegeben werden, da ansonsten der Default-Parameter „302“ verwendet wird.

Siehe: /app/code/core/Mage/Core/Controller/Response/Http.php :

/**
* Additionally check for session messages in several domains case
*
* @param string $url
* @param int $code
* @return Mage_Core_Controller_Response_Http
*/
public function setRedirect($url, $code = 302)
{
/**
* Use single transport object instance
*/
if (self::$_transportObject === null) {
self::$_transportObject = new Varien_Object;
}
self::$_transportObject->setUrl($url);
self::$_transportObject->setCode($code);
Mage::dispatchEvent('controller_response_redirect',
array('response' => $this, 'transport' => self::$_transportObject));
return parent::setRedirect(self::$_transportObject->getUrl(), self::$_transportObject->getCode());
}

Um das über ein Magento-Event zu lösen, geht wie folgt vor:

Erstellt ein neues Module und erweitert die config.xml mit folgendem xml-snippet, z.B. in der /app/code/local/Neuesmodul/Cms/etc/config.xml

<global>
<events>
<cms_controller_router_match_before>
<observers>
<Neuesmodul_Cms_observer_cmsControllerRouterMatchBefore>
<type>singleton</type>
<class>neuesmodul_cms/observer</class>
<method>
cmsControllerRouterMatchBefore
</method>
</Neuesmodul_Cms_observer_cmsControllerRouterMatchBefore>
</observers>
</cms_controller_router_match_before>
</events>
</global>

in /app/code/local/Neuesmodul/Cms/Model/Observer.php fügt ihr die folgende Funktion  ein:

/*
* set 301-Http-Response-Code for redirection
*/
public function cmsControllerRouterMatchBefore(Varien_Event_Observer $observer)
{
$condition = $observer->getEvent()->getCondition();
if ($condition->getRedirectUrl()) {
Mage::app()->getFrontController()->getResponse()
->setRedirect($condition->getRedirectUrl(), 301)
->sendResponse()
->setDispatched(true);
}
}

Alternativ-Funktion

/*
 * set 301-Http-Response-Code for redirection
 */
 public function cmsControllerRouterMatchBefore(Varien_Event_Observer $observer)
 {
 $condition = $observer->getEvent()->getCondition();
if ($condition->getIdentifier()) {
 Mage::app()->getFrontController()->getResponse()
 ->setRedirect('/', 301)
 ->sendResponse()
 ->setDispatched(true);
die();
 }
 }

Magento bietet eine Reihe an Möglichkeiten den Webshop für Suchmaschinen zu optimieren (kurZ: SEO). Die folgende Checkliste sollte vor der Go-Live Schaltung abgearbeitet werden:

SEO features	Description
General
1. Store name	Don’t forget to enter your store name. Store name is used in different parts of Magento System -> Configuration -> General -> Store information -> Store name
2. Home page title and meta data	Don’t forget to enter “Page title” and “Meta data” for your CMS pages, including Home page CMS -> Pages -> Home
3. Logo image Alt description	Alt description of the store image logo System -> Configuration -> Design -> Header -> Logo Image Alt
4. SEO Friendly URLs (SEF URLs)	SEO Friendly URLs is one of the most important features of every eCommerce store, don’t forget to enable and test it System -> Configuration -> Web -> Search Engines Optimization -> Use Web Server Rewrites -> “Yes”
Base URL
5. Unsecure and secure base URLs	Enter HTTP and HTTPS path to your store, e.g. http://www.example.com/store/ or https://www.example.com/store/ System -> Configuration -> Web -> Unsecure -> Base URL System -> Configuration -> Web -> Secure -> Base URL
6. Auto-redirect to Base URL	Use only one WWW or non-WWW URL for your store. I.e. redirect from http://example.com/store/ to http://www.example.com/store/ System -> Configuration -> Web -> URL options -> Auto-redirect to Base URL -> “301 redirect (Moved permanently)”
Products and categories
7. Products meta data and URL key	Your products should have SEO friendly URL keys and correct meta data values Catalog -> Manage Products -> [Product] -> General -> URL Key Catalog -> Manage Products -> [Product] -> Meta data
8. Categories meta data and page title	Enter URL Key, page title, Meta information for each category Catalog -> Manage Categories -> [Category]
9. Canonical link for categories and products	Enter URL Key, page title, Meta information for each category System -> Catalog -> Catalog -> Search Engine Optimizations -> Use Canonical Link Meta Tag For Categories System -> Catalog -> Catalog -> Search Engine Optimizations -> Use Canonical Link Meta Tag For Products
10. Structure of product URLs	Preferred structure of product URLs System -> Catalog -> Search Engine Optimizations -> Use Categories Path for Product URLs -> “Yes”
Sitemap
11. Google sitemap	Google sitemap configuration System -> Google Sitemap
12. Magento sitemap	Magento sitemap configuration settings System -> Catalog -> Sitemap -> Use Tree Like Category Sitemap -> “Yes” System -> Catalog -> Sitemap -> Search Engine Optimizations -> Autogenerated Site Map -> Enable
Advanced
13. Remove SID from Magento URLs	Be careful, this feature allows customers to stay logged in when switching between different multi-stores System -> Configuration -> Web -> Session Validation Settings -> Use SID on Frontend -> No
14. Permanent redirect rules	Permanent redirect rules for renamed products or categories System -> Catalog -> Search Engine Optimizations -> Create Permanent Redirect for URLs if URL Key Changed -> “Yes”
Default values
15. Default SEO values	Default values for title, Meta tags and robots directives System -> Configuration -> Design -> HTML head -> Default Title System -> Configuration -> Design -> HTML head -> Default Description System -> Configuration -> Design -> HTML head -> Default Keywords System -> Configuration -> Design -> HTML head -> Default Robots -> “INDEX, FOLLOW”
16. Default title separator	Default page title separator on storefront System -> Catalog -> Search Engine Optimizations -> Page Title Separator -> “-”
17. Default product URL suffix	Default product URL suffix for all pages System -> Catalog -> Search Engine Optimizations -> Product URL Suffix -> “.html” System -> Catalog -> Search Engine Optimizations -> Category URL Suffix -> “.html”

SEO Tool Sammlung

Diverse SEO Tools – linkvendor.com

Social Media Image Maker

Ein nützliches tool um für diverse Social-Media Bilder anzupassen.

www.autreplanete.com/ap-social-media-image-maker

Tool zum testen der Keyworddichte

www.werbeheini.de/seo-keyword-dichte.php

w3c validator

Der w3c validator zum überprüfen einer Webseite auf validen HTML-Code nach W3C-Standard.validator.w3.org

w3c link checker

validator.w3.org/checklink

 

Free Monitor for Google

Ein kostenlose Tool um für Ihre Webseiten die aktuelle Platzierung in der Suchmaschine Google anhand definierter Keywords heraus zu finden.Download Free Monitor for Google

301 redirect checker

Überprüft ob eine Seite per 301 weiter geleitet wird.

www.redirectchecker.com

www.ragepank.com/redirect-check

 Screaming Frog SEO Spider Tool

Der Screaming Frog ist ein SEO Spider, folglich macht er im Prinzip genau das, was sämtliche Suchmaschinen-Bots machen: Er crawlt die Links einer Domain und sammelt dabei SEO-relevante Daten.

Diese Daten lassen sich dann sortieren, filtern und Excel-freundlich exportieren. Als Desktopanwendung ist der Screaming Frog sowohl für Windows- als auch für Mac-User verfügbar. In der kostenlosen Version ist der Crawl-Umfang auf maximal 500 URLs begrenzt und auch die Einstellungsmöglichkeiten sind beschränkt. Nichtsdestotrotz sollte die kostenlose Variante für die Analyse kleinerer Projekte vollkommen ausreichend sein. Wem das doch nicht reicht, der kann für 99 Britische Pfund eine Jahreslizenz für die Vollversion erstehen.

www.screamingfrog.co.uk/seo-spider/

Immer wieder stolpert man über die Begriffe „Web 2.0“ und „Web 3.0“. Aber was steckt dahinter? Sind es nur neue Buzz-Wörter der Social-Media-Jugend?

Das Web 2.0

Mit Web 2.0 ist das heutige für die Benutzer weitestgehend interaktive Internet gemeint. Die Mehrzahl der Inhalte werden von den Anwendern generiert, nicht mehr primär statisch von den Webseitenbetreibern vorgegeben wie im „Web 1.0“. Als gute Beispiele sind Wikipedia, Youtube oder Facebook zu nennen. Ohne die von den Anwendern bei gesteuerten Inhalte wären diese Seiten nahezu nutzlos. Aber genau das Gegenteil ist der Fall, die Seiten erleben nahezu ein mega Boom, die Besucherzahlen sind enorm, die Akzeptanz sehr positiv und der Bekanntheitsgrad sehr hoch, weniger aktive Internet-Anwender kennen und nutzen diese Plattformen.

Web 3.0

Aber was ist jetzt das Web 3.0?

Das Web 3.0 ist ein semantisches Web. Die Daten auf der Webseite werden so gekennzeichnet, dass sie von Maschinen (zb Suchmaschinen wie Google.de) detailliert erkannt, kategorisiert und anschließend verarbeitet bzw angezeigt werden können. Aktuell können Maschinen die Daten zwar in der Summe einlesen, allerdings nicht immer detailliert trennen. Wir Menschen unterscheiden die verschiedenen Daten (zb Preis, Name eines Produktes, Beschreibung des Produktes, Artikel-Nr., etc.) durch die Formatierungen, Labels, Überschriften oder anhand anderer Kennzeichen.

Für zb Suchmaschinen ist diese Unterscheidung nicht ohne weiteres Möglich. Aus diesem Grund werden diese Daten explizit eindeutig gekennzeichnet, so das auch Maschinen diese erkennen. Hier ein Beispiel für ein semantische Kennzeichnung:

<stadt>Hannover</stadt> liegt an der <fluss>Leine</fluss>.<author>Daniel Briegert</author> hat diesen Text geschrieben.

Hierdurch ergeben sich viele positive Optimierungsmöglichkeiten, gerade im Umfeld der Suchmaschinenoptimierung (kurz: SEO).
Google selbst liest diese Daten bereits aus und stellt sie gesondert da. Primär über Rich Snippets (seit 2009).

Semantisches Web für SEOs

Welche Auszeichnungen über Rich Snippets sind aktuell am wichtigsten und damit für SEO ein „must have“?
Allgemein kann man sagen: „je mehr, umso besser und sei es nur um für die Zukunft gerüstet zusein!“. Nachteil ist allerdings ggf ein erhöhter Wartungsaufwand, ändern sich die Auszeichnungsstandards leider immer noch in unregelmäßigen Abständen bzw werde ergänzt oder ersetzt.

Aktuell kann die Auszeichnung von Bewertungen, Autoren und die Anzahl der Kommentare die Klickrate in den SERPS deutlich erhöhen, und das bei Gleichzeitig sinkender Absprungrate. Deshalb empfehle ich diese zu implementieren.

Semantische Auszeichnungen in Webshops

Neben der genannten Bewertungsauszeichnungen ist es sinnvoll bei Webshops gerade auf den Produktseiten die jeweiligen Produkteigenschaften auszuzeichnen.

Diese können sein:
Preis
Artikelnummer
rabattierter Preis
Hersteller
Größe
Farbe
Währung
Etc.

Allg. wichtig ist die Auszeichnung der jeweilig relevanten Eigenschaften folgender Seiten bzw Daten:

Events und Veranstaltungen
Produkte und Angebote
Bewertungen
Geschäfte, Restaurants und Organisationen
Filme, Bücher und Rezepte

Zur Auszeichnung empfiehlt sich das Microdata-Markup gemäß schema.org zu verwendet. Zur Validierung, ob das Markup korrekt implementiert wurde, empfehle ich das kostenlose Google Rich Snippet Testing Tool.

Ergänzende Artikel:

• Rich snippets: data-vocabulary.org vs schema.org

• SEO: Microformats vs RDF vs Mikrodata – Microformats oder RDF oder Mikrodata verwenden?

• 7 wertvolle SEO OnSite Tipps

Wenn dir der Artikel gefallen hat bzw ein Mehrwert für dich war, wäre ich dankbar wenn du diesen Artikel in den Sozialen-Medien teilen und „liken“ könntest, danke!

Auf der Suche nach geeigneten Domains für eine neue Webseite wird oft die Frage gestellt „Mehrere Länderdomains oder eine .com?“. Als Beispiel fällt mir ein Web-Shops ein, welcher in verschiedenen Ländern präsent sein soll.

Klares Pro-Argument ist ein psychologischer Faktor, und zwar werden bei der breiten Masse der Internetbenutzer (primär ältere Nutzer) Webseiten mit der Länderdomain des jeweiligen Landes, als vertrauenswürdiger angesehen und damit auch mehr genutzt. Google selbst kann die Seiten ebenfalls besser zuordnen, vor allem bei der lokalen-Suche kann dieser Faktor ein Mehrwert sein. Auch kann es durchaus sein dass Anwender die jeweilige Domain intuitiv eingeben oder teile der Domain bei google.de, so dass diese als Vorschlag erscheint.

Aber was ist jetzt SEO-technisch die beste Lösung?

Da großer internationaler Konzern, lieber eine „große“ .com oder .eu Domain mit vielen Unterseiten und den jeweiligen Sprachversionen als Unterkategorien oder doch lieber mehrere Domains mit Länderendungen (.de, .co.uk, .fr, etc.)?

Und was ist jetzt bei gleichsprachigen Ländern wie z.B. Österreich (.at) und gleichzeitig Deutschland (.de)?
Wie wird da verhindert das Google beide  Seiten bzgl. duplicate content abstraft?

Viele Fragen, auf die ich in diesem Artikel eingehen möchte.

Bei der Lösung mit jeweils eigenständigen Länder-Domains, erfolgt eine Aufsplittung der eingehenden Linkpower, wobei bei der 1-Domain-Lösung (z.B. über .com oder .eu mit jeweils Unterseiten pro Land) die Domain den gesamten Link-Juice abbekommt.

Ist das überhaupt ein Problem? Ist mit diesem Faktor schon die Entscheidung gefallen?

Nicht ganz und vor allem ist es weit wichtiger, auch über die regionalen Suche gefunden zu werden.

Mit der .com wird die Seite zwar auch gefunden, wenn jemand „Seiten aus Deutschland“ bei Google anklickt (oder je nach dem aus welchem Land die IP kommt), jedoch nicht Seiten aus Östereich / Seiten aus der Schweiz etc.!

Mit .de, .ch, .at etc. wird automatisch auch die Seite mit der Regionalen Suche gefunden. Was wiederum einfacher zu optimieren ist.

Und wie lösen wir das Duplicate Content Problem bei Seiten mit der selben Sprache aber unterschiedlicher Domain?

Jetzt steht weiterhin dass Problem, der doppelten Inhalte auf zwei verschiedenen Webseiten/Domains mit der selben Sprache, im Raum (z.B. .de und .at). Wie lösen? Durch 301 oder canonical-link würden nicht beide Varianten auch in den SERPs gelistet, was allerdings gewollt ist.

Internationale und mehrsprachige Websites

Schauen wir doch mal bei Google in der FAQ dort wird unser Beispiel genannt.
Gerade im spanischen Raum (Latainamerika, Spanien, etc.) kommt es zu ähnlichen Problen.
Hier geht Google im Detail auf das Problem „Duplizierter Content und internationale Websites“ ein.

Interessant ist meiner Meinung nach die Kombination beider Varianten, daher schon auf die jeweiligen Länderdomains setzen, allerdings auch ein offizielles Länder-Kürzel mit in die URL aufzunehmen, z.B. bei der kanadischen Domain:

http://example.ca/fr/vélo-de-montagne.html http://fr.example.ca/vélo-de-montagne.html

Google sagt dazu

Ein Hinweis auf die Sprache in der URL kann auch dabei helfen, Probleme mit mehrsprachigem Content auf Ihrer Website zu ermitteln.

„Ein Hinweis auf die Sprache in der URL kann auch dabei helfen, Probleme mit mehrsprachigem Content auf Ihrer Website zu ermitteln.

Zusätzlich geht Google auf das Thema „Duplizierter Content und internationale Websites“ ein, allerdings wird genau das Problem nicht erklärt, sondern darauf verwiesen per canonical oder redirect auf die als „bevorzugte Version“ fest gelegte Seite zu leiten. Aber genau das wollen wir ja nicht, die Seiten sollen sowohl mit der .de-domain in den deutschen SERPs als auch mit der .AT-Domain in den Österreichischen SERPs gelistet werden, auch mit dem selben Content.

Ich denke dieser Weg ist Bestandteil der Lösung (neben einbinden der Sprache in der URI):

Einstellungen für die geografische Ausrichtung (Geotargeting). Mithilfe des Geotargeting-Tools in den Webmaster-Tools können Sie für Google angeben, dass Ihre Website auf ein bestimmtes Land ausgerichtet ist. Dies sollten Sie jedoch nur tun, falls Ihre Website eine gTLD (Generic Top-Level Domain) aufweist. Falls sich Ihre Website an mehrere Länder richtet, sollten Sie dieses Tool nicht verwenden. Es wäre beispielsweise sinnvoll, für eine Website über Restaurants in Montreal „Kanada“ als Ziel einzustellen. Hingegen ist dieses Ziel für eine Website, die sich an französischsprachige Nutzer in Frankreich, Kanada und Mali richtet, nicht geeignet.

Zuständlich sollte das Markup Linkelements „rel=“alternate“ hreflang  zur Auszeichnung verwendet werden:

<link rel="alternate" hreflang="es" href="http://www.example.com/" />
<link rel="alternate" hreflang="es-ES" href="http://es-es.example.com/" />
<link rel="alternate" hreflang="es-MX" href="http://es-mx.example.com/" />
<link rel="alternate" hreflang="en" href="http://en.example.com/" />

Anwendungsbeispiel für Österreich, Schweiz & Deutschland

URL: www.website.de/beispielseite/
<link rel=“alternate“ hreflang=“de-AT“ href=“http://www.website.at/beispielseite/“ />
<link rel=“alternate“ hreflang=“de-CH“ href=“http://www.website.ch/beispielseite/“ />

URL: www.website.ch/beispielseite/
<link rel=“alternate“ hreflang=“de-AT“ href=“http://www.website.at/beispielseite/“ />
<link rel=“alternate“ hreflang=“de-DE“ href=“http://www.website.de/beispielseite/“ />

URL: www.website.at/beispielseite/
<link rel=“alternate“ hreflang=“de-CH“ href=“http://www.website.ch/beispielseite/“ />
<link rel=“alternate“ hreflang=“de-DE“ href=“http://www.website.de/beispielseite/“ />

Über hreflang wird also neben der Sprache auch die Region hinterlegt, in der die jeweilige Seite ausgespielt werden soll.

Quelle: googlewebmastercentral-de.blogspot.de/2011/12/neues-markup-fur-mehrsprachige-inhalte.html

Was meint Ihr zu diesem Thema?
Ich würde mich freuen wenn ihr eure Meinung als Kommentar schreibt.

 

Anwendungsbeispiel

URL: www.website.de/beispielseite/
<link rel=“alternate“ hreflang=“de-AT“ href=“http://www.website.at/beispielseite/“ />
<link rel=“alternate“ hreflang=“de-CH“ href=“http://www.website.ch/beispielseite/“ />

URL: www.website.ch/beispielseite/
<link rel=“alternate“ hreflang=“de-AT“ href=“http://www.website.at/beispielseite/“ />
<link rel=“alternate“ hreflang=“de-DE“ href=“http://www.website.de/beispielseite/“ />

URL: www.website.at/beispielseite/
<link rel=“alternate“ hreflang=“de-CH“ href=“http://www.website.ch/beispielseite/“ />
<link rel=“alternate“ hreflang=“de-DE“ href=“http://www.website.de/beispielseite/“ />

Über hreflang wird also neben der Sprache auch die Region hinterlegt, in der die jeweilige Seite ausgespielt werden soll.

Die Seitengeschwindigkeit (engl. Pagespeed) bzw. genauer die Ladezeit einer Webseite, ist seit 2010 laut Google ein wichtiges Ranking-Kriterium. Daher ist es wichtig diese regelmäßig zu überwachen (Monitoring), bei schlechten Werten zu analysieren und schlussendlich zu optimieren.

An dieser Stelle möchte ich hierzu ein paar Optimierungs-Tipps geben.

Gerne könnt ihr in den Kommentaren Ergänzungen oder Kritiken schreiben, wenn sinnvoll nehme ich diese gerne in den Artikel mit auf.

Test-Tools / Seitengeschwindigkeit analysieren

Google stellt dafür ein kostenloses Tool zum Performance evaluieren der Webseite zur Verfügung, zu erreichen über den folgenden Link.

https://developers.google.com/pagespeed

Das Tool gibt es auch als kostenloses Browser Plugin:

https://developers.google.com/speed/pagespeed/download

Ladezeit mit Google-Analytics messen

Ich empfehle ebenfalls die Ladezeiten auch mit Google-Analytics regelmäßig zu monitoren.
Detailierte Informationen hierzu unter Google-Analytics.

Ziel: regelmäßiges automatisches Monitoring der Ladezeit

Grafiken komprimieren

Die Ladezeit von Grafiken lässt sich durch automatische Komprimierung wesentlich verkürzen,
Qualitätsunterschiede sind für das menschliche Auge fast nicht erkennen. Ein guter Komprimierungs-Dienst ist z.B.:

Tipp:    JPEGmini.com

Ziel: Grafiken verkleinern ohne merklichen Qualitätsverlust – weniger Datenvolumen zwischen Client & Server

Gzip Komprimierung aktiveren

Die automatische Gzip komprimierung lässt sich über die .htaccess ggf. über den Webserver (Provider) konfigurieren und sollte entsprechend aktiviert sein.

Ziel: Datenvolumen zwischen Client & Server verringern

CSS + Javascript Dateien zusammenfassen

Oft werden mehrere CSS und/oder JS-Dateien verwendet. Durch das zusammenfassen dieser Dateien, vermindern sich die HTTP-Requests (aus verschiedenen wird nur noch einer), dadurch erhöht sich ebenfalls die Ladezeit der Webseite.

Ziel: Weniger HTTP-Requests

Cache aktivieren

Wenn möglich ein Cache-Module des Webservers einbinden und aktivieren (z.B. APC oder MemCache).

Ziel: Webseiten werden im Cache vorgehalten, dadurch verringert sich die Last & Ladezeit des Webservers

Im Nachgang zum gestrigen Artikel SEO: Microformats vs RDF vs Mikrodata – Microformats oder RDF oder Mikrodata verwenden? möchte ich heute auf die sich zwangsweise ergebende Frage Auszeichnung nach „data-vocabulary.org oder  schema.org?“ eingehen.

Die Antwort ist einfach, wenn bekannt ist wofür RDF steht bzw. das RDF-Schema (RDF Vocabulary Description Language).
Daher, data-vocabulary.org ist für RDF zu verwenden, schema.org eher für mikrodata.

Weitere führende Infos bei wikipedia

Manch einer nennt Microformats und RDFa die stille Revolution bzgl. semantic web.

Aber was ist am besten? RDFa oder microformats? Wer sich mit der Implementation des semantischen Webs beschäftigt, und z.B. die Umsetzungsempfehlungen aus den Google Webmaster Richtlinien liest, merkt schnell das es verschiedene Wege zur Umsetzung gibt. Aber was ist der besser Weg?

Die Antwort ist nicht so einfach.

Microformats

Gegründet wurde die ursprüngliche Bewegung unter dem Namen microformats.org und der zugehörigen Website im Juni 2005. Die Gründer waren Dan Cederholm und Tantex Çelik. Letzterer ist bei vielen Webentwicklern für seine teilweise hochkomplexen Internet-Explorer-Hacks bekannt, die mit den diversen Kommentarmöglichkeiten spielen. Tantek Çelik hat allerdings auch für Microsoft und Technorati gearbeitet.

Das Besondere an den Microformats von microformats.org ist, dass sie keine neuen Technologien und Standards benötigen. Sie verwenden vollständig die Funktionalität von XHTML. Während die Microformats also quasi jederzeit eingeführt werden konnten, schlug sich das eigentliche semantische Web mit komplexeren Problemen herum. Schon seit vielen Jahren gab es Bemühungen, Bedeutung in Tag-basierte Sprachen zu mischen.

Microformats (oder zu deutsch “Mikroformate”) verwenden bekannte HTML Attribute wie “class” und Hierarchien, um Auszeichnungen aus einer fest definierten Auswahl vor zu nehmen.

Vorteile

• Einfach
• Führt keine neuen HTML-Attribute ein, gültiges HTML4.

Nachteile

• Nur eine fest definierte Auswahl an Formaten, nicht erweiterbar.
• Keine definierte API zur Extraktion der Daten.
• Keine definierte Internationalisierungs-Unterstützung.
• Die Verwendung von “class” kann zu Konflikten mit CSS-Definitionen führen.

Microformats Beispiel

<p class="vcard">
<a class="fn email" href="mailto:mail@fly2mars-media.de">Vorname Name</a> arbeitet als
<span class="role">SEO-Berater</span> für
<span class="org">Fly2Mars-Media.de</a>.
</p>

RDF

RDFa erweitert den HTML-Standard um RDF-Daten in (X)HTML-Dokumente einzubetten.

Der vielleicht wichtigste Ansatz ist RDF, das Ressource Description Framework. Dabei handelt es sich nicht um einen Standard, sondern um eine ganze Standard- Familie. Verwaltet wird sie – wie HTML und XHTML – vom W3C. RDF bietet im Grunde eine Beschreibung von Objekten.

Ursprünglich hauptsächlich für Metadaten gedacht, wurde der Ansatz bald auf alle Arten von Daten ausgeweitet. Da RDF selbst allerdings recht umfangreich ist und nicht direkt mit Websites interagiert, hat das W3C den Microformats-Gedanken aufgegriffen und mit RDFa eine einfache RDF-Variante für die Integration in XHTML geschaffen.

Vorteile

• Maximale Flexibilität, umfangreich erweiterbar, um eigene Vokabularien zu definieren.
• Erlaubt Mashups verschiedener Vokabularien.
• Prefixe erlauben kompakteren Code da URLs nicht immer voll ausgeschrieben werden müssen.
• Erlaubt die beliebige Verkettung von Elementen.
• RDFa Dom API

Nachteile

• Hohe Komplexität.
• Auf XML und XHTML ausgerichtet, wenn auch mittlerweile in HTML5 einbettbar.
• Führt 8 neue HTML-Attribute ein.

RDF Beispiel

<p xmlns:v="http://rdf.data-vocabulary.org/#" typeof="v:Person">
<a href="mailto:mail@fly2mars-media.de" rel="v:url" property="v:name">Vorname Name</a> arbeitet als
<span property="v:role">SEO-Berater</span> für
<span property="v:affiliation">Fly2Mars-Media</span>.
</p>

Microdata

Microdata ist eine Erweiterung für HTML5, um semantische Annotationen einzubetten.

Vorteile

• Kompromiss zwischen Flexibilität+Erweiterbarkeit und moderater Komplexität.
• Näher am HTML5-Standard, z.B. mit Unterstützung des HTML5 time Elements.
• Nativer JSON-Export
• Microdata DOM API
• Bevorzugtes Format der Suchmaschinen-Riesen Google,  Microsoft und Yahoo! (siehe auch Schema.org).

Nachteile

• Erlaubt keine mehrfachen Eigenschaften für Elemente, wie z.B. Email und Name in einem einzigen Link-Element.
• Führt 5 neue HTML-Attribute ein.

Mikrodata Beispiel

<p itemscope itemtype="http://schema.org/Person">
<a itemprop="email" href="mailto:mail@fly2mars-media.de">
<span itemprop="name">Vorname Name</span>
</a> arbeitet als <span itemprop="jobTitle">SEO-Berater</span> für <span>fly2mars-media.de</a>.
</p>

Fazit

RDF wird gut von Google erkannt, bietet mehr Möglichkeiten als Microformats. Validiert werden können die Seiten mit dem Rich Snippets Testing Tool von Google. Google empfiehlt Mikrodata, wohl auch weil mehr HTML5.

Deshalb verwende ich jetzt RDF und Mikrodata.

Google unterstützt Rich Snippets in der Anzeige der Suchergebnisse (SERPs). Neben Microformats und RDFa wird auch Microdata unterstützt, letzteres ist dabei das bevorzugtes Format und von Google empfohlen. Auf  Schema.org befindet sich eine gute Dokumentation, diese sollte befolgt werden.

Eure Erfahrungen & Ergänzungen?

Her damit, aktuell spannendes Thema, neben Bewertungen, Autoren-Infos, Kontaktdaten, etc. lässt sich vieles damit so auszeichnen das die Daten richtig von den Suchmaschinen (oder anderen Maschinen lesbaren Geräten) richtig erkannt und verarbeitet werden können. Web 3.0 kann kommen! 🙂