Archiv für das Jahr: 2016

Bilder aus der Google Suche entfernen

Manchmal landen Bilder im Google Suche Index, die man dort vielleicht lieber nicht sehen möchte: private Bilder, Testbilder, alte Bilder. Dann stellt sich die Frage, wie kann ich die Bilder aus der Google Suche entfernen, so dass sie nicht mehr gefunden, nicht mehr angezeigt werden? So war es auch in einem Fall, bei dem ich neulich helfen durfte.

Es ging im konkreten Fall um eine Testseite – und eigentlich sollte diese Testseite gar nicht gefunden werden. Und vor allem sollten die Bilder nicht in der Google Suche erscheinen. Ist aber trotzdem passiert.

Die Testseite lief unter einer Subdomain – und die URL war eigentlich nirgendwo gemeldet. In WordPress war meines Wissens nach sogar auch die Option „Suchmaschinen davon abhalten, diese Website zu indexieren“ aktiviert. Aber irgendwie wurde die Seite dann trotzdem von Google gefunden. Man musste zwar schon eine spezielle Suchanfrage stellen (site:…) aber dann wurden so gut wie alle Seiten inklusive der Bilder bei Google zu finden.

Bilder löschen, Bilder melden – Löschung bei Google beantragen

Der schnellste Weg um nun zunächst die Bilder aus der Bildersuche zu entfernen geht wie folgt: zuerst sollte man die Bilder vom Webserver löschen oder zumindest unerreichbar machen. Dazu kann man zum Beispiel einen einfachen Verzeichnisschutz per htaccess-Datei installieren. So ein Verzeichnisschutz lässt sich bei vielen Hosting-Anbietern direkt im Administrationsbereich des Webspace einrichten. Eine Anleitung dazu ist auch unter der Seite Webserver/htaccess/Passwortschutz bei selfhtml.org zu finden. Damit wäre dann die Webseite und somit auch die Bilder nicht mehr erreichbar.

Wenn man keinen FTP-Zugang hat und auch keinen Verzeichnisschutz einrichten kann, bleibt einem vermutlich nichts anderes übrig, als die Bilder direkt im CMS zu löschen. Bei WordPress geht das am besten im Bereich Medien (links in der Navigationsleiste des Admin-Bereichs). Es reicht nicht aus, die Bilder aus den einzelnen Seiten zu entfernen – dann würden die Bilddateien weiterhin auf dem Webserver liegen und demensprechend auch für Google erreichbar sein. Die Bilder – also die Bilddateien müssen wirklich vom Server gelöscht werden.

Screenshot: Bilder aus der Google Suche entfernen

Im zweiten Schritt muss man die Bilder dann bei Google als gelöscht melden. Dafür gibt es ein eigens Formular, das sich in den Google Webmaster-Tools aufrufen lässt: Veraltete Inhalte entfernen. Allerdings muss man dazu einen Google-Account haben und im Bereich Webmasters angemeldet sein.

Grundsätzlich muss die Webseite, um die es geht, nicht in den Webmaster-Tools eingetragen sein. Es genügt, dass die Bilder bzw. die Dateien vom Server gelöscht – oder wenigstens für Google unerreichbar (Verzeichnisschutz) sind. Dann läßt sich die Löschung bei Google beantragen, obwohl die Seite nicht mit dem Webmaster Account verknüpft ist. Das kann im Prinizip jeder machen, der einen Webmasters-Zugang hat. Man hilft mit einer solchen Meldung Google also quasi dabei, gelöschte Bilder aus der Suche zu entfernen und somit den Index aktuell zu halten.Ddafür muss man sich nicht als Betreiber der betroffenen Webseite ausweisen.

Schwieriger wird es allerdings, wenn die Bilder nicht mehr im direkten Einflussbereich sind – also wenn sie zum Beispiel bereits von anderen Diensten, Webseiten oder Blogs aufgegriffen und erneut veröffentlicht wurden, Das wird Thema eines anderen Artiekels werden.

Hier noch einmal der Direkt-Link zum Google Formular Veraltete Inhalte entfernen.

Webseite langsam? Geschwindigkeit von PHP Skripten testen

Schreibe eine Antwort

Die Webseite lädt langsam? Es könnte an einem Skript liegen… Aber welches?

Wenn Sie zum Beispiel das Gefühl haben, dass eine bestimmte Funktion, eine spezielle Datenbankabfrage oder vielleicht ganz konkret ein bestimmtes WordPress Plugin zu langsam läuft, dann kann es durchaus mal sein, dass das an einem ungünstigen Loop liegt und/oder dass vielleicht zu viele (unnötige) Datenbankanfragen an den Webserver gestellt werden.

