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?

Entradas relacionadas:

• URLs limpias y amigables con PHP y Apache
• MediaWiki con URLs cortas usando mod_rewrite
• Administrar servidores web vía SSH sin contraseña

Existen varias propuestas de sistemas de cache donde siempre se ejecuta un script PHP trabajando con el output-buffer para guardar la respuesta. Estos sistemas de cache tiene el inconveniente de que a pesar de tener la página cacheada siempre estamos ejecutando un script PHP con el coste en rendimiento que ello conlleva. Como solución se propone trabajar con el output-buffer pero usar la directiva de configuración ErrorDocument del Apache para que si ya tenemos la página generada no se ejecute ni un script PHP.

La directiva ErrorDocument se usa para configurar lo que el servidor devolverá al cliente en caso de error. Pues bien, se trata de configurar el error que indica que no existe la página solicitada (error 404) para que apunte a un script PHP donde generaremos la página. En la siguiente petición a la misma página el Apache devolverá directamente el archivo HTML generado.

Algunas consideraciones previas:

• Necesitas tener permisos de escritura en el directorio donde pretendas guardar las páginas. (esto lo puedes conseguir fijando los permisos a 777).
• Necesitas poder configurar la directiva ErrorDocument de tu servidor Apache. (algunos hostings no lo permiten).

[1] Configurar el Apache

Debemos añadir lo siguiente en nuestro .htaccess o en la configuración del servidor Apache:

ErrorDocument 404 genera_pagina.php

[2] Añadir el código necesario

Es necesario añadir un bloque de código al principio y al fin de cada script. A continuación una implementación de ejemplo:

Se puede guardar el anterior código en un script llamado "genera_pagina.php" sustituyendo la linea echo "hola" por el código de nuestra aplicación (p.e. con un include()) o podemos dividir el código en dos scripts y usar las directivas auto-append-file y auto-prepend-file para no tener que modificar nuestra aplicación (cortar por las lineas de puntos).

En el ejemplo se obtiene sólo el nombre de la página solicitada y se crea una archivo con el mismo nombre con el contenido de la respuesta. Pero no soporta directorios, está pensado para trabajar sobre un directorio en concreto o en una web sin directorios en las URL. Cambiando la primera linea del ejemplo podéis hacer que se comporte de otra forma, el ejemplo simplemente obtiene el último trozo de la URL usando como delimitador "/".

A diferencia de otras propuestas de cache aquí estamos modificando el Apache para que ejecute un script en caso de no encontrar una página. Es por esto que en vuestra aplicación debéis generar una página de error en el caso de que la página solicitada no exista. Lo correcto es que en esta página de error se envíe la header correspondiente tal y como lo haría el Apache por defecto:

[3] Mantenimiento de la cache

Por ultimo nos falta programar un proceso en el cron para que elimine los archivos de la cache que han caducado. Por ejemplo para mantener una cache de una hora:

0 * * * * find /web -mtime +1h -print0 | xargs -0 rm -f

Se ha de sustituir "/web" por la ruta física donde tenemos nuestra aplicación web. Si no queremos programar un cron siempre podemos hacer lo anterior desde algún script PHP que se ejecute constantemente en nuestra web.

Lo que comento en este post no es nada nuevo, ya fue propuesto por Rasmus Lerdorf en el PHPCon del 2002 (aunque un poco caducada la presentación que enlazo merece la pena).

Entradas relacionadas:

• Cache en memoria compartida con APC
• Instalación del APC (Alternative PHP Cache) sobre FreeBSD
• Nuevos estándares para las PEAR2

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:

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.

Entradas relacionadas:

• MediaWiki con URLs cortas usando mod_rewrite
• URL con o sin WWW, esa es la cuestión
• Transfiriendo datos con la librería cURL en PHP