Apr 10

Hace tiempo escribí un post acerca de como usar FeedBurner para los feeds de un WordPress que se ha quedado algo obsoleto debido a algunos cambios en WordPress respecto a la URL de los feeds y a la compra de FeedBurner por parte de Google.

Si todavía crees que usar FeedBurner es una buena idea (yo nunca lo tuve claro) la forma más cómoda de configurarlo es modificando el archivo .htaccess, aunque también existen plugins específicos (por ejemplo el FD Feedburner Plugin).

Se trata de añadir lo siguiente al .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} !FeedBurner [NC]
RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
RewriteRule ^feed/(.*)$ http://feeds2.feedburner.com/xxxxxx [R,L]
</IfModule>

Con lo anterior conseguimos que nuestro WordPress únicamente genere el feed para FeedBurner y que el resto de clientes (navegadores, arañas, etc.) sean redirigidos a la URL de FeedBurner.

Teóricamente este es el mejor método para usar FeedBurner ya que seguimos difundiendo la URL del feed original y así siempre podemos dejar de usar este servicio sin muchos inconvenientes. El problema está en que al haber la redirección muchos usuarios siguen el enlace del feed con el navegador y se suscriben a la URL del feed de FeedBurner… o sea que con el tiempo acabaremos con lectores suscritos a ambas URLs.

El método alternativo es modificar el theme de WordPress, o usar algún plugin, para difundir directamente la URL del feed de FeedBurner.

Proxy de Google

Si teníamos una cuenta en FeedBurner y la hemos migrado a Google recientemente, a parte del engorroso cambio de la URL del feed, quizás hemos notado que ahora la URL que difunde tu feed para cada post pasa por un proxy de Google.

En principio esto ya sucedía antes y el cambio únicamente es que ahora en lugar de pasar por feeds.feedburner.com pasa por feedproxy.google.com (aunque en mi caso antes de migrar la cuenta a Google no pasaba por ningún proxy, tengo caché, lo puedo demostrar :)

En cualquier caso si queremos desactivar completamente el proxy de Google hemos de cambiar la configuración de nuestro feed en FeedBurner. Concretamente se trata de desactivar la opción “Item link clicks” de la sección “TotalStats” dentro de la pestaña “Analize”. Con esto seguiremos teniendo estadísticas de número de lectores e ítems vistos (información más que suficiente) pero difundiremos siempre la URL original de cada post, algo muy recomendable para SEO (como bien nos explicaba Armonth hace tiempo).

Así es como debería quedar la configuración en FeedBurner:

FeedBurner snapshot

Tagged with:
Dec 04

MediaWiki es, probablemente, el motor para wikis más conocido del mundo. Originalmente creado para la Wikipedia actualmente es usado por una gran cantidad de wikis que nada tienen que ver con dicha fundación. La instalación por defecto del MediaWiki configura unas URLs no muy apropiadas en los tiempos que corren (con scripts PHP visibles y parámetros por GET) pero que tienen la ventaja de funcionar correctamente en un mayor número de servidores. Si dispones de mod_rewrite a continuación describo una forma de hacer estas URLs un poco más “bonitas” y cortas.

Acerca de este tema existe mucha documentación y en el apartado correspondiente del manual puedes encontrar varias alternativas. Después de haber trabajado con varias wikis en estos últimos años la que encuentro mejor es la siguiente.

Modificar LocalSettings.php

Se debe sustituir el valor de la variable $wgArticlePath por:

[php] $wgArticlePath = “/$1”; [/php]

y si no tienes definida esta variable se debe añadir en un lugar cercano a la definición de $wgScriptPath.

Modificar .htaccess

Añadir las siguientes lineas a tu .htaccess:

RewriteEngine On
RewriteBase /
RewriteRule ^$ http://www.ejemplo.com/Portada [R=301,L]
RewriteRule ^[^:]*\. - [L]
RewriteRule ^[^:]*\/ - [L]
RewriteRule ^(.+)$ /mediawiki/index.php?title=$1 [L,QSA]

Las URLs resultantes tienen la forma:

http://www.ejemplo.com/Portada para la Home.
http://www.ejemplo.com/Prueba para una página llamada “Prueba”.

Consideraciones

Este método funciona correctamente en distintos escenarios aunque se han de tener en cuenta algunas consideraciones:

[1] La wiki debe estar instalada en el directorio “mediawiki”. Si la tienes en otro directorio sustituye “mediawiki” por el nombre apropiado en las anteriores reglas de mod_rewrite.

[2] Si alguien accede a la raíz del dominio es redirigido a “/Portada” con una redirección permanente (301).

[3] Si el nombre de tu wiki contiene un punto (p.e. Ejemplo.com) fallarán los accesos a algunas páginas especiales. Para forzar que las páginas especiales que usan el nombre de la wiki en la URL se procesen correctamente es necesario añadir la siguiente regla justo después de la redirección a la Portada:

RewriteRule ^Ejemplo\.com(.+)$ /mediawiki/index.php?title=Ejemplo.com$1 [L,QSA]

Tagged with:
Nov 05

Desde el nacimiento de la World Wide Web existe la costumbre de usar el subdominio “www” para las direcciones URL cuando en realidad, y siguiendo la definición oficial de la WWW, no es para nada necesario. Todos los navegadores web existentes asumen el protocolo HTTP y añaden “http://” automáticamente a las URL, ¿porque entonces muchos servidores siguen necesitando el uso del subdominio “www” para servir la web?

Actualmente podríamos decir que es una cuestión de gustos usar o no la WWW para nuestras URL, te encuentras con partidarios del NO, como la iniciativa no-www.org, y otros que exponen interesantes motivos de porque SÍ, como en HM2K.

Lo que sí es recomendable para SEO, y en mi opinión también para temas de Marketing, es decidirse por con o sin WWW y sólo usar un formato de URL. Siempre deberíamos difundir nuestra URL de la misma forma: en los enlaces de nuestra web, en enlaces de otras webs (las que podamos controlar), en anuncios en prensa e inet, etc. También se debería redirigir el tráfico que llega por el formato no deseado al bueno.

El comportamiento por defecto de muchos servidores de servir el mismo contenido en una URL con o sin WWW sin usar ninguna redirección es un error para SEO ya que crea contenido duplicado. Lo usual es que los buscadores interpreten las URL con o sin WWW como sitios web distintos.

Personalmente también encuentro importante la unificación del formato de las URL de cara a la comunicación, imagen de marca, difusión de contenidos, etc. Normalmente uno de nuestros objetivos es que los usuarios recuerden nuestra URL, ahora hablar con WWW ahora sin, no ayuda, a parte de la imagen que transmite.

Si por ejemplo decidimos que nuestras URL llevan WWW (como yo en este blog) podemos redirigir todo el tráfico que llega a URLs sin WWW con un .htaccess como:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^phpbsd\.net$ [NC]
RewriteRule ^(.*)$ http://www.phpbsd.net/$1 [R=301,L]

Como complemento a la redirección Google también nos permite indicar nuestra preferencia en las Webmaster Tools.

Mis conclusiones:

  • Imprescindible la unificación a un formato determinado (con o sin WWW) vía redirección tanto para SEO como para Marketing.
  • Normalmente siempre sin WWW a excepción de si se trata de una web dirigida a un público no muy técnico y más aún si pretendemos hacer campañas de publicidad en medios convencionales (tv, prensa, etc.), en estos casos encuentro mejor usar la WWW para indicar claramente que nos estamos refiriendo a una URL. Quizás si usamos TLDs comunes (.com, .net, .org y en nuestro caso .es) cada día es menos necesario, si usamos cualquier otro encuentro muy recomendable usar la WWW.

¿y tú de quién eres? ¿con o sin?

Tagged with:
Jan 28

Los feeds son una de las formas más prácticas de mantenerse al día de los últimos updates de nuestros blogs favoritos. Usando sistemas como Bloglines puedes llegar a estar suscrito a centenares de feeds.

Si tenemos un blog con un poco de tráfico es muy probable que ya tengamos suscritas unas cuantas personas al feed del blog. Los lectores pueden hacer un check de nuestras feeds en un intervalo de 10 a 30 minutos. Esto con unas 30 o 50 personas suscritas suponen unas 3000 peticiones diarias o más.

Se ha de sumar también que dependiendo de donde tengas presencia con tu blog puedes tener unas 5 o 10 arañas de buscadores consultando el feed. Sin ánimo de hacer publicidad una muy buena solución para quitarnos de encima esta carga es usar FeedBurner. A parte de que ofrece varios servicios interesantes (contadores, estadísticas, etc.).

Puedes fácilmente crearte una cuenta en FeedBurner y agregar tantos feeds como quieras. La idea es que sólo FeedBurner recoja los feeds de tu blog y las peticiones de todos los demás las sirva FeedBurner.

Una manera muy sencilla de conseguir lo anterior es con el uso de mod_rewrite. Esto proporciona dos ventajas, una que no necesitamos modificar absolutamente nada de nuestro blog y la otra que si algún día no queremos seguir con FeedBurner la URL de los feeds que difundimos es la original y no tendremos ningún problema. Otra opción es modificar la plantilla de nuestro blog para que informe de la URL de FeedBurner, pero no podremos cancelar la cuenta con FeedBurner sin perder lectores.

Las reglas para el .htaccess son las siguientes:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} FeedBurner
RewriteRule ^feed/(.*)$ /wp-feed.php?feed=$1 [L,QSA]
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^feed/(.*)$ http://feeds.feedburner.com/phpbsd [R,L]
</IfModule>

Con lo anterior dejamos que FeedBurner acceda a los feeds generados por nuestro WordPress y todos los demás navegadores (o arañas de buscadores) los redireccionamos a FeedBurner.

Modificando las anteriores reglas puedes redireccionar otras feeds a FeedBurner que no sean la principal. Por ejemplo para las feeds de un tag específico (si tienes el UTW):

RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^tag/php/feed/(.*)$ http://feeds.feedburner.com/phpbsd/php [R,L]

Con todas las reglas de rewrite anteriores se asume que tenemos configurado WordPress para generar las feeds ante una URL terminada con “/feed/” y que hemos configurado las feeds correspondientes en FeedBurner.

Para más información tienes la ayuda en wordpress.org y la discusión en el foro correspondiente, también existen algunos plugins relacionados.

Tagged with:
Jan 11

Hoy en día uno de los factores a tener en cuenta cuando nos ponemos a desarrollar una aplicación PHP son que forma tendrán las URLs de nuestro futuro site. Unas URLs limpias y amigables son más fácilmente indexadas por los buscadores al mismo tiempo que son más fáciles de recordar y entender para el usuario de la web.

Como URL limpia y amigable entendemos una dirección sin parámetros por GET como por ejemplo:

http://www.phpbsd.net/bienvenida/

en lugar de la “sucia”, difícil de recordar e indexar:

http://www.phpbsd.net/?page_id=5

[1] Lo primero es configurar correctamente el apache con un .htacces como:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Estas reglas son ya un clásico usado por muchas de las aplicaciones PHP que corren por ahí (como el wordpress de este blog). Indican que cualquier petición se envíe siempre al index.php.

[2] Ahora sólo falta tratar las URLs que recibimos desde PHP. Una manera muy sencilla es con una función como:

[php] function get_url() {
$parametros = array();
$url = parse_url($_SERVER[‘REQUEST_URI’]);
foreach(explode(“/”, $url[‘path’]) as $p)
if ($p!=”) $parametros[] = $p;
return $parametros;
} [/php]

Esta función devuelve un array con todos los parámetros separados por “/” pasados a la URL. Con esto ya podemos procesar la petición, sólo tenemos que consultar en este array para saber que nos piden.

Por ejemplo con la URL:

http://www.phpbsd.net/2006/12/06/optimizacion-del-rendimiento-de-adodb-en-php/

si ejecutamos un print_r(get_url()) obtenemos:

Array (
[0] => 2006
[1] => 12
[2] => 06
[3] => optimizacion-del-rendimiento-de-adodb-en-php
)

Para más información podéis consultar la documentación de la función parse_url y del módulo de apache mod_rewrite.

Tagged with:
preload preload preload