Bevor man aber loszieht und den vermeintlich langsamen Skripte mit dem Feuerschwert begegnet sollte man zunächst versuchen, die Ursache – die Bremse zu finden. Häufig reicht es dafür, einfach mal die Zeit zu stoppen, die ein bestimmtes Skript benötigt.

Dazu muss man lediglich vor Ausführung des verdächtigen Skripts eine Art Stoppuhr starten – wenn dann das Skript oder die Datenbankabfrage durchgelaufen ist schaut man einfach nach, wieviel Zeit vergangen ist. Und mit PHP ist es zum Glück auch relativ einfach, eine solche SToppuhr zu bauen und diese quasi um einen verdächtigen Code zu klammern – solange es sich eben um PHP Code handelt. Microtime ist Dein Freund!

Zunächst brauchen wir eine Variable für den Timer, der vor Ausführung des zu untersuchendes Codes gestartet wird:

$start_timer = microtime(true); // TIMER START

Dann wird der Timer gestoppt, sobald der Code durchgelaufen ist. Genau genommen wird hier einfach die Differenz zwischen START und STOPPin der Variable $time_passed gespeichert:

$time_passed = microtime(true) - $start_timer; // TIMER STOP

Man könnte den so errechneten Wert – also die Dauer über ein einfaches echo anzeigen lassen:

echo("Das Skript hat ".$time_passed." Sekunden benötigt.");

Wenn man dann noch den Wert auf zwei Kommastellen runden möchte, setzt man einfach die PHP Anweisung round davor:

echo("Das Skript hat ".round($time_passed, 2)." Sekunden benötigt");

Alles zusammen genommen könnte am Ende dann ungefähr so aussehen:

$start_timer = microtime(true);

// hier folgt der verdächtige Code
while … {

}

$time_passed = microtime(true) - $start_timer;

echo("Das Skript hat ".round($time_passed, 2)." Sekunden benötigt.");

Nachtrag: Ob sich der Aufwand lohnt? Ist die Ladezeit überhaupt SEO-relevant? ist eine langsam ladende Seite schlecht für SEO? Und/oder ist eine langsame Webseite schlecht für UX? Alle diese Fragen können ganz klar mit JA beantwortet werden:

Ladezeit ist SEO-relevant
Spätestens seit 2010 ist es offiziell: die Ladezeit einer Webseite beeinflusst neben vielen anderen Faktoren die Suchergebnisse-Position einer Webseite. Bereits 2009 hatte google ein Experiment durchgeführt, bei dem die Ladezeit der Suchergebnisseite künstlich verlangsamt wurde – und das Ergebnis war eindeutig: Ladezeit ist SEO-relevant.
Ladezeit ist UX-relevant
Die oben genannten Untersuchung war im Prinzip ’natürlich‘ eine Untersuchung der User Experience. Wenn die Suchergebnisseite nur 100ms bis 400ms langsamer lädt, reduziert sich die Zahl der Suchanfragen um 0,2% bis 0,6% – die Nutzer verlieren mit abnehmender Geschwindigkeit die offenbar die Lust, die Seite zu benutzen.
Lohnt sich der Aufwand?
Ich habe kürzlich für einen Kunden eine Seite optimiert, die man auch schon als WebApp bezeichnen kann. Kurz beschrieben: aus unterschiedlichen Datenbankabfragen wird je nach gesetzten Präferenzen und Optionen eine komplexe Tabelle generiert. Vor der Optimierung wurde jede Tabellenzelle bzw. die Ausgabe jeder Tabellenzelle über einen Loop einzeln generiert. Nach der Optimierung genügte eine einzige Datenbankabfrage. Wir darüberhinaus an verschiedenen Stellen im Skript die Zeit gemessen, die zum Beispiel zur Ausführung einer bestimmten Funktion benötigt wurde und anschliessend verschiedene Alternativen getestet. So konnten wir letztendlich die Zeit, die benötigt wird, um die Daten für die Tabelle zusammenzustellen von 5 – 10 Sekunden auf unter 0,5 Sekunden reduzieren. Ja: der Aufwand lohnt sich. Manchmal.

WordPress Child Theme erstellen – ganz einfach

Schreibe eine Antwort

Wenn man eine WordPress Webseite erstellen möchte, sollte man am besten gleich auch ein WordPress Child Theme erstellen. Es gibt natürlich eine Fülle fertiger WordPress Themes – und viele kostenpflichtige Premium Themes bieten bereits umfangreiche Anpassungsmöglichkeiten: über diverse Optionen lassen sich häufig ‚ganz einfach‘ Design-Details wie Schriftart und Farben anpassen. Und auch bei kostenlosen Themes lässt sich häufig immerhin die Schriftfarbe oder andere Design-Elemente über eingebaute Optionen ändern. Egal für welches Theme man sich am Ende entscheidet – hier und da möchte man gegebenenfalls Design–Anpssungen machen, sodass das Deisgn den eigenen Wünschen bzw. den Kundenwünschen entspricht und sich vonanderen Webseiten abhebt.

Der einfachste Weg ist sicherlich, direkt in den entsprechenden Templates und Stylesheets Änderungen vorzunehmen. Dies ist allerdings auch der ‚drechigste‘ Weg – ein alter Grundsatz lautet: never hack the core! Beim nächsten Update kann das sonst zu bösen Überraschungen führen: die mühsam eingearbeiteten Anpassungen werden beim Update unter Umständen direkt überschrieben, Design-Anpassungen gehen verloren und dann sieht plötzlch alles wieder genau so aus, wie am Anfang.

Der wirklich einfachste Weg, um schnell individuelle Anpassungen an einem WordPress Theme vorzunehmen ist, ein eigenes Child Theme einzurichten.

WordPress Child Theme erstellen – ganz einfach

Vor einigen Jahren war es noch etwas umständlich, schnell mal ein eigenes WordPress Child Theme zu erstellen. Inzwischen ist das aber sehr viel einfacher geworden. Im Prinzip muss man nur zwei Dateien anlegen – schon kann man mit den eigenen Style-Anweisungen die voreingestellten Theme-Styles überschreiben. Genug der Vorrede – so geht’s:

Zunächst legt man im Themes-Verzeichnis ein neues leeren Verzeichnis an. Dieses Verzeichnis wird dann alle Dateien beinhalten, die unser Child Theme benötigt. Das Verzeichnis sollte daher schon so benannt sein, wie das Child Theme heissen soll. In diesem Falle nennen wir das Child Theme einfach mal „Mein Theme“ und das Verzeichnis dementsprechend „mein-theme“.

1) Child Theme Stylesheet style.css einrichten

In dem neuen Verzeichnis legt man dann ein Stylesheet an, das folgenden Code enthalten sollte:

/*
 Theme Name:   Mein Theme
 Theme URI:    http://cpu20.de/mein-theme/
 Description:  Twenty Fifteen Child Theme
 Author:       Vorname Nachname
 Author URI:   http://cpu20.de
 Template:     twentyfifteen
 Version:      1.0.0
 License:      GNU General Public License v2 or later
 License URI:  http://www.gnu.org/licenses/gpl-2.0.html
 Tags:         light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
 Text Domain:  mein-theme
*/

Wozu sind die einzelnen Angaben notwendig? Naja – die meisten Angaben sind nicht wirklich notwenig, damit das Child Theme auch funktioniert. Es ist aber gut, sich an die verabredeten Strukturen zu halten, damit später mal jemand nachvollziehen kann, womit er es hier eigentlich zu tun hat. Ausserdem werden einige der Angaben des sogn. Stylesheet-Headers später im Administrationsbereich von WordPress angezeigt.

Ich habe mir angewöhnt, das Child Theme nach dem jeweiligen Projekt bzw. dem Kunden zu benennen. Damit ist dann allen beteiligten klar, dass es sich hier um Anpassungen handelt, die speziell für diesen Kunden vorgenommen wurden. Das kann aber natürlich jeder so machen, wie er möchte. Kurz ein paar Details zu den Angaben:

Theme Name ist der Name des Themes in diesem Falle des Child Themes.
Theme URI ist die Web-Adresse, unter der man mehr über dieses Theme erfährt.
Unter Description sollte eine kurze Beschreibung des Themes zu finden sein.
Der Author ist natürlich der Autor des Child Themes und über die Author URI sollte der Autor zu finden sein.
Bei Template muss das Verzeichnis des Parent Themes eingetragen werden, das überschrieben bzw. ergänzt werden soll (wichtig!). In diesem Falle wäre also twentyfifteen das Parent Theme.
Version sollte selbsterklärend sein – die Version des Themes.
Unter Licence und Licence URI ist die Nutzerlizenz des Themes hinterlegt. In des meisten Fällen sollte das die GNU General Public License sein.
Mit Tags lässt sich das Theme beschreiben – das erleichtert ggf. ein späteres Auffinden in Themes-Verzeichnissen.
Und die Text Domain ist wiederum wichtig, damit das Theme auch in andere Sprachen übersetzt werden kann. Sie muss eindeutig sein und sollte sich am Namen des Themes orientieren.

Der erste Schritt zum WordPress Child Theme ist gemacht – jetzt müssen wir nur noch Child Theme und Parent Theme miteienander verbinden – und das passiert in der Datei functions.php…

2) Child Theme functions.php einrichten

Die zweite Datei im Child Theme Verzeichnis ist die functions.php, die wenigstens den Code enthalten muss, der das Child Theme mit dem Parent Theme verbindet. Das Child Theme würde zwar theoretisch auch ohne diese Verbindung funktionieren – es würden aber keine Style-Anweisungen und keine Funktionen des Parent Themes übernommen werden – somit wäre das Child Theme kein Child mehr, sondern ein eigentständiges Theme.

Hier also der Code:

<?php
function theme_enqueue_styles() {

    $parent_style = 'parent-style';

    wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( $parent_style )
    );
}
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
?>

Was dieser Code-Schnippsel macht: zunächst wird das Stylesheet des Parent Themes geladen, dann das Stylesheet des Child Themes. Damit ist gewährleistet, dass zunächst alle Style-Anweisung ‚reguler‘ befolgt werden. Anschliessend werden die individuellen Anpassungen berücksichtigt.

In einem letzten Schritt muss das neue Theme nun noch aktiviert werden. Sobald das Verzeichnis auf den Webserver geladen wurde sollte es im Administrationsbereich unter Design > Themes zu finden sein. Nachdem es aktiviert wurde greifen alle Anpassungen, die man im Stylesheet hinterlegt hat. Ausserdem lassen sich der functions.php nun auch beliebige Funktionen hinzufügen, die das Theme ggf. bereichern können.

Wer möchte, kann nun auch noch ein paar Schritte weiter gehen. Grundsätzlich lässt sich in weinem WordPress Child Theme alles das anpassen, was ein WordPress Theme zu bieten hat. Dazu aber mehr in einem anderen Tutorial. Zunächst würde ich mal empfehlen, einen Screenshot des Child Themes zu hinterlegen. Dazu legt man einfach ein entsprechendes png-Bild im Theme-Verzeichnis an und benennt es screenshot.png – damit sieht das Theme auch im Administrationsbereich dann ‚ordentlich‘ aus.

WordPress Webseiten-Umzug von Server/Domain A zu Server/Domain B

Schreibe eine Antwort

Möchte man eine WordPress-Webseite erstellen, dann bietet es sich an, die Webseite zunächst auf einem Testserver bzw. in einer Entwicklungsumgebung zu erstellen. Wenn dann das Design steht, alle Plugins installiert sind und auch die Inhalte ihren Weg auf die Webseite gefunden haben ist es Zeit, die Webseite umzuziehen. Manchmal möchte man vielleicht auch „nur“ den Hosting-Anbieter wechseln – ein Server-Umzug steht an.

Ich habe dazu schon früher schon einmal einen etwas ausführlichen Beitrag geschrieben: Domain-Umzug mit WordPress-Webseite [Anleitung und Tipps]. Allerdings hatte der Beitrag eher die grundsätzlichen Prinzipien im Fokus. Damals habe ich mich vor allem auf Plugins konzentriert, die einem helfen, die WordPress-Datenbank von einem Server zum anderen – von einer Domain zu einer anderen umziehen zu lassen. In diesem Beitrag möchte ich nun konkret eine Reihe Plugins empfehlen, die einem bei einem kompletten Server- und/oder Domain-Umzug helfen können.

Standard Export-Import-Funktion im WordPress Administrationsbereich

WordPress bringt von Hause aus eine eigene Export-Import-Funktion mit. Allerdings ist die wirklich sehr rudimentär: es werden lediglich die Inhalte, aber keine Plugins oder Medien etc. umgezogen. Und wenn man nicht nur den Webspace, sondern vielleicht auch die Domain wechselt muss man anschliessend in der Regel dann auch noch viele tote Links reparieren. Nicht besonders praktikabel – aber in einigen Fällen sicherlich schon ausreichend.

Plugin #1: Akeeba Backup

Dieses Plugin erstellt ein Backup der gesamten Webseite – inklusive aller Verzeichnisse und natürlich auch inklusive der Datenbank. Je nach Größe bzw. Umfang der Webseite kann ein kompletter Umzug in wenigen Minuten erledigt sein.

Das Plugin wird seit Juli 2015 nicht mehr bei WordPress.org im Plugin-Verzeichnis gelistet, da es wohl einen Streit um den Leistungsumfang der kostenlosen Version gab. Es ist jedenfalls nach wie vor eine kostenlose Basis-Version verfügbar – vom Leistungsumfang sollte sich vielleicht am besten jeder selbst ein Bild machen: akeebabackup.com/download/backup-wordpress.html

Plugin #2: Duplicator

Und dann ist da Duplicator – ein offenbar kostenloses Plugin, das auf WordPress.org ziemlich populär zu sein scheint und auch viele gute Bewertungen bekommen hat. Von der Plugin-Seite: „Duplicator gibt WordPress-Administratoren die Möglichkeit, eine Website von einem Ort zum anderen zu migrieren, kopieren oder klonen. Das Plugin dient auch als einfaches Backup-Programm.“

WordPress Plugin Duplicator: Umzug Clone Backup von kompletten WordPress Webseiten

Die Einstellungen können auf den ersten Blick ziemlich komplex und kompliziert erscheinen. Das Plugin arebitet mit der Metapher ‚Packages‘ – man muss also zunächst ein neues Package anlegen. Es kann notwendig sein, dass man die Schreibrechte anpasst – vorübergehend kann man 777 verwenden, sodass das Plugin selbstständig die notwendigen Verzeichnisse anlegen kann.

Klingt vielersprechend? Ist vielersprechend. Das Plugin Duplicator kann man kostenlos bei wordpress.org herunterladen. Hier gehts zum Download: de.wordpress.org/plugins/duplicator

Plugin #3: WP Clone

Auch mit WP Clone kann man eine Seitevon einem Server zum anderen umziehen lassen – oder auch von einer lokalen Installation auf einen Webserver umziehen. Dazu muss man zunächst WordPress auf dem neuen Webspace installieren, dann das Plugin WP Clone auf beiden Systemen installieren. Im alten CMS / auf dem alten Server wählt man dann die Export-Funktion – auf dem neuen Sevrer dementsprechend die Import-Funktion.

Aber vorsicht: beim Import wird die komplette WordPress-Installation neu installiert. Alles, was man bis zum Import gegebenenfalls bereits angepasst oder eingegeben hat geht verloren. Das scheint nicht allen Nutzern vorher klar gewesen zu sein – die alte Diskussion „Bug vs. Feature“.

Das Plugin WP Clone von WP Academy kann man kostenlos bei wordpress.org herunterladen. Hier gehts zum Download: wordpress.org/plugins/wp-clone-by-wp-academy

Fazit: Die hier vorgestellten Plugins eignen sich vor allem, um koplette WordPress Webseiten / WOrdpress Blogs umziehen zu lassen. Sie eignen sich meiner Meinung nach hingegen nicht als Backup-Tool.

Benötigen Sie Unterstützung bei Gestaltung, Umzug oder beim Erstellen einer Webseite? Meine Kontakt-Details finden Sie hier.

404 Fehler vermeiden – tote Links finden und reparieren

Error 404 page not found - Fehler beheben - Foto/Montage: T.Bortels/cpu20.de

2 Antworten

Wenn man eine Webseite neu erstellt, sollte ja erst mal eigentlich alles funktionieren. Erfahrungsgemäß werden alle internen Links frisch gesetzt und alle externen Links auf Aktualität geprüft – damit sollte man im besten Falle gar keine toten Links auf seiner Webseite haben und der Error 404 sollte gar nicht erst auftreten.

Ganz anders kann sich das natürlich, verhalten, wenn es sich nicht um eine neu erstellte Webseite handelt, sondern zum Beispiel um einen Webseiten-Umzug oder sogar um einen Relaunch. Evenuell hat sich die Seitenstruktur verändert, Rubriken verschoben, URLs geändert. Dann sollte man natürlich schon aus SEO-Gründen versuchen, möglichst viele alte und unter Umständen wertvolle URLs und interne Verlinkungen zu „retten“ indem man entsprechende Weiterleitungen einrichtet – also zum Beispiel über die htaccess-Datei per 301-Rückmeldung Suchmaschinen direkt die neuen Adressen der alten Inhalte mitteilt. Das soll aber nicht Thema dieses Eintrags sein – hier geht es zunächst mal um die kaputten Links, und wie man kaputte Links überhaupt finden kann.

Webseiten-Pflege / Webseiten-Wartung

In diesem Eintrag geht es mir um Webseiten, die vielleicht schon ein paar Jahre online sind. Im Laufe der Zeit kann es passieren, dass sich URLs ändern – und dass man das entweder nicht direkt mitbekommt, weil es sich zum Beispiel um externe Verlinkungen handelt – oder man vergißt ganz einfach, die eigenen internen Verlinkungen anzupassen. In der Folge hat man plötzlich hier und da tote Links, die auf keine gültige Webadresse verlinken – und es wird der Fehlercode 404 ausgegeben. Im Laufe der Jahre kann da schon einiges zusammen kommen. Daher sollte man von Zeit zu Zeit mal nachsehen, ob man vielleicht den einen oder anderen toten Link auf der Webseite hat und diesen dann gegebenenfalls reparieren. Wir nennen diese Routine in Anlehnung an die Englische Bezeichnung einfach mal Link-Checking.

Warum das wichtig ist? Zum einen sind tote Links für Besucher ärgerlich – langfristig leidet der Ruf der Webseite. Und uchmaschinen mögen tote Links schon gar nicht. Also sollte man auch im Sinne einer gewissen Suchmaschinenoptimierung (SEO) wenigstens hin und wieder mal ein paar tote Links reparieren und so 404 Fehler vermeiden.

Link-Checking: Tote Links finden, 404 Fehler vermeiden

Schonmal vorab:

Link-Checking (blöder Begriff? Ich weiss…) macht man am besten nicht händisch. Auch wenn man meint, die Webseite sei ja gar nicht so groß – es kann Stunden oder sogar Tage dauern, bis man den ersten toten Link gefunden hat. Und die Gefahr ist dann, dass man meint, es wäre alles in Ordnung. Aber nur, weil man selbst keine toten Links findet, heisst das nicht, dass es keine toten Links gibt.
Link-Checking macht man am besten von aussen – also nicht direkt über das CMS, auch wenn es zum Beispiel für WordPress unter Umständen spezielle Plugins gibt, die tote Links finden können. Stattdessen verwendet man am besten entweder einen externen Dienst oder ein Programm, das lokal auf einem Rechner läuft.
TLDR / mein aktueller Favourit: deadlinkchecker.com

WordPress Plugin: Broken Link Checker

Es gibt zurzeit offenbar nur ein Plugin für WordPress, das als „Link Checker“ angepriesen wird: Broken Link Checker. Das kann aber leider keine Seitenleisten bzw. keine Widgets durchsuchen. Daher ist es für Verlinkungen aus Widgets heraus – und damit zum Beispiel für Blogrolls etc. leider nicht geeignet.

Zudem hat das Plugin auch ziemlich schlechte Bewertungen wegen Performance-Problemen bekommen. Die Probleme reichen wohl bis hin zur Unerreichbarkeit der Webseite – der Server verweigert weitere Zugriffe und gibt einen 500er Server-Error aus.

Wer das Plugin aber trotzdem mal testen will kann es hier finden: wordpress.org/plugins/broken-link-checker

Mit „Screaming Frog SEO Spider“ tote Links finden (Cross-Plattform Programm)

Vorab das Gute am Programm Screaming Frog SEO Spider: die kostenpflichtige Version scheint sehr komplex und voll mit unterschiedlichen Funktionen zu sein, mit denen man seine Webseite optimieren kann. Ausserdem funktioniert das Programm wohl auf Mac, PC und Linux gleichermaßen.

Ich habe mir dann allerdings mal die kostenlose Version des „Screaming Frog SEO Spider“ angesehen und getestet, was damit möglich ist – und was nicht. Bei dem Programm handelt es sich offenbar vor allem um ein umfangreiches Analyse-Tppl, das lokal aufm Rechner installiert werden kann und das eine Webseite quasi „von aussen“ untersucht.

Grundsätzlich halte ich das Pronzip für eine gute Idee. Die kostenlose Version ist aber leider so gut wie nutzlos – es läßt sich meines WIssens nach immer nur 1 Seite untersuchen. Die Vollversion ist mir dann aber auch wieder leider zu groß, zu mächtig, und voe allem mit $99 pro Jahr einfach zu teuer, um gelegentlich mal ein paar tote Links zu finden.

Wer das Programm aber dennoch mal testen möchte kann es hier finden: screamingfrog.co.uk/seo-spider

Mit integrity tote Links finden (Programm für Mac OS X)

Das Programm integrity aus dem Hause Peacockmedia bietet eine sehr aufgeräumte und kompakte Benutzeroberfläche – und eine Link-Analyse ist auch bereits mit der kostenlosen Version möglich. Man gibt einfach die URL der Webseite ein und lässt das Programm ein paar Minuten lang die Webseite nach toten Links durchsuchen.

Anschliessend kann man sich alle Links oder eben nur die 404-Fehler-Links anzeigen lassen. Dabei werden alle Seiten aufgelistet, auf denen der Link zu finden ist.

Es werden allerdings offenbar nur verlinkte Seiten / Webseiten aufgeführt – eine eventuell fehlerhaft verlinkte Javascript-Datei fehlt – und auch überflüssige bzw. nicht vorhandene Feeds (RSS/XML) werden nicht aufgelistet. Daher ist dieses Programm eher dazu geeignet, um schnell mal zwischendurch nachzusehen, ob alle für Besucher direkt sichtbaren Links in Ordnung sind.

Hier ist das Programm zu finden: peacockmedia.software/mac/integrity

Online Service: Link-Checker von w3.org

Als nächstes habe ich mir den offiziellen Link-Checker von w3.org angesehen. Ein paar Vorteile sind schnell zu erkennen: das Tool ist online frei verfügbar. Es muss also keine Software installiert werden, es ist keine Mitgliedschaft erforderlich, es entstehen keine Kosten.

Nachteile: es kann ziemlich lange dauern, bis man eine Webseite auf tote Links hin untersucht hat. Der Spider klappert offenbar wirklich alle Seiten gründlich ab und gibt dann auch einen entsprechend umfangreichen Bericht aus. Dabei beschränkt sich der Link-Validator nicht alleine auf…

Es ist auf jedenfall eine gute Ide, beim ersten Durchlauf die Option „Summary only“ zu wählen. Aber selbst dann gibt der Validator vermutlich mehr Informationen über ungültige Verlinkungen aus, als man eigentlich haben möchte. In seltenen Fällen kann es auch hier dazu kommen, dass der Server einfach weitere Zugriffe blockiert und einen 500er-Fehler zurückgibt.

Wer den Service aber dennoch mal testen möchte, kann ihn hier finden: validator.w3.org/checklink

Online Service: Dead Link Check

Beim Dead Link Check handelt es sich um ein kostenloses Online Tool, mit dem man ziemlich unkompliziert und direkt nach toten Links suchen kann. Man muss lediglich die URL der zu durchsuchenden Webseite eingeben – es folgt eine einfache CAPTCHA-Abfrage mit der man bestätigt, dass man kein Roboter ist. Daraufhin beginnt das Tool die Webseite zu durchsuchen.

Bei größeren Webseiten bzw. ab 2500 zu durchsuchenden URLs kommt dann eine erneute CATCHA-Abfrage – danach sucht das Tool fleißig weiter. Der anschliessende Bericht ist sehr übersichtlich – es werden nur die problematischen Links zusammen mit der jeweils problematischen Seite ausgegeben.

Neben direkten Links zu anderen Seiten / Webseiten werden auch solche ausgegeben, die auf den ersten Blick nicht einfach zu entdecken wären: zum Beispiel JavaScripte, Stylesheets, Webfonts. Ich habe bei einem solchen Test zum Beispiel herausgefunden, dass eine meiner WordPress-Installationen für jede CPT-Seite (Custom Post Type Page) einen Link zu einer Kommentar-Feed bereitstellt, die es so aber gar nicht gibt. Das ließ sich dank diesem Hinweis im WordPress-Forum leicht beheben – hätte ich ohne automatische Dead-Link-Suche aber vermutlich nie herausgefunden. Wie auch immer.

Anschliessend kann man die Liste der problematischen Links dann ‚ganz einfach‘ abarbeiten und so Link für Link reparieren. Hier geht’s zum Tool: deadlinkchecker.com

Favorit: Online Broken Link Checker

Auch der Broken Link Checker ist ein kostenloses Online Tool. Die Link-Analyse kann einige Zeit dauern – aber auch hier lohnt sich die Geduld.

Der Broken Link Checker ist eventuell ein wenig schneller, als das Online Tool Dead Link Check. Allerdings ist die Analyse bei weitem nicht so ausführlich – und die Anzahl der durchsuchten Seiten ist auch verdächtig niedrig. Trotzdem möchte ich das Tool empfehlen – die Bedienung ist einfach und der Link-Bericht kann helfen, grobe Link-Fehler zu vermeiden.

Hier geht’s zum Tool: brokenlinkcheck.com

…na dann: Happy Link-Checking! 🙂

Nachtrag: In seinem Blogpost „404-Fehlerseiten mit Google Analytics und Tag Manager tracken“ zeigt Christian Ebernickel, wie man mithilfe von Google Analytics 404-Fehlerseiten finden kann.

Email mit „Domain availability notice“ – was tun?

Schreibe eine Antwort

Wenn man ein paar Domains besitzt, bekommt man hin und wieder Emails mit der Betreffzeile „Domain X availability notice“. Manchmal steht auch einfach nur der Domainname „Domain X“ in der Betreffzeile, und der Absender lautet zum Beispiel „Domain Available Info“. Und manchmal bekommt man sogar gleich von mehreren Diensten ähnlcihe Emails zugeschickt.

Dabei bezieht sich „Domain X“ meistens auf einen Domainnamen, der einem irgendwie bekannt vorkommt – der einem Domainnamen ähnelt, den man selbst in der Sammlung hat. Häufig Domains mit alternativer Endung angeboten. Zum Beispiel wird einem nahegelegt, dass doch „cpu20.com“ gut zu „cpu20.de“ passen würde. Was tun?

“ I just wanted to let you know that domain CPU20.COM is now available again and we are brokering the sale. Since you have a related domain name we thought you might have some interest in this one? „

Bei diesen Diensten handelt es sich in der Regel um professionelle Domain-Händler, die gerne auch mal als „Domain-Grabber“ bezeichnet werden.

Was machen Domain-Grabber? Dürfen die das?

Grundsätzlich sollten Domains eigentlich nur von Personen und Firmen registriert werden, die ein direktes Interesse an der jeweiligen Domain haben. So steht es zumindest in den Richtlinien des Internic – der zentralen Registrierungsstelle für Domainnamen. Trotzdem reservieren Domain-Grabber und Domain-Händler gerne manchmal hunderte oder sogar tausende Domains, um diese eventuell gewinnbringend zu veräßern. Rechtlich bewegen sie sich damit meines Wissens nach in einer Grauzone. Praktisch kann man dagegen aber kaum etwas tun.

Häufig fangen Domain-Grabber abgelaufene Domains auf. Wenn eine Domain aufgegeben und somit wieder frei wird, kann sie theoretisch jeder neu registrieren. In der Praxis wird aber ein Großteil der freiwerdenden Domains inzwischen von solchen Domain-Grabbern abgegriffen.

Was kann man tun?

Es ergeben sich eigentlich die folgenden drei Möglichkeiten:

Domain-Grabber beauftragen
Man möchte die angebotene Domain übernehmen und beauftragt einen solchen Dienst mit der Übernahme. Je nach Dienst und je nach Domain wird dann eine bestimme Gebühr fällig. In der Regel bewegen sich die Kosten zwischen 100 und 200 Dollar – es kann aber auch teurer werden.
Domain selber registrieren
Man kann natürlich darauf hoffen, dass man schneller ist, als die Domain-Grabber. Das wird technisch aber kaum möglich sein. Insofern bleibt eigentlich nur die Hoffnung, dass die Domain-Grabber die Domain zwar anbieten, aber ohne feste Zusage nicht tätig werden und die Domain somit fallengelassen und letztendlich frei registrierbar wird. Das kann klappen, aber man sollte sich nicht darauf verlassen.
Alternative Domain registrieren
Man sucht sich einfach eine alternative Domain und registriet diese. Zunächst kann das etwas frustrierend sein, da sich der angebotene Domainname vielleicht schon als ‚Gute Wahl‘ ins Gedächtnis gebrannt hat. Aber letztendlich ist die Registrierung einer alternativen Domain nicht wirklich von Nachteil. Schließlich kommt es beim Erfolg einer Webseite am Ende auf sehr viel mehr an, als *nur* auf den optimalen Domainnamen. Und man kann sich rühmen, die Domain-Grabber nicht gefüttert zu haben. Schließlich funktioniert dieses etwas fragwürdige Business nur dann, wenn immer wieder genug Leute bereit sind, für deren Dienste zu bezahlen.

Update: In einem aktuellen Fall hat sich die Geduld bezahlt gemacht. Ich habe einfach stillgehalten, nicht auf die Emails reagiert, keinen Link angeklickt. Stattdessen habe ich regelmäßig nachgesehen, ob die Domain frei ist – und schließlich war sie frei und ich konnte sie ohne zusätzliche Kosten und ohne Zwischenhändler registrieren.