Mit Gzip und Deflate Compression übergewichtige Pfunde der Webseite schrumpfen sowie Müsli, ähm Cache und Expires gegen das Vergessen via htaccess optimal servieren – so gehts:

Ich habe schon lange nach einer optimalen htaccess gesucht, die möglichst alle (viele) Empfehlungen von PageSpeed sauber umsetzt. Wo wenn nicht bei google wurde ich heute endlich fündig!

Ich habe von der originalen htaccess Datei eine wichtige Teilmenge für mich abgezwackt, die all meinen Seiten ein paar Flügel verliehen hat!

Vielleicht kann der ein oder andere damit ja auch was gescheites anfangen:
Hier gehts zum Code

Expires Header: Gives the date/time after which the response is considered stale

add following to your .htaccess file for enabling expire-header (expire apache module must be installed):

<IfModule mod_expires.c>
    # turn on the module for this directory
    ExpiresActive on
    # set default
    ExpiresDefault "access plus 24 hours"

    # cache common graphics
    ExpiresByType image/jpg "access plus 1 months"
    ExpiresByType image/gif "access plus 1 months"
    ExpiresByType image/jpeg "access plus 1 months"
    ExpiresByType image/png "access plus 1 months"

    # cache CSS
    ExpiresByType text/css "access plus 1 months"

    # cache other filetypes
    ExpiresByType text/javascript "access plus 1 months"
    ExpiresByType application/javascript "access plus 1 months"
    ExpiresByType application/x-shockwave-flash "access plus 1 months"
</IfModule>

[via]

Die JavaBots – wofür sie auch immer gut sind – vermehren sich in der letzten Zeit drastisch, spidern Scharenweise die Websites und produzieren dabei viele 404 Fehlermeldungen. Das nervt! Erst hatte ich versucht sie manuell über die robots.txt auszusperren, doch trägt man dort einen ein, kommt auch schon ein anderer. Die Liste der verschiedenen Bots ist “zu lang” um sie bei jedem neuen Bot aufs neue einzutragen, so dass eine andere Lösung her musste. Einfach in die .htaccess folgende Rewrite Regel reinschreiben und Ruhe ist:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^Java
RewriteRule ^.*$ - [F]

by Peregrino Will Reign

• Sicherheit in WordPress: 10 Schritte zum Schutz des Admin-Bereichs
  Der Administrationsbereich einer Webanwendung ist das beliebteste Ziel der Angreifer und gehört somit besonders gut und wirksam geschützt. Nicht anders ist es in WordPress: Beim Initialisieren eines neuen Blog legt das System einen Administrationsnutzer mit einem durchaus sicheren Passwort an und sperrt den öffentlichen Zugang zum Bereich mit sämtlichen Einstellungen durch eine Login-Seite ab. Der Grundstein der Absicherung ist gelegt. Wir graben tiefer!
  Ein wirklich sehr lesenswerter Artikel! Die kleinen Tutorials sind sehr gut beschrieben und sind zudem gut mit Bildern illustriert.
• 11 Vital Tips and Hacks to Protect Your WordPress Admin Area
  As we continued to emphasize the security of your WordPress admin panel due to the recent attack on our site, we have compiled a fully detailed article that will highlight some of the must have security measures for your WordPress Admin Area.
  Dieser Artikel beinhaltet einige Schritte, die in dem oberen Artikel nicht aufgeführt sind

Domaingo bieten erst ab dem “Power L” Paket die Möglichkeit das Apache Modul “mod_rewrite” zu benutzen. Das hat zur Folge, dass wenn User mit minderwertigeren Paketen versuchen Permalinks in ihrem WordPress zu aktivieren, sie sich dann nur noch vor einer “Internal Server Error 500″ Page wiederfinden und NICHTS mehr geht! Da steht man dann dar und ist erstmal heftigst geschockt!

Schuld daran ist dann eine automatisch generierte .htaccess Datei im root der WP-Installation, die eine mod_rewrite Regel benutzt. Diese .htaccess Datei muss dann einfach per FTP (am Besten im internen domaingo Kundenmenü FTP Browser) gelöscht werden und das Blog ist wieder erreichbar!

Domaingo Nutzer könne also erst mit den Taripaketen “Power L” und “Power XL” das Apache Modul nutzen. Das Funktioniert seit Mai 2005.