Heute berichtete Fritz darüber, dass er sogar den Cache seines Browsers dafür leeren musste.

Ein unhaltbarer Zustand! Deswegen habe ich dieses Problem nun priorisiert und folgende Maßnahmen ergriffen:

• Das WordPress-Plugin DB Cache Reloaded als möglichen (Mit-)Täter habe ich deaktiviert (siehe hierzu auch den Blogbeitrag “Verschwundene Kommentare im Firefox – Cache Problem?” einschließlich Kommentare).
• Ferner habe ich in meiner .htaccess-Datei das generelle Ablaufdatum (expire date) von 10 Jahren ab Aufruf (Client-Abfrage) auf MIME-Type ohne HTML umgestellt (siehe hierzu z.B. die Konfigurationsdirektive: ExpiresDefault und Speed Up Sites with htaccess Caching).

Hier meine alte Einstellung aus der .htaccess-Datei für expire date:

Und so sieht nun die neue Einstellung hierfür in meiner .htaccess-Datei aus:

Kontrolliert, ob damit expire date für den MIME-Type HTML entfernt ist, habe ich mit dem Firefox-Addon YSlow. Unter Components bekommt man durch Mausklick auf die Überschriftsspalte Expires (Y/M/D) no expires oder ein expire date angezeigt.

Ich hoffe, das behebt das Anzeigeproblem neuer Kommentare. Vorsorglich weise ich aber noch einmal darauf hin, dass ich Erstkommentare und Kommentare mit Links moderiere (siehe hierzu auch den Blogbeitrag “Kommentar-Spam bekämpfen“).

Für Hinweise, ob es noch Probleme gibt oder diese nun behoben sind, bin ich jederzeit dankbar. Deshalb hier schon mal ein großes Dankeschön an Fritz, der mir über eine Twitter-Direktnachricht bestätigte, dass bei ihm das mit der Aktualisierung unmittelbar nach dem Absenden eines Kommentars nun klappt.

Für Anmerkungen, Hinweise und Rückmeldungen kannst Du gerne die Kommentarfunktion nutzen.

Kommentare

• 5. Dezember 2010, Ute schreibt: Bei mir klappte es vorhin auch, danke fürs Reparieren. :hurra:
• 5. Dezember 2010, Dieter schreibt: @Ute Danke für die Rückmeldung. Und ja: :hurra: Hoffe, dass das Problem nun endgültig behoben ist.
• 17. Dezember 2010, Moni schreibt: Ich mache das sonst immer mit folgendem Metatag, aber dein Lösungsansatz mit der .htaccess ist auch recht interessant. Leider kann man diese nicht auf allen Sharing Hostern selbst editieren: Einfach in den Header mit rein...
• 17. Dezember 2010, Dieter schreibt: @Moni Metatag-Lösung ist mir nicht bekannt. Von Sharing Hoster, bei denen man die .htaccess-Datei nicht bearbeiten kann, rate ich ab. Dein Code für den Header ist nicht zu sehen. Ich nehme an, dass Du vergessen hast den Code als solchen zu kennzeichnen. PS: Insbesondere Erstkommentare und Kommentare mit Links moderiere ich. SEO-Keywords im Namen akzeptiere ich nicht. In der Regel lösche ich dann auch den Link zur Website!
• 20. Mai 2011, Marc Nemitz schreibt: Hallo, besteht das Problem aktuell noch oder wurde es endgültig im Zuge der neuen WP-Versionen behoben? Und noch eine Frage, wenn ich mehrere Domains auf einem Platz laufen habe, muss ich etwas besonderes beachten bei der htaccess? Gruß Marc
• 20. Mai 2011, Dieter schreibt: Hallo Marc, das Problem war meinen Optimierungsmaßnahmen für eine geringe Ladezeit geschuldet. Das hat nichts mit einer bestimmten WordPress-Version zu tun. Deine zweite Frage erschließt sich mir nicht. Was meinst Du mit "Platz"? Gruß zurück Dieter

Ähnliche Beiträge

• Bild oder Foto beim Kommentar
• Startseite
• Webdesign-Beiträge über Webdesign-Infos.de erreichbar
• Ladezeit als Google-Rankingfaktor
• Auf Moderation von Kommentaren hinweisen

Permalink | 6 Kommentare | Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena
Schlagwörter: .htaccess, Cache, DB Cache Reloaded, expire date, Kommentar, Plugin, WordPress

Zwar bin ich ein Laie in Sachen Administration eines Apache-Servers, aber soviel habe ich mitbekommen:

Bots (Robots, Webcrawler), die sich nicht an die robots.txt halten, kann man guten Gewissens von der Website aussperren.

Hier mein aktuelles Praxisbeispiel:

In den Logdaten meiner chCounter-Installation auf Webseiten-Infos.de tauchte sehr häufig der Crawler 80legs mit folgendem User Agent, aber ständig wechselnden IP-Adressen und Hosts auf:

Ich überprüfte die im User Agent enthaltene Website http://www.80legs.com/spider.html. Danach handelte es sich um einen Webcrawler und nach den FAQ hierzu sollte ein Ausschluss des Crawlers in der robots.txt beachtet werden:

Wie ich aber den Logdaten von chCounter entnehmen konnte, war dem aber leider nicht so. Auch nach dieser Ergänzung der robots.txt tauchten viele Logdaten mit diesem User Agent auf.

Nun war ich mir sicher, dass es sich um einen sogenannten ungezogenen Jungen (bad guy) handelte, sprich einen Bot (Robot, Webcrawler), der nur vorgibt zu 80legs zu gehören. Also wollte und konnte ich diesen Bot (Robot, Webcrawler) ohne schlechtes Gewissen blockieren.

Das Aussperren dieses Bots (Robots, Webcrawlers) von Webseiten-Infos.de gelang mir mit folgender Ergänzung der .htaccess auf meinem Webspace:

Wie oben schon erwähnt, bin ich kein Experte für den Webserver Apache. Leider fand ich im Netz (Web) auch keine gut lesbaren Einsteigerinfos zur richtigen Schreibweise von solchen Einträgen in der .htaccess. Ich dachte mir lediglich, dass es wohl erforderlich sein dürfte, alle Zeichen, die keine Buchstaben oder Schrägstrich (Slash) sind, durch einen sogenannten umgekehrten Schrägstrich (Backslash) zu maskieren.

Darüber hinaus dachte ich mir, dass es nichts schaden könnte, wenn ich die Funktionsfähigkeit dieser Ergänzung der .htaccess testen könnte.

Und tatsächlich: Das geht mittels dem Firefox-Addon User Agent Switcher 0.7.2.

Dieses Addon kann auch um beliebige User Agents ergänzt werden. Ich habe bei mir das Addon User Agent Switcher 0.7.2 um oben genannten User-Agent ergänzt und dann meinen Firefox auf diesen User Agent umgestellt. Ein Neuladen der Webseite Webseiten-Infos.de führte dann zu folgender Meldung:

Forbidden

You don’t have permission to access / on this server.

Mit den anderen User Agents für die gängigen Browser lässt sich dagegen die Website Webseiten-Infos.de problemlos aufrufen.

Seitdem ich die .htaccess entsprechend ergänzt habe, finden sich in den Logdaten auch keine neuen Zugriffe mit diesem User Agent mehr.

Die Aussperrung dieses User Agent scheint also zu funktionieren.

Solltest Du Anmerkungen oder Verbesserungsvorschläge haben, dann nur her damit.

Kommentare

• 11. März 2010, Thomas Scholz schreibt: Was für Spam hat der denn hinterlassen?
• 11. März 2010, Dieter schreibt: Ich sollte so spät nachts keine Blogbeiträge schreiben. ;-) Du hast mal wieder den Nagel auf den Kopf getroffen. Die einzige von mir beobachtete Aktivität des Bots war die Missachtung der robots.txt. Er war mir mit seinen weiterhin extrem häufigen Zugriffen auf meine Webseiten, die mir die Besucherstatistik verfälschen und Serverressourcen verbrauchen, lediglich suspekt. Werde den Titel des Blogbeitrags gleich mal korrigieren. Danke für den Gedankenschubser!
• 14. März 2010, Andreas schreibt: Von solchen Bots habe ich bisher noch nichts gehört, aber der Artikel ist dennoch interessant. Ich werde mit den Link mal abspeichern, und wenn ich dann doch Besuch von einem solchen Bot bekomme, weiß ich ja, was ich zu tun habe. Bekäme man Spambots denn auf dieselbe Weise los? Vielleicht bekomme ich von so einem ja über kurz oder lang mal Besuch.
• 14. März 2010, Dieter schreibt: @Andreas Geht auch mit Spambots, wenn die einen unüblichen User Agent verwenden oder immer von der gleichen IP-Adresse kommen. Und im Übrigen kann ich Dir das WordPress-Plugin Antispam Bee gegen automatisierte Spam-Kommentare uneingeschränkt empfehlen. Ich hoffe, das hilft Dir im Bedarfsfall weiter. Beste Grüße Dieter
• 14. März 2010, Thomas schreibt: Bin auch gerade auf der Suche nach einer besseren Lösung. Leider kommen die SpamBots bei mir immer mit unterschiedlicher IP und auch mit wechselndem UserAgent. Danke für den Tipp mit "Antispam Bee" - kannte ich bisher noch nicht - werd ich mir gleich mal ansehen. Zu der Misachtung der robots.txt solltest du mal auf bot-trap.de schauen.
• 14. März 2010, Dieter schreibt: @Thomas Die fleißige Biene Antispam Bee kannst Du auch so einstellen, dass sie die automatischen Spam-Kommentare direkt blockt. Dann bekommen Du und Deine WordPress-Datenbank diesen Spam noch nicht einmal mehr zu sehen. Danke für den Hinweis auf bot-trap.de. Steht bei mir schon auf der Liste der Websites, die ich mir noch näher ansehen will. Hast Du denn schon Erfahrungen mit bot-trap.de gemacht? Beste Grüße Dieter
• 14. März 2010, Icem@n schreibt: Auf der Suche nach Infos zu diesem Bot, bin ich auf diesen Eintrag gestoßen. Heute Nacht kam das Ding auch bei mir vorbei und bescherte mir rund 500 Besucher in knappen 4 Stunden. In den Logfiles habe ich bisher nichts Ungewöhnlichliches entdeckt, außer, dass sehr oft das Gästebuch und der Veranstaltungskalender besucht wurde. Ist mir jedenfalls höchst suspekt. Hast du noch weitere Infos zu diesem Spider finden können?
• 14. März 2010, Dieter schreibt: @Icem@n Habe leider keine weiteren Infos zu dem Spider gefunden. Da er sich aber entgegen der Website nicht an die robots.txt hält, gehe ich stark davon aus, dass es sich um einen vorgetäuschten User Agent handelt und der Bot mit Sicherheit nicht mein Freund, sondern mein Feind ist.
• 15. März 2010, Thomas schreibt: @Dieter: Nein, ich habe bisher nur gelesen und gehört, dass das mit der Bot-Falle super funktionieren soll. Wenn bei der Antispam Bee die Beiträge nichtmal mehr in der Datenbank landen, wäre das ja ein echter Vorteil gegenüber SpamKarma - wobei man das dort vielleicht auch einstellen kann und ich habs nur noch nicht gefunden.
• 15. März 2010, Dieter schreibt: @Thomas Dann werde ich demnächst mal bot-trap.de ausprobieren. SpamKarma habe ich noch nicht eingesetzt. Dazu kann ich deshalb nichts sagen. Antispam Bee blockiert in der Standardeinstellung automatische Spam-Kommentare. Diesbezüglich zitiere ich mal aus der Dokumentation von Antispam Bee:

  Im Auslieferungszustand entfernt Antispam Bee jeden Spam-Kommentar, ohne dies irgendwo zu notieren. Diese Vorgehensweise hat den wesentlichen Vorteil, dass sich keine Liste mit Spam-Einträgen bildet, die in bestimmten Abständen zeitintensiv und mühselig kontrolliert und geleert werden muss.

• 15. März 2010, Thomas Scholz schreibt: @Dieter: Das kann aber auch ein Nachteil sein, denn ein Versehen kann man dann nicht mehr korrigieren. Ich würde die rabiate Methode des unkontrollierten Löschens nur benutzen, wenn täglich so viel Spam einschlägt, daß eine manuelle Kontrolle ohnehin nicht mehr zu bewältigen ist. Nur dann. Einmal am Tag 50—100 Spamkommentare zu überfliegen, halte ich noch für vertretbar.
• 15. März 2010, Dieter schreibt: @Thomas Wie Du der Grafik in meinem Blogbeitrag "Spamschutz nur mit Antispam Bee" entnehmen kannst, habe ich den Haken bei Spam markieren, nicht löschen gesetzt. Ich teile Deine Einschätzung, dass die rabiate Methode des unmittelbaren automatischen Löschens nur in Ausnahmefällen gewählt werden sollte. Über 50 Spam-Kommentare an einem Tag sind bisher auf Webseiten-Infos.de die absolute Ausnahme. Unabhängig davon untersuche ich gerne kurz die Spam-Kommentare hinsichtlich irgendwelcher Auffälligkeiten (insbesondere IP-Adressen sowie User Agent mit chCounter).
• 11. November 2010, Robert schreibt: Danke für den Hinweis mit der htaccess. Denn immer wieder fallen Bots auf, die sich nicht an die robots.txt halten. Bislang habe ich es immer mit der IP versucht, was aber einerseits nur begrenzt funktionierte und andererseits auch "echte" Besucher blockierte. Die htaccess-Lösung scheint soweit ganz gut zu funktionieren und ist perfekt ergänzbar.
• 12. November 2010, Dieter schreibt: @Robert Gern geschehen. Mit der htaccess-Datei kann man viel machen. Schade nur, dass ich bisher keine umfassende Einführung hierzu gefunden habe.

Ähnliche Beiträge

• Neues Layout für Handy und PDA
• iPhone-Simulatoren sind für die Tonne!
• Google +1 blockieren
• Video: Willkommen bei Facebook
• Spam-Schutz auf Webseiten-Infos.de

Permalink | 14 Kommentare | Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena
Schlagwörter: .htaccess, IP-Adresse, robots.txt, User Agent, Webseiten

1. WordPress-Plugins
   1. Akismet
   2. Antispam Bee
   3. Simple Trackback Validation
   4. SpamViewer
2. Spam-Schutz mittels Einstellungen von WordPress
3. Spam-Schutz via .htaccess
   1. IP-Adressen aussperren
   2. User-Agent blockieren
4. Mein persönliches Fazit

1. Spam-Schutz durch WordPress-Plugins

Angeregt durch toscho möchte ich – wie Micha, Frank Bültge, Dominik (ocean90), Helmut Pozimski, Marco Döhring und toscho selbst – meine eingesetzten Maßnahmen zum Schutz vor Spam vorstellen.

Diese Maßnahmen setze ich nicht nur auf Webseiten-Infos.de, sondern auch auf allen meinen und von mir technisch betreuten WordPress-Installationen ein. Das sind derzeit insgesamt vier WordPress-Websites.

Dabei versuche ich mich aus Gründen der Vergleichbarkeit, Bequemlichkeit und weil ich die von toscho vorgeschlagenen Kriterien gut finde, daran zu orientieren.

Soweit die oben genannten Blogbeiträge aber Ausführungen enthalten, die hierher passen, erlaube ich mir zu zitieren oder darauf zu verlinken. Zugänglichkeitsprobleme durch meine Maßnahmen zum Schutz vor Spam sind mir nicht bekannt. Allerdings setze ich auch keinen Captcha bei der Kommentarfunktion ein.

Zum Schutz vor Spam setzte ich folgende vier WordPress-Plugins ein:

1. Akismet von Automattic
2. Antispam Bee von Sergej Müller
3. Simple Trackback Validation von Michael Wöhrer
4. SpamViewer von Frank Bültge

Hierauf sowie Spam-Schutz mittels Einstellungen von WordPress und via .htaccess-Datei gehe ich nachfolgend ein.

1.1. Akismet

Akismet wird mit WordPress automatisch mitgeliefert.

Es ist für den persönlichen Gebrauch kostenlos. Betreibst Du jedoch ein Blog, mit dem Du mehr als 500 US-Dollar pro Monat generierst oder das zu einem großen Unternehmen gehört, dann kostet Akismet und gibt es dafür einen kommerziellen API-Schlüssel.

Auch für den persönlichen Gebrauch benötigst Du zum Einsatz dieses Plugins einen WordPress.com-API-Schlüssel, der im Administrationsbereich (Backend) unter Plugins > Akismet-Konfiguration eingetragen werden muss. Diesen bekommst Du über den Link http://en.wordpress.com/api-keys/.

Akismet lernt von den Erfahrungen der Nutzer. Allerdings werden dazu Daten eingehender Kommentare und Trackbacks an den Server von Akismet in den USA gesandt. Aus diesem Grunde habe ich einen Hinweis hierauf in die Datenschutzerklärung von Webseiten-Infos.de aufgenommen.

Lesenswert in diesem Zusammenhang ist der Blogbeitrag “Akismet in WordPress: Ist die Nutzung in Deutschland rechtmäßig?” von Sergej Müller.

Meine persönliche Meinung ist, dass die Nutzung von Akismet in Deutschland rechtmäßig ist. Voraussetzung dafür ist, dass potentielle Kommentatoren die Möglichkeit haben, vor dem Absenden eines Kommentars von der Datenübermittlung an den Server zum Spam-Schutz Kenntnis zu erlangen und insoweit ihre Meinung, ob sie gleichwohl kommentieren wollen, zu überdenken.

Deshalb gibt es auf Webseiten-Infos.de bei Kommentar schreiben den Link zur Datenschutzerklärung.

Akismet gibt im Administrationsbereich (Backend) unter Dashboard > Akismet-Statistiken Aufschluss über das Spam-Aufkommen in der eigenen WordPress-Installation.

Webseiten-Infos.de ist seit Februar 2009 online und weist durch Akismet aktuell folgende Statistik aus:

• Bisher 5.339 Spams (spam detected) und 560 echte Kommentare (ham detected), also eine Spam-Quote von etwa 90%.
• Die Erkennungsrate von Spam durch Akismet liegt hier aktuell bei 99,424%.
• 24 Spam-Kommentare hatte Akismet auf Webseiten-Infos.de bislang nicht selbst erkannt und mussten von mir manuell als Spam gekennzeichnet werden (missed spam).
• 10 echte Kommentare auf Webseiten-Infos.de wurden von Akismet fälschlicherweise als Spam eingestuft (false positive).
• Bisher war April 2009 mit 850 Spam-Kommentaren der Monat mit dem höchsten Aufkommen und November 2009 mit 239 Spam-Kommentaren der Monat mit dem geringsten Aufkommen an Spam.
• Tendenziell und erfreulicherweise scheint auf Webseiten-Infos.de die Anzahl der Spam-Kommentare rückläufig zu sein.

Wünschenswert ist aus meiner Sicht bei Akismet das Beifügen eines Musters einer Datenschutzerklärung.

Im Übrigen verweise ich auf den Abschnitt zu Akismet im lesenswerten Blogbeitrag “Spam verhindern mit Akismet und .htaccess” von Thomas Scholz aka toscho.

1.2. Antispam Bee

Hierüber haben hat bereits Micha in seinem lesenswerten Blogbeitrag “Antispam Bee – Meine WordPress Antispam Lösung” und Dominik (ocean90) in seinem ebenfalls lesenswerten Blogbeitrag “Biene versus Spam oder mit Antispam Bee dem Spam entkommen” geschrieben. Außerdem gibt es den informativen Blogbeitrag “Antispam Bee: Das WordPress-Plugin für den Schutz gegen Spam” von Sergej Müller in seinem Blog zu seiner Antispam-Lösung.

Deshalb hier nur kurz ergänzend der Hinweis auf meinen Blogbeitrag “Antispam Bee: Einstellungen geändert“. Dort erkläre ich, warum ich hier auf Webseiten-Infos.de bei den Einstellungen von Antispam Bee das Häckchen für “Spam markieren, nicht löschen” setzte / setzen musste.

Von Vorteil wäre es für mich, wenn Antispam Bee auch beim Einsatz der Kommentarfunktion in den Templates für die Suche (search.php) und Archive (archive.php) richtige Kommentare erkennen, also nicht als Spam ansehen würde.

Nachtrag vom 14. Februar 2010:
Sergej führte mit der Version 1.3 bei Antispam Bee die Option “Kommentare finden auch außerhalb von Beiträgen Verwendung” ein. Damit hat er mir einen ganz großen Gefallen getan. Durch das Häckchen bei dieser Option werden richtige Kommentare auch erkannt, wenn sie bei einem Suchergebnis oder einer Archivseite getätigt wurden.

1.3. Simple Trackback Validation

Dieses Plugin löscht Spam Trackbacks indem es überprüft, ob

1. die IP-Adresse des Trackback-Absenders mit der IP-Adresse des Servers der Trackback-URL übereinstimmt und
2. die Webseite, von welcher die Trackback-URL kommt, in dem Trackback verwendet wird und diese Webseite einen Link zu meiner WordPress-Seite beinhaltet.

Ich entnehme der Beschreibung der Funktionalität des Plugins Antispam Bee, dass auch dieses Plugin Trackbacks auf diese Art und Weise auf Spam überprüft.

Testweise habe ich deshalb mal das Plugin Simple Trackback Validation deaktiviert. Sollte das Plugin Antispam Bee für das Zurückhalten von Trackback-Spam ausreichen, werde ich Simple Trackback Validation endgültig “in Rente schicken”.

1.4. SpamViewer

Streng genommen handelt es sich bei diesem WordPress-Plugin nicht um eine Maßnahme, die vor Spam schützt, sondern eine Hilfsmittel um die MySQL-Datenbank sauber zu halten. Unter anderem die Funktionalität Löschen von Spam-Kommentaren aus der MySQL-Datenbank stellt übrigens auch das Plugin WP-Optimize zur Verfügung.

SpamViewer “kann die falschen Einträge retten und unnötige Einträge in der Datenbank löschen, um diese klein zu halten.” Zugegebenermaßen habe ich dieses Plugin bisher wohl kaum genutzt. Im Dashboard des Administrationsbereichs (Backend) von WordPress kann ich über die eingeblendete Option “Aktuell” auch die als Spam angesehenen Kommentare aufrufen und dann endgültig Löschen, Bearbeiten oder doch Freigeben.

Ich habe deshalb dieses Plugin deaktiviert. Sieht so aus als ob ich es nicht (mehr) brauche.

Ein netter Nebeneffekt der Umfrage von Thomas ist also, dass ich dadurch auf nicht (mehr) benötigte Plugins aufmerksam wurde. Danke dafür!

2. Spam-Schutz mittels Einstellungen von WordPress

Neben Plugins habe ich aber auch WordPress so eingestellt, dass Kommentar-Spam erst überhaupt nicht in meinem Blog veröffentlicht wird. Dazu habe ich im Administrationsbereich (Backend) folgende Optionen unter Einstellungen > Diskussion ausgewählt:

Häckchen gesetzt bei

• Benutzer müssen zum Kommentieren Name und E-Mail-Adresse hinterlassen und
• bevor ein Kommentar erscheint, muss der Autor bereits einen genehmigten Kommentar geschrieben haben.

Darüber hinaus habe ich dort festgelegt, dass ein Kommentar in die Warteschlange zu schieben ist, wenn er mehr als 1 Link enthält (Eine hohe Anzahl von Links ist ein typisches Merkmal von Kommentar-Spam.).

Warum habe ich diese Einstellungen gewählt?

Nun, leider nahm die Zahl manueller SEO-Kommentare mit Keyword-Spam auf Webseiten-Infos.de in den letzten Monaten zu. Diesen Spam können die o.g. Plugins regelmäßig nicht automatisch herausfiltern.

Mein Eindruck ist, dass hier insbesondere unseriöse Webdesigner und Agenturen versuchen das Ranking von Kundenseiten durch Rückverweise (Backlinks) mittels solcher SEO-Kommentare in Blogs zu verbessern. Einige Seiten von Webseiten-Infos.de dürften da auch angesichts eines guten PageRanks sowie guter SERPs besonders beliebte Ziele von SEO-Spammern sein.

Natürlich würde ich gerne darauf verzichten, Erstkommentare und Kommentare mit einem Link oder mehreren Links erst nach Freischaltung erscheinen zu lassen. Gegenüber dem Einsatz eines Captcha halte ich das aber für die benutzerfreundlichere und zugänglichere Variante. Sobald ich den ersten Kommentar freigeschaltet habe, erscheinen dann weitere Kommentare direkt.

Letztendlich werden also manuelle Kommentare von mir manuell dahingehend geprüft, ob es sich um SEO-Spam handelt. Komme ich zu der Einschätzung SEO-Spam, dann

• entferne ich den Link und / oder
• ändere den Namen in Name-gelöscht oder
• markiere den Kommentar für Akismet als Spam und lösche ihn (siehe hierzu auch meinen Blogbeitrag “Kommentar-Spam bekämpfen“).

Im Übrigen denke ich aktuell darüber nach, den Text zum Eingabefeld Namen für Kommentare in nächster Zeit noch um den Hinweis “kein SEO” zu ergänzen.

3. Spam-Schutz via .htaccess

1. IP-Adressen aussperren

Meine .htaccess-Datei enthält Zugangsblockaden für besonders häufig auftretende IP-Adressen von Spammern und eine Browserkennung (User Agent).

Leider kommen die meisten Spam-Kommentare über verschiedene, sprich ständig wechselnde IP-Adressen. Da artet das Sperren von IP-Adressen zum Hase/Igel-Wettrennen aus.

Andererseits gibt es gelegentlich doch so dumme Spammer, die immer über dieselbe IP-Adresse ihren Drecks-Kommentar absetzen. Hiergegen hilft dann die Zugangssperre via .htaccess-Datei.

Zur Veranschaulichung hier ein Auszug aus meiner .htaccess-Datei:

Bei Thomas Scholz gibt es in seinem Blogbeitrag “Spam verhindern mit Akismet und .htaccess” übrigens weitere lesenswerte Hinweise auf den Einsatz der .htaccess-Datei zum Sperren von IP-Adressen.

2. User-Agent blockieren

Erstaunlicherweise erfolgte bereits mehrmals eine regelrechte Attacke mit SEO-Spam auf Webseiten-Infos.de. Leider erfolgte jeder Angriffsversuch von einer anderen IP-Adresse. Gut, dass Antispam Bee diesen Spam erkannte. Ärgerlich war jedoch, dass das deutlich die Besucherstatistik verfälschte und Serverkapazitäten beanspruchte.

Da bei diesen Spam-Attacken alle Zugriffe aber mit dem gleichen User Agent (UA) erfolgte und ich ansonsten keinen nennenswerten Gebrauch dieses User Agent (UA) feststellen konnte, bekommen Besucher mit diesem User Agent (UA) keinen Zugang mehr zu Webseiten-Infos.de.

Auch dies habe ich mittels einer Ergänzung meiner .htaccess-Datei realisiert. Hier der Auszug aus der .htaccess-Datei:

Im Bedarfsfalle beabsichtige ich meine .htaccess-Datei um entsprechende Einträge zu erweitern.

4. Mein persönliches Fazit

• Die Idee von Thomas Scholz aka toscho, dass wir mal über die Mittel bloggen sollten, mit denen wir unsere Website gegen Spam schützen, kam genau zur richtigen Zeit. Ein solcher Blogbeitrag war auf Webseiten-Infos.de überfällig.
• Lässt doch der Informationsaustausch über eingesetzte Schutzmaßnahmen gegen Spam bisher zu wünschen übrig, ist also verbesserungsfähig und -bedürftig.
• Dank der Beschäftigung mit meinen Maßnahmen zum Schutz gegen Spam im Rahmen dieses Blogbeitrags konnte ich zwei Plugins einsparen.
• So wie es derzeit aussieht, werde ich wohl in Zukunft weiterhin auf Akisment und Antispam Bee als Plugins setzen.
• Darüber hinaus werde ich wohl auch meine Einstellungen von WordPress zum Kommentieren weiterhin so belassen.
• Die .htaccess-Datei werde ich schließlich im Bedarfsfalle weiter ergänzen.
• Ich hoffe, dieser doch längliche Blogbeitrag hilft dem einem oder anderen Betreiber von Webseiten und insbesondere WordPress-Nutzern bei der erfolgreichen Bekämpfung von Spam.

Fehlerhinweise und Anmerkungen nehme ich gerne jederzeit entgegen.
Die Kommentarfunktion steht dazu zur Verfügung.

Kommentare

• 15. Januar 2010, Sergej Müller schreibt: Vielen Dank für die ausführliche Zusammenfassung und die Empfehlung meiner Antispam Bee. Ich habe lange überlegt, ob das Plugin auch Archivseiten unterstützen soll, aber da scheinbar dieser Anwendungsfall kaum Verwendung findet, habe ich mir die Mühe gespart. (Auch bei dir wird in den Cats kaum bis gar nicht kommentiert) ;)
• 15. Januar 2010, Antispam Bee – Meine WordPress Antispam Lösung - Antispam, Spam, Akismet, Spamkommentare, Plugin, Lösung - dynamicinternet schreibt: [...] Dieter Welzel: Spamschutz auf Webseiten-Infos.de [...]
• 16. Januar 2010, Ute schreibt: Gewohnt gut, da kann ich mir einen Artikel sparen. ;) Ich setze Akismet und Simple Trackback Validation ein. Der Hinweis auf Name nicht Keyword scheint nur selten zu helfen, ich ändere dann kommentarlos in "ohne_namensnennung". Bislang fing Akismet 26.057 Spams auf uteles Blog mit einer Genauigkeit von 99.864% und 13.609 auf miradlo bloggt mit 99.851% Funktionsfähig ist Akismet schon, aber mich stört noch immer, dass es ein zentraler Dienst ist.
• 16. Januar 2010, Dieter schreibt: @Sergej Dein Plugin Antispam Bee finde ich wie alle Deine mir bekannten Plugins, und das sind fast alle, einfach klasse. Dass ich auf Webseiten-Infos.de WordPress gegenüber den Standardeinstellungen stark modifiziert habe, ist für einige kleine Probleme ursächlich. Und in der Tat, Kommentare über die Archivseiten kommen wohl selten vor. Es hat jedenfalls lange gedauert, bis ich mal auf einen automatisch gelöschten Kommentar hingewiesen wurde. Gleichwohl wäre es für mich bequem, wenn Antispam Bee auch bei Archiv- und Suchergebnisseiten Spam-Kommentare automatisch löschen und es dabei nicht zu false positive kommen würde. Hilfreich wäre für so "WP-Bastelfreaks" wie mich, wenn dazu ein gut platzierter Hinweis in der Anleitung zu Antispam Bee zu finden wäre. Dann weiß der Nutzer, dass er in solchen Fällen Antispam Bee besser nur mit Häckchen setzen bei "Spam markieren, nicht löschen" nutzt. @Ute Danke! Das geht runter wie Öl. :freu: Und wow, bei Dir hat Akismet ja schon richtig heftig viel Spam abgefangen. Zudem ist die Erkennungsquote für Spam noch höher. Auch ich bin nicht glücklich darüber, dass Akismet ein zentraler Dienst ist. Ich bevorzuge Unabhängigkeit von externen Diensten bei meinen Webpräsenzen. Jedoch habe ich den Eindruck, dass die Kombination von zentralem (Akismet) und lokalem Spam-Schutz (Antispam Bee) zu den besten Resultaten und zum geringsten Aufwand für den Betreiber führt. So aus dem Stehgreif fallen mir nur folgende drei externe Dienste ein, die ich auf Webseiten-Infos.de einsetze: - Akismet vom WordPress-Entwickler Automattic - Gravatar ebenfalls von Automattic - Google Maps von Google Das Thema Pro und Contra für die einzelnen externen Dienste ist auch mal den einen oder anderen Blogbeitrag wert. ;-)
• 16. Januar 2010, Sergej Müller schreibt: Morgen Dieter. In der Antispam Bee Anleitung wird auch empfohlen, "nach der Inbetriebnahme des Plugins sind die Kommentarfelder auf korrekte Funktionsweise zu kontrollieren". Da müsste dir auffallen, dass auf Archivseiten etwas nicht stimmt ;) Ich könnte die Unterstützung für Archivseiten und die Suche in einem Befehl implementieren - eine Zeile genügt. Allerdings denke ich dabei an die Nutzer, die Formulare nur in Beiträgen einsetzen - da wird Antispam Bee allerdings vergeblich nach dem Kommentarformular in den Kategorien etc. suchen (was an sich nicht schlimm ist, kostet nur unnötig Performance). Vielleicht als Option? Aber danke für den Hinweis, ich werde die Anleitung am einen Satz erweitern und Menschen darauf hinweisen. Nutzer-Feedback wie deins hier ist immer goldwert. Merci.
• 16. Januar 2010, Dieter schreibt: Morgen Sergej,

  Vielleicht als Option?

  Das fände ich geil! Entschuldigung für den sprachlichen Ausrutscher, ich meine natürlich toll. Allerdings muss ich zugeben, dass ich keine Ahnung habe, inwieweit andere WordPress-Nutzer entsprechende Änderungen an der archive.php und search.php vornehmen.

  Aber danke für den Hinweis, ich werde die Anleitung am einen Satz erweitern und Menschen darauf hinweisen. Nutzer-Feedback wie deins hier ist immer goldwert. Merci.

  Den Dank muss und möchte ich gerne zurückgeben. Deine Plugins sind einfach genial.
• 19. Februar 2010, wp-popular.com » Blog Archive » Spam-Schutz auf Webseiten-Infos.de | Webseiten-Infos.de schreibt: [...] more: Spam-Schutz auf Webseiten-Infos.de | Webseiten-Infos.de Tags: antispam, [...]
• 5. Dezember 2010, Peter schreibt: Herzlichen Dank für den super Beitrag! Hat mir sehr weitergeholfen :)
• 5. Dezember 2010, Dieter schreibt: @Peter Freut mich. Ebenfalls hilfreich in diesem Zusammenhang: Hinweise für Kommentare und Kommentar-Spam bekämpfen. ;-)
• 21. Dezember 2011, Empfehlenswerte externe Dienste | Webseiten-Infos.de schreibt: [...] Akismet zum Schutz vor Spam im Zusammenspiel mit dem WordPress-Plugin Akisment von Automattic (siehe hierzu meinen Blogbeitrag “Spam-Schutz auf Webseiten-Infos.de“) [...]
• 21. Dezember 2011, Spamabwehr mit Antispam Bee | Webseiten-Infos.de schreibt: [...] bekämpfen“, “Antispam Bee: Einstellungen geändert“, “Spam-Schutz auf Webseiten-Infos.de” und “Spamschutz nur mit Antispam [...]

Ähnliche Beiträge

• Spamschutz nur mit Antispam Bee
• Spamabwehr mit Antispam Bee
• Hinweise für Kommentare
• Kommentar-Spam bekämpfen
• Kostenlose Backlinks im Internet?

Permalink | 11 Kommentare | Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena
Schlagwörter: .htaccess, Akismet, Antispam Bee, Captcha, Einstellungen, Kommentar-Spam, Mathetest, Simple Trackback Validation, Spam, Spam-Schutz, WordPress

• die Blogbeiträge “Unfreiwillig zurückgesetztes Administratorpasswort” von WordPress-Deutschland.org und
• “WordPress 2.8.3: Admin password reset exploit – schwere Sicherheitslücke” von Caschy sowie
• den Artikel “Lücke in WordPress ermöglicht Aussperren des Admins [Update]” bei heise.de

bin ich darauf aufmerksam geworden, dass bei WordPress schon wieder eine Sicherheitslücke entdeckt wurde.

Erfreulicherweise ist diese Sicherheitslücke nicht kritisch. Nur wenn ein Dritter Zugang zu Deinem Postfach hat und mit einem Exploit Dein Administrationspasswort zurücksetzt, könnte er sich Zugang zum Administrationsbereich Deiner WordPress-Installation verschaffen.

Sofern Du bereits das Verzeichnis wp-admin Deiner WordPress-Installation mit einem .htaccess-Passwortschutz versehen hattest oder noch besser lediglich die Datei wp-login.php im Rootverzeichnis, bist Du vor dem Exploit, also dem Zurücksetzen des Administrationspasswortes durch Dritte, hinreichend geschützt.

Solltest Du das Verzeichnis wp-admin mit einem .htaccess-Passwort (.htpasswd) schützen, gibt es Probleme mit Plugins, die Mailbenachrichtigungen bei weiteren Kommentaren ermöglichen (Subscribe to Comments). Näheres hierzu im Blogbeitrag “WordPress-Login absichern – zweite Variante” von Caschy.

Deshalb sei hier der .htaccess-Schutz für die Datei wp-login.php im Rootverzeichnis empfohlen (siehe hierzu auch Tipp 7 des insgesamt lesenswerten Blogbeitrags “Sicherheit in WordPress: 10 Schritte zum Schutz des Admin-Bereichs” von Sergej Müller).

Wer keinen Zugriff auf die .htaccess-Datei hat, dem sei als Alternative der Fix im Blogbeitrag “Unfreiwillig zurückgesetztes Administratorpasswort” von WordPress-Deutschland.org nahegelegt.

Und wieder hatte ich das Glück, dass mich eine Sicherheitslücke von WordPress nicht betraf. Diesmal hatte ich aufgrund einer netten Nachfrage und eines hilfreichen Hinweises von Sergej bereits den Schutz des Verzeichnisses wp-admin durch den .htaccess-Passwortschutz der Datei wp-login.php ersetzt. Danke dafür!

Kommentare

• 11. August 2009, Ute schreibt: Wenn du die wp-login per .htaccess nochmal absicherst, brauchst zum Einloggen jedoch zwei Passwörter, das für die .htaccess und das für WP, oder stehe ich jetzt auf der Leitung?
• 12. August 2009, Dieter schreibt: @Ute Das hast Du völlig richtig erkannt. :-) Damit macht diese Lösung natürlich etwas Mehrarbeit. Aber: Wenn wenn Du Dich über einen sicheren Rechner, also etwa Deinen eigenen Computer einloggst, dann kannst Du im Normalfall Deinem Browser gestatten sich die Daten für beide Passwörter zu merken. Dann brauchst Du die Anmeldung über die .htaccess- und .htpasswd-Datei sowie das WordPress-Loggin über die Datei wp-login.php nur einmal zu machen. Auf öffentlichen Computern wie in einem Internetcafe ist dagegen vom Speichern der Passwörter abzuraten.
• 21. Dezember 2011, Webseiten-Infos.de auf WordPress 2.8.4 aktualisiert | Webseiten-Infos.de schreibt: [...] Zum vorherigen Beitrag [...]

Ähnliche Beiträge

• Webseiten-Infos.de auf WordPress 2.8.4 aktualisiert
• Firefox 3.5.3 steht zum Download bereit
• Kritische Sicherheitslücke in WordPress
• HTML-Kommentare von WordPress-Plugins entfernen
• Little Boxes Teil 0 von Peter Müller

Permalink | 3 Kommentare | Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena
Schlagwörter: .htaccess, Administrationspasswort, Fix, Sicherheitslücke, WordPress

Die schlechte Nachricht:

Sie betrifft anscheinend alle Versionen von WordPress einschließlich der aktuellen Version 2.8.2.

Die guten Nachrichten:

• Sie ist nur für Betreiber von WordPress-Installationen relevant, bei denen Dritte als registrierte Benutzer (die Rolle “Abonnent” mit den wenigsten Rechten reicht schon) existieren und/oder angelegt werden können. Das ist beispielsweise der Fall, wenn sich Dritte zum Kommentieren registrieren müssen.
• Thomas Scholz aka toscho hat bereits einen Fix zum Schließen dieser Sicherheitslücke entwickelt. Ob WordPress-Deutschland.org will die sichere Variante dieses Fixes erst öffentlich zugänglich machen, wenn es eine entsprechende Reaktion der Entwickler gibt (siehe hierzu den Kommentar von toscho und von den Kommentar von Olaf). Wie toscho plädiere ich für die transparente Methode. Schließlich ist der Code von WordPress auch frei zugänglich und ist gerade dies einer der Stärken von Open-Source-Software. Aber auch die Argumentation von Olaf mit der Veröffentlichung zu warten ist nachvollziehbar.

Meine Empfehlung:

Wer also bei seiner WordPress-Installation Dritten wie etwa Besuchern die Registrierung erlaubt, sollte

• diese Abschalten und unbekannte, bereits registrierte Benutzer vorsorglich löschen und/oder
• das Verzeichnis wp-admin seiner WordPress-Installation temporär mit einem vollständigen .htaccess Schutz versehen und/oder
• den Fix von toscho einsetzen,

um diese Sicherheitslücke zu schließen.

Danke an

• das Forenmitglied illifly für das Berichten über die Sicherheitslücke,
• Olaf Baumann aka jottlieb für den Blogbeitrag bei WordPress-Deutschland.org dazu und
• toscho für das Entwickeln eines Fix um die kritische Sicherheitslücke zu schließen.

Mein Fazit:

• Ich habe Glück gehabt, denn meine Blogs kennen nur mich als registrierten Benutzer. Kommentatoren müssen sich bei mir nicht registrieren. Damit darf ich trotz dieser kritischen Sicherheitslücke gelassen bleiben.
• Bleibt zu hoffen, dass mit der nächsten WordPress-Version (2.8.3?) diese kritische Sicherheitslücke auch offiziell geschlossen wird.
• Die häufig auftretenden und festgestellten Sicherheitslücken sprechen nicht für WordPress. Andererseits werden diese aufgrund seiner starken Verbreitung oft sehr schnell gefunden und geschlossen. Dies spricht wiederum für WordPress.

Nachtrag vom 4. August 2009:

Die Entwickler haben schnell reagiert und die Version 2.8.3 veröffentlicht (siehe hierzu auch meinen Blogbeitrag “Webseiten-Infos.de auf WordPress 2.8.3 aktualisiert“). Das Update hierauf ist aus Sicherheitsgründen zu empfehlen.

Wer aufgrund des höheren PHP-Speicherbedarfs nicht auf WordPress 2.8.x aktualisieren kann (siehe hierzu meinen Blogbeitrag “Ursache des enormen Speicherbedarfs gefunden!“), behält die kritische Sicherheitslücke. Für diese Fälle gelten meine oben gemachten Empfehlungen weiterhin.

Nachtrag vom 8. August 2009:

Toscho hat in seinem Blogbeitrag “WordPress 2.8.3: Das Doppelslash-Problem” eine PHP-Lösung veröffentlicht, die auch mit älteren WordPress-Versionen funktioniert und zudem weitere Probleme löst. Einfach den im seinen Blogbeitrag veröffentlichten PHP-Code in die functions.php des aktiven Themes kopieren.

Darüber hinaus macht er darauf aufmerksam, dass mehrfache Slashes // in der URL nicht nur Probleme bei WordPress bereiten.

Dank Markus Wulftange aka Gumbo stellt er in seinem Blogbeitrag auch noch eine Lösung mittels (Ergänzung der) .htaccess-Datei und mod_rewrite vor (muss in der .htaccess-Datei vor der PERISHABLE PRESS 4G BLACKLIST stehen, sofern vorhanden, und die Zeile “RedirectMatch 403 \/\/”dieser Blacklist auskommentiert werden).

Funktioniert auf dieser Webpräsenz übrigens einwandfrei.

Das sollte bei allen Anwendungen helfen. Die (Ergänzung der) .htaccess ist die bessere Alternative. Wenn sie bei Dir funktioniert (testen!), dann brauchst Du die functions.php des aktiven WordPress-Themes nicht zu ergänzen.

Kommentare

• 21. Dezember 2011, Webseiten-Infos.de auf WordPress 2.8.3 aktualisiert | Webseiten-Infos.de schreibt: [...] Zum vorherigen Beitrag [...]
• 21. Dezember 2011, WordPress: Wider dem Katastrophen-Gerede | Webseiten-Infos.de schreibt: [...] hierzu meine Blogbeiträge “Angriffe auf alte WordPress-Installationen” und “Kritische Sicherheitslücke in WordPress“) und Weiterentwicklungen häufig Aktualisierungen (Updates), die möglichst zeitnah [...]

Ähnliche Beiträge

• Update auf Firefox 3.6.3 empfohlen!
• Kritische Sicherheitslücke in Safari geschlossen
• Webseiten-Infos.de auf WordPress 2.8.3 aktualisiert
• Update auf Firefox 3.6.2 empfohlen!
• Firefox 3.0.8 schließt zwei Sicherheitslücken

Permalink | 2 Kommentare | Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena
Schlagwörter: .htaccess, Fix, functions.php, mehrfache Slashes, PHP, Registrierung, Sicherheitslücken, WordPress

Das ist nicht verwunderlich. WordPress ist sehr verbreitet und leicht zu installieren. Aber mit der automatischen Standardinstallation sind auch einige Schwachpunkte verbunden, die Du beseitigen solltest, damit es Hacker nicht (zu) leicht haben.

Bereits mit der Installation von WordPress solltest Du möglichst das Präfix für die Tabellen ändern. Deshalb empfehle ich Dir vorab das Whitepaper (pdf-Datei, 685 kB) von Blogsecurity.net zu lesen. Über eine Twitternachricht von Blogsecurity bin ich zudem auf dieses Video “10 Tips To Make WordPress Hack-Proof” zu diesem Whitepaper auf guvnr.com aufmerksam geworden:

Hier noch ein paar Links zu WordPress-Plugins, welche helfen das Sicherheitsniveau von WordPress zu verbessern:

• WP-Antivirus von Sergej Müller
  (siehe hierzu auch meinen Blogbeitrag “Antivirus-Plugin verbessert Sicherheit” und die alte Website für das Plugin)
• WP Security Scan von Michael Torbert
  (läuft leider hier nicht, aber bei meinem privaten, von one.com gehosteten Blog unter www.dieter-welzel.de/blog/)
• Limit Login Attempts von Johan Eenfeldt
• Secure WordPress von Frank Bültge
• WP Scanner von Blogsecurity

Und zu guter Letzt noch ein paar weiterführende Links zu dem Thema:

• Sicherheit / WordPress absichern von Michael Weingärtner
• WordPress sicherer machen von Frank Bültge
• WordPress Plugins für mehr Sicherheit von Frank Bültge
• WordPress sicherer machen ::: ohne den sonst existierenden admin von Ute Hauth
• Sicherheit in WordPress: 10 Schritte zum Schutz des Admin-Bereichs von Sergej Müller
• …wieder mal Sicherheit ::: WordPress und Plugins ohne Versionsnummern von Ute Hauth
• Ungebetene Gäste mit .htaccess blocken von Thomas Scholz
• .htaccess: Angriffe sehen und blockieren von Thomas Scholz
• The Perishable Press 4G Blacklist von Jeff Star
• 13 Vital Tips and Hacks to Protect Your WordPress Admin Area auf wpbeginner.com

Kommentare

• 25. Mai 2009, the_guv schreibt: Ich bin Sie mögen mein Tutorium und Video erfreut... "Video How-to: 10 Tips To Make WordPress Hack-Proof " Bitte beachtet, dass es viel mehr Detail auf dem ursprünglichen Artikel. gibt.. http://www.guvnr.com/web/blogging/10-tips-to-make-wordpress-hack-proof/ ... Plus mehr WordPress und hat Tutorien an meinem Blog guvnr erzählt. com. the_guv
• 28. Mai 2009, Sebastian schreibt: Danke für die vielen hilfreichen Tipps und Links, ich werd mich da jetzt erstmal durcharbeiten. besonders das Vid mit den 10 Tipps ist ziemlich hilfreich!
• 28. Mai 2009, Dieter schreibt:

  Danke für die vielen hilfreichen Tipps und Links

  Bitte schön, gern geschehen! :-)

  ich werd mich da jetzt erstmal durcharbeiten.

  Kann ich nur empfehlen und Du solltest Dich auch damit beeilen. Der Login vom Blog zeigt mir an, dass der User admin besteht und eine maximale Anzahl von Loginversuchen ist auch noch nicht sichergestellt! Zudem kann ich aus dem Quelltext direkt ersehen, dass WordPress 2.7.1 im Einsatz ist. Ich habe deshalb mal vorsorglich den Link zu Deinem Blog rausgenommen, sonst wissen die Hacker gleich wo sie besonders leicht einbrechen können. ;-) Am Rande noch der Hinweis, dass 16 Validierungsfehler auf der Startseite des Blogs kein Qualitätsmerkmal sind (siehe hierzu auch meinen Artikel "Was macht eine gute Webpräsenz aus?"). :!:
• 21. Dezember 2011, Angriffe auf alte WordPress-Installationen | Webseiten-Infos.de schreibt: [...] jeden Fall Deinen Administrationsbereich sicherer machen (siehe hierzu meinen Blogbeitrag “Sicherheit von WordPress verbessern” und insbesondere den Blogbeitrag “Sicherheit in WordPress: 10 Schritte zum Schutz des [...]

Ähnliche Beiträge

• Angriffe auf alte WordPress-Installationen
• BSI warnt vor Internet Explorer
• Die 10 größten Web-Security-Mythen
• WordPress: Wider dem Katastrophen-Gerede
• Spamschutz nur mit Antispam Bee

Permalink | 4 Kommentare | Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena
Schlagwörter: .htaccess, Admin, Blogsecurity, Plugins, Sicherheit, WordPress

Beispiel: http://www.webseiten-infos.de und http://webseiten-infos.de

Grundsätzlich ist das positiv zu bewerten, dass ein Besucher über beide Wege zu Deiner Website findet.

Unter dem Gesichtspunkt der Suchmaschinenoptimierung (Search Engine Optimization (SEO)) gibt es damit aber Probleme.

Grund: Für Suchmaschinen wie Google handelt sich bei diesen beiden Varianten um unterschiedliche URLs, die aber denselben Inhalt zeigen. Zudem verteilen sich dann die Backlinks, das sind die Links, die von anderen Webseiten auf diese Webseite gesetzt werden, auf diese beiden URLs, so dass die Linkpower sich verteilt, statt auf eine Webseite zu konzentrieren.

Dieses Problem des scheinbaren doppelten Inhalts (Double Content, Duplicate Content) kannst Du vermeiden, wenn Du einen Webserver hast der mod_rewrite unterstützt. Dazu musst Du die eine Variante mithilfe eines 301 Moved Permanently-HTTP-Headers auf die andere URL umleiten.

Welche Variante dabei sinnvollerweise auf die andere Variante umgeleitet werden soll, ist Deine Entscheidung. Darüber lässt sich trefflich streiten.

Ich persönlich bevorzuge die Variante mit dem www-Präfix. Es hat sich nach meiner unmaßgeblichen Meinung (IMHO) einfach eingebürgert Webseiten mit dem www-Präfix zu nennen und auch zu schreiben. So fällt mir auf, dass auf Autos oft für Webseiten mit vorangestelltem www geworben wird.

Damit der mod_rewrite aktiv wird, musst Du die .htaccess-Datei in dem Stammverzeichnis (Wurzelverzeichnis, Root-Verzeichnis) Deines Webspaces ergänzen oder – falls noch nicht vorhanden – anlegen.

Deshalb hier zuerst die Variante, bei der die Webseiten ohne auf die Webseiten mit www-Präfix umgeleitet werden. Dabei steht example für den Hostnamen (Second-Level-Domain) und org für die Top Level Domain (TLD).

Zur Veranschaulichung noch das Ganze mit dem Eintrag in meiner .htaccess-Datei:

Wer es lieber ganz korrekt haben möchte, der macht es umgekehrt, sprich leitet die Webseiten mit auf die Webseiten ohne www-Präfix um. Und hier auch dafür der erforderliche Eintrag in der .htaccess-Datei am Beispiel meiner Website:

Die hier vorgestellte Problematik des doppelten Inhalts (Double Content, Duplicate Content) für Webseiten mit und ohne www-Präfix ist durchaus für die Suchmaschinenoptimierung bedeutsam. Das kannst Du an der Möglichkeit sehen, dass Du in den Google Webmaster-Tools unter Einstellungen eine bevorzugte Domain mit oder ohne www-Präfix angeben kannst.

Kommentare

• 12. Januar 2010, Agy schreibt: Ich nutze es komischerweise lieber ohne www, weiß auch nicht warum, mir gefällt es so besser, aber hast natürlich Recht, der Großteil schreibt immer mit www und auf Werbungen etc wird es auch immer mit www geschrieben.
• 12. Januar 2010, Dieter schreibt: @Agy Ist völlig i.O., wenn Du die formal korrekte Variante ohne www-Präfix bevorzugst. Allerdings solltest Du das dann möglichst auch im Internet durchgängig so handhaben. Im Impressum Deiner Website nutzt Du jedoch beispielsweise die Variante mit www-Präfix.
• 20. Juli 2010, David schreibt: Warum ist das kleine 't' auf dieser Seite blau hinterlegt? Bringt das irgend was, außer, dass die Seite schlechter lesbar ist?
• 20. Juli 2010, Dieter schreibt: @David Welches kleines "t" und mit welchem Browser? Hast Du mehrere Browser getestet? Bei mir sieht alles normal aus, sowohl mit verschiedenen Browsern als auch mit verschiedenen Rechnern.
• 21. Juli 2010, David schreibt: Hi Dieter, ich bin über Google.com auf die Seite gekommen, mit den Suchbegriffen "SEO mit oder ohne www". Aus irgendeinem Grund baut mein Browser mir nämlich in den Suchlink ein &aq=t mit ein. Es ist also kein Fehler auf der Webseite. Gruß, David
• 21. Juli 2010, Dieter schreibt: @David In der Tat seltsam, aber ich bin beruhigt, dass es nicht an meiner Webseite liegt. Bei mir wirft die Suchanfrage die angeklickte Ergebnisseite mit farbigen Hintergrundfarben für die Suchwörter aus. Konkret: - SEO (blau) - mit (orange) - www sowie ohne (rot) - oder (grün) Getestet mit Firefox und Internet Explorer. PS: Das funktioniert auch mit meiner internen Suche auf Webseiten-Infos.de. ;-)
• 6. Juni 2011, Detlef schreibt: Danke für die ausführliche Beschreibung ;)
• 6. Juni 2011, Dieter schreibt: @Detlef Bitte sehr!

Ähnliche Beiträge

• Weiterleitungen beseitigen
• Webnews sind rausgeflogen
• Runde Navigationselemente ohne Grafiken
• Runde Ecken für Google Chrome 4
• Tabindex für Kontaktformular

Permalink | 8 Kommentare | Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena
Schlagwörter: .htaccess, Doppelter Inhalt, Google, SEO, Suchmaschinen, Webmaster-Tools, www-Präfix