Technik

Technik

SEOs am Server – Redirects & Co.

Die trockenen “strukturierten Daten” haben wir hinter uns gelassen. Jetzt widmen wir uns einem SEO-Thema, das sehr heiß werden kann. Wir sprechen über Server, Redirects, 404-Fehler und mehr. Keine Sorge: Dafür müssen Sie keinen Server zusammengebaut haben. Wir gehen nur auf die wichtigsten und häufigsten SEO-Techniken ein.

 

Zu Beginn sollte kurz thematisiert werden, warum SEOs überhaupt mit diesem Bereich zu tun haben. Ist das nicht eigentlich IT bzw. Informatik? Ja, ist es. Leider kommt es immer wieder vor, dass heute Web-Projekte ohne besondere IT Kompetenz aufgebaut werden.

 

Zum Problem wird das immer dann, wenn der Besitzer des Web-Projektes höher hinaus will. Das ist dann in etwa so, als würde ein Koch gerne in kürzester Zeit professioneller Schmied werden. Das Resultat ist dann, dass ein SEO gerne als Allrounder rekrutiert wird und für alles her hält. Sofern er das Know-How besitzt, versteht sich.

 

Sofern Ihr Kunde einen Verantwortlichen für die IT hat, sprechen Sie mit diesem ihre Vorschläge für die Optimierung ab. Lassen Sie diese Maßnahmen auch von ihm umsetzen. Sie ersparen sich somit das Risiko, an einem unbekannten System arbeiten zu müssen.

 

 

Backups erstellen

 

Gerade, weil unbekannte Systeme so heikel sein können, gilt als erste Priorität: Erstellen Sie ein Backup (Sicherung) aller Dateien und von allen verknüpften Datenbanken. Fassen Sie davor nichts an und stellen Sie nichts um. Stellen Sie ebenfalls sicher, dass Sie dieses Backup im Notfall schnell wieder einspielen können.

 

Warum ist das so wichtig? An einem Standard-System zu arbeiten, ist kein Problem. Es wird erst problematisch, wenn an der Plattform des Kunden allerlei Änderungen vorgenommen wurden. Das sind solche Änderungen, von denen Ihnen niemand etwas sagt. Ziehen Sie dann den falschen Stein aus dem System, kracht alles zusammen.

 

Warum kommt das immer wieder vor? Weil modernes Business viele Köche an einem Brei kochen lässt. Vor einem Jahr gab es vielleicht einen IT Fachmann. Dieser hat dann hier und dort ein paar Codes hinzugefügt oder entfernt. Ein halbes Jahr später kam ein Server-Admin, der kurzerhand ein paar praktische Anpassungen vorgenommen hat.

 

Je stärker die Fluktuation bei einem solchen Projekt ist, desto mehr Wert sollte auf der Dokumentation liegen. Das ist in den meisten Fällen aber keinesfalls Realität. Entsprechend sitzen Sie unter Umständen vor einem Online-Shop oder einer Website, an welcher vor Ihnen schon 5-10 Menschen gebastelt haben.

 

Toll ist das nicht, aber so ist es leider nicht selten. Deshalb immer: Backup machen! Andernfalls sind Sie derjenige, der zahlt (oder Ihre Berufshaftpflichtversicherung).

 

 

 

301-Redirects setzen

 

Wenn der Kunde Sie wirklich am System arbeiten lassen möchte, sollte er Folgendes zur Verfügung stellen:

 

    • FTP-Zugriff
    • MySQL-Datenbank-Zugriff
    • Zugriff auf das Backend des Web-Projektes

 

Redirects setzen Sie dann am besten über den FTP-Zugriff. Im Root-Verzeichnis (auch Wurzelverzeichnis) sollten Sie eine Datei mit der Bezeichnung .htaccess finden. Öffnen Sie diese mit einem Texteditor wie beispielsweise notepad++. Um einen 301-Redirect zu setzen müssen Sie eine allein stehende Zeile eintragen, die zum Beispiel so aussieht:

 

RewriteEngine On

Redirect 301 /de/tassen/gross/ https://mugytassy.de/jumbotassen/

 

Mit “Redirect 301” geben Sie den Befehl, einen 301-Redirect (permanently moved) zu erzeugen und eben keinen 302-Redirect (temporarily moved). Im SEO macht es so gut wie nie Sinn, einen 302-Redirect zu setzen. Wenn eine Seite über einen anderen URL zu finden ist, hat das eigentlich immer einen guten und langfristigen Grund.

 

Mit “/de/tassen/gross/” geben wir den ursprünglichen URL an, über welchen die Seite zu finden war. Dieser wird absichtlich ohne Domain angegeben. An dieser Stelle steht also immer der Pfad ohne Domain und ohne https://.

 

Mit “https://mugytassy.de/jumbotassen/” geben wir den neuen URL an, über welchen die Seite nun zu finden ist. Stellen Sie immer sicher, dass alles zu 100% korrekt ist. Ein falsches Leerzeichen oder ein falscher Buchstabe kann in diesem Fall alles zum Scheitern bringen.

 

Abschließend sollten Sie beim Thema Redirects bedenken, dass diese oben erwähnte Form für Apache Server gilt und am geläufigsten ist. Es kann genauso gut vorkommen, dass die oben erwähnte Form nicht funktioniert. In diesem Fall lässt sich zum Beispiel auch Mod_Rewrite verwenden, was in etwa so aussehen würde:

 

RewriteEngine On
RewriteCond %{REQUEST_URI} ^\/de\/tassen\/gross\/$
RewriteRule .* https://mugytassy.de/jumbotassen/ [R=301,L]

 

Google mag es übrigens lieber, wenn man den gerade erwähnten Rewrite verwendet, anstatt eines Redirects. Der Grund ist einfach erklärt: Bei einem Rewrite müssen die Crawler nicht erneut die Seite bzw. den URL scannen. Das spart Ressourcen.

 

Das war es auch schon! Geschafft! Jetzt müssen Sie die Datei nur speichern bzw. die alte Datei mit der neuen Datei-Version auf dem Server überschreiben. Wenn Sie alles richtig gemacht haben, sollte der Redirect sofort wie gewünscht funktionieren.

 

Wie bereits erwähnt, gelten solche Redirect Einträge für die am weitesten verbreiteten Apache Server. Neben Apache sind aber unter anderem auch Nginx- oder Microsoft-Server im Einsatz. Diese erfordern anderweitige Befehle.

 

Für jeden neuen Redirect müssen Sie übrigens eine neue Zeile nutzen. Bitte bedenken Sie, dass ich keine Garantie oder Haftung übernehme, falls Sie Beispiele dieser Lektionen für Kundenprojekte verwenden! Das geschieht immer auf eigene Gefahr!

 

 

 

404-Fehlerseiten einrichten

 

Stellen Sie sich vor, Sie betreiben einen Supermarkt und haben die Nudeln vom ersten Regal am Eingang auf unterschiedliche Regale verteilt. Damit Ihre Kunden nicht denken, dass Sie keine Nudeln mehr anbieten, bringen Sie ein Schild mit dem Hinweis “Wir haben die Nudeln in anderen Regalen platziert. Sprechen Sie uns gerne an!” an.

 

So in etwa funktioniert eine 404-Seite:

 

    • Sie sagt Usern, aber auch den Suchmaschinen, dass etwas nicht mehr hier ist
    • Sie entschuldigt sich liebenswert oder mit Humor für dieses Debakel
    • Sie bietet eine Kontaktmöglichkeit und/oder eine Suchfunktion an
    • Sie weist User darauf hin, was diese jetzt tun können/sollten
    • Das kann die Nutzung der Suchfunktion, des Live-Chats/Kontaktformulars oder das Zurückkehren zur Startseite sein

 

Wie richten wir diese nützliche Seite ein? Sobald die Seite mit gewünschten Texten, Bildern und Funktionen designed und veröffentlicht ist, kehren wir zur bereits erwähnten .htaccess Datei via FTP-Zugriff zurück.

 

Nehmen wir an, die 404-Seite ist folgendermaßen erreichbar: https://mugytassy.de/404-seite/

In der .htaccess Datei erstellen wir eine neue Zeile und geben ein:

ErrorDocument 404 /404-seite/

 

Nach dem Speichern und Hochladen der Datei, ist die 404-Seite eingerichtet. Nun fragen Sie sich vielleicht, warum man das in der .htaccess Datei eingibt? Man sieht doch, dass es eine 404-Seite ist oder nicht? Das stimmt, aber erstens muss der Server selbst auch eine 404-Meldung für die Suchmaschinen zurückgeben und zweitens muss im Falle eines 404-Fehlers auch die passende Seite definiert sein.

 

Neben den genannten Einstellungen sollte immer auch im Backend sichergestellt werden, ob dort in den Einstellungen eine 404-Seite definiert werden kann. Häufig ist das der Fall. Sofern zutreffend, geben Sie auch dort den Pfad zur 404-Seite an.

 

 

 

Weitere Einstellungen für die .htaccess Datei

 

Hier finden Sie einige Einträge, die Sie für ein Projekt verwenden können. Beschäftigen Sie sich aber bitte intensiver mit diesem Thema, bevor Sie mit derartigen Einträgen los legen. Sie müssen auch Anpassungen an den URLs vornehmen und prüfen, ob es zu Doppelungen kommt. Einfaches Copy & Paste funktioniert hier nicht.

 

Es handelt sich hierbei nur um Beispiele, die mit der Zeit veralten können:

 

.htaccess Einträge

.htaccess Einträge

# Ensure all URLs have a trailing slash.

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_URI} !(.*)/$

RewriteRule ^(.*)$ https://www.meinedomain.de/$1/ [L,R=301]

# END Ensure all URLs have a trailing slash.

 

# Enable gzip compression

<ifModule mod_gzip.c>

mod_gzip_on Yes

mod_gzip_dechunk Yes

mod_gzip_item_include file .(html?|txt|css|js|php|pl)$

mod_gzip_item_include handler ^cgi-script$

mod_gzip_item_include mime ^text/.*

mod_gzip_item_include mime ^application/x-javascript.*

mod_gzip_item_exclude mime ^image/.*

mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*

</ifModule>

#END gzip compression

 

# BEGIN Expire headers

<ifModule mod_expires.c>

ExpiresActive On

ExpiresDefault “access plus 5 seconds”

ExpiresByType image/x-icon “access plus 2592000 seconds”

ExpiresByType image/jpeg “access plus 2592000 seconds”

ExpiresByType image/png “access plus 2592000 seconds”

ExpiresByType image/gif “access plus 2592000 seconds”

ExpiresByType application/x-shockwave-flash “access plus 2592000 seconds”

ExpiresByType text/css “access plus 604800 seconds”

ExpiresByType text/javascript “access plus 216000 seconds”

ExpiresByType application/javascript “access plus 216000 seconds”

ExpiresByType application/x-javascript “access plus 216000 seconds”

ExpiresByType text/html “access plus 600 seconds”

ExpiresByType application/xhtml+xml “access plus 600 seconds”

</ifModule>

# END Expire headers

 

# BEGIN Cache-Control Headers

<ifModule mod_headers.c>

<filesMatch “\.(ico|jpe?g|png|gif|swf)$”>

Header set Cache-Control “public”

</filesMatch>

<filesMatch “\.(css)$”>

Header set Cache-Control “public”

</filesMatch>

<filesMatch “\.(js)$”>

Header set Cache-Control “private”

</filesMatch>

<filesMatch “\.(x?html?|php)$”>

Header set Cache-Control “private, must-revalidate”

</filesMatch>

</ifModule>

# END Cache-Control Headers

 

# Set up caching on static resources for 1 year based on Google recommendations
<IfModule mod_expires.c>
ExpiresActive On
<FilesMatch “\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav|js|css|gif|jpg|jpeg|png|swf)$”>
ExpiresDefault A29030400
</FilesMatch>
</IfModule>

 

HTTPS bzw. SSL erzwingen funktioniert mit diesem .htaccess Eintrag:

RewriteEngine On

RewriteCond %{HTTPS} !=on

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

 

Wenn Inhalte mit www. und ohne www. abrufbar sind, sollte eine Entscheidung getroffen werden. Schließlich führt es theoretisch zu Duplicate Content, wenn eine Seite über zwei oder mehrere URLs abgerufen werden kann. Diese Problematik kann ebenfalls mithilfe von .htaccess geklärt werden:

 

Immer www.:

RewriteCond %{HTTP_HOST} ^meineseite\.de$ [NC]

RewriteRule ^(.*)$ https://www.meineseite.de/$1 [R=301,L]

 

Nie www.:

RewriteCond %{HTTP_HOST} ^www.meineseite\.de$ [NC]

RewriteRule ^(.*)$ https://meineseite.de/$1 [R=301,L]

 

 

 

Einstellungen am Server vornehmen

 

Dieser Themenbereich ist schwierig zu beleuchten, weil es bei nahezu jedem Hosting-Provider Unterschiede gibt.

 

Manchmal werden mods angeboten wie mod_deflate, mod_http2,oder mod_pagespeed. Diese steigern die Performance teils erheblich. Ohne Backup und vollen Zugriff sollten Sie hier allerdings keine Experimente wagen.

 

Die PHP-Version kann ebenfalls Einfluss auf die Geschwindigkeit haben. Ebenso steigern PHP-Erweiterungen wie APC oder OPcache die Leistung. Klopfen Sie beim Auftraggeber ab, ob hier alle Einstellungen vorgenommen wurden. Probieren Sie hier nichts auf gut Glück aus – zumindest nie ohne Backup.

 

Mit diesen Beispielen sollten Sie einen guten ersten Überblick und Einstieg in die Thematik bekommen haben. Falls Sie in diesem Bereich tiefer einsteigen möchten – sehr gut! Schauen Sie bei https://jweiland.net/know-how.html vorbei und testen Sie ihr Erlerntes am besten selbst an einigen Versuchsobjekten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.