Cosas que no hay que hacer al redireccionar una página

En estos últimos tiempos he aprendido dos cosas que no hay que hacer nunca cuando quieres redireccionar una página si no quieres hundirte en la miseria.

Cosa 1: Redirecciones 301 a 404

Uno de los fallos más habituales que comentemos cuando hacemos una redirección 301 es que solemos mandar tooodo a la nueva URL, dominio o lo que toque en cada caso… pero no solemos parar a mirar si una página se está redireccionando hacia una que da error, o sea, una que devuelve un código 4xx.

¿Y qué pasa con los buscadores? Pues que como siempre se lían con los 3xx, 4xx y 5xx, por norma general, si haces una redirección a una página de error, esas páginas se acaban añadiendo al índice secundario y se monta un poyo bastante hermoso.

La cuestión es que, los casos en los que una redirección 301 acaba mandando a una página 404, esa página, puede que visiblemente no esté en los resultados de búsqueda, pero si revisas en Webmaster Tools aparecen “cosas raras”.

Cosa 2: Canonical con noindex

Una de las formas más sencillas de hacer una redirección, o mejor dicho, de corregir si una dirección URL no es correcta, es la de usar la meta-etiqueta canonical. Con esta etiqueta, básicamente le decimos a los buscadores que “ignoren” la direción URL que se encuentra en la ventana del navegador y que la que han de poner e indexar es la que aparece en el código fuente. De esta forma, si algún juanker quiere hacer cosas malignas, no va a poder conseguirlas.

El problema más grande es que en algunas ocasiones, uno se puede plantear que “la página actual” ha de ser otra (por eso ponemos el canonical) y no queremos que la “vieja” se indexe (por lo que ponemos el noindex)… ¿qué ocurre? Que tanto la nueva como la vieja no se indexarán al tener ese noindex.

Teniendo en cuenta que el canonical lo que acaba haciendo es “eliminar” la dirección URL antigua, no hace falta utilizar el noindex, ya que perjudica en la aparición en los resultados de búsqueda.

Un par de trucos para WordPress con .htaccess

Muchas veces queremos hacer cosas en WordPress y buscamos plugins que pueden sobrecargar el sistema de forma absurda, pudiendo hacer mejoras gracias a unas pocas líneas del .htaccess.

Reducir spam en comentarios

En muchas ocasiones los robots de spam están tan mal hechos que no incluyen ningún tipo de referrer, algo que los usuarios por norma general sí que permiten… así que:

RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*dominio.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

Evitar enlaces multimedia externos (hotlinking)

Gracias a esto puedes impedir que los sitios que te enlacen y usen tus imágenes reciban un bonito mensaje…

RewriteCond %{HTTP_REFERER} !^http://(.+\.)?dominio\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|png)$ nohotlinking.png [L]

WTF – Web Testing Framework

Muchos sabéis que una de las herramientas que últimamente tengo bastante presente es YSlow, y hace unos días que descubrí una ampliación de esta herramienta llamada WTF (Web Testing Framework) que simplemente revisa algunos elementos del código de una página web.

Entre los elementos que revisa están:

  • Si se usa el elemento <blink>
  • Si se usa el elemento <marquee>
  • Si se usa el elemento <font>
  • Si no existe el <doctype …>
  • Si se usan imágenes GIF para ajustar el diseño
  • Si se usan enlaces con # o javascript

La versión 0.0.1 se lanzó el pasado día 20 y para utilizarla sólo hace falta que ya esté en funcionamiento la herramienta de Yahoo!. A ver si su creador le va añadiendo más elementos que no contempla la herramienta “padre”.

HTML 5: los “malditos” iframes

Aunque es uno de los elementos que se utilizan todavía, la verdad es que el consumo que provoca en los navegadores es tan alto que si nos paramos a pensar fríamente, no es nada recomendable su uso… aún así, el HTML 5 todavía lo mantiene ya que para algunas cosas sigue siento un elemento valioso (aunque, como digo, yo no lo recomiendo, ni yo ni Google ni Yahoo!…)

iframe

El elemento iframe básicamente permite integrar lo que se podría decir como una ventana de navegador dentro de otra, o sea, una página dentro de otra, en un espacio definido. De esta forma podemos abrir el contenido de una página propia o externa dentro de una parte de la que actualmente visualizamos.

El principal atributo que lo acompaña es el src que como en muchos otros elementos, hace referencia a una dirección URL, que será la página que abrirá dentro. También se le puede indicar el srcdoc que hace referencia al nivel de profundidad que tendrá el elemento. El atributo name hará referencia al nombre del elemento (por si hay que acceder a él a través del DOM).

Uno de los mayores problemas que tienen los iframes es la seguridad que puede comportar abrir “cualquier” elemento externo a nuestro sitio. Es por esto que existe el atributo sandbox (al que por ejemplo ya da soporte Google Chrome) y que restringe algunas acciones. Algunos de los valores que puede generar excepciones son:

  • allow-same-origin
  • allow-top-navigation
  • allow-forms
  • allow-scripts

<iframe sandbox="allow-same-origin allow-forms allow-scripts" src="http://www.example.com/incrustado.html"></iframe>

Otro atributo que parece muy interesante es seamless. Con este atributo le decimos al navegador que “renderice” el contenido del iframe como si fuera parte del sitio. Esto implicará que haya algunas restricciones y ampliaciones, como que el contenido ha de estar en el mismo dominio, que los CSS que haya en el iframe pasarán a formar parte del CSS principal…

Para acabar, y como es lógico, hemos de indicar el tamaño de la ventana, y para ello utilizaremos los atributos width y height, que indicarán el ancho y alto de la ventana.

Sin duda el elemento iframe va a ser uno de los más criticados por los buscadores y optimizadores de la red, pero parece que va a seguir aquí durante bastante tiempo.

Web Performance Optimization, básico en un negocio web

Según voy adelantando en esto de mejorar los sitios web, ya no por SEO únicamente, sino pensando en los usuarios, me doy cuenta de la importancia esa de frases como: es que Google va muy rápido. Sí, la verdad es que sí, se agradece muchísimo que un sitio vaya muy muy rápido hoy en día, porque en gran medida es lo que hace que el usuario se sienta a gusto, porque puede navegar casi instantáneamente.

Uno de los inversores importantes en Estados Unidos, Fred Wilson, que ha invertido en Twitter, delicious, Etsy o FeedBurner cuando habla del TOP 10 de las aplicaciones web, pone en el número uno la velocidad del sitio: First and foremost, we believe that speed is more than a feature. Speed is the most important feature. If your application is slow, people won’t use it…; así que vale la pena siempre darle una ojeada a la optimización del sitio, ya sea a nivel de SEO, a nivel Usabilidad, o a nivel de que el código sea 100% compatible, pero normalmente no nos miramos con tanto ojo si el servidor web, la base de datos o el lenguaje de programación están configurados de forma óptima.

Conseguir algo como esto no es nada sencillo, sobretodo si vienes de un sitio bastante complejo y con muchos problemas:

Pero conseguir algo como esto en tan sólo unos días, creo que es bastante emocionante…

Y es que dentro de poco creo que vamos a ver nacer un nuevo tipo de trabajo, gente que se dedicará principalmente a hacer mejorar el rendimiento de los sitios web, un trabajo que muchos administradores de sistemas deben tener presente, ya que son ellos los principales beneficiarios de algo así.

Un googlero llamado Steve Souders, anteriormente trabajador en Yahoo! y conocido como Yahoo! Superstar, además de ser el creador de una de las herramientas básicas, el YSlow, publicó una entrada hace cosa de un mes en la que explica algunos temas interesantes:

  • Rapidez por defecto: muchas aplicaciones que se construyen para CMS, lenguajes de programación, “la nube”, bibliotecas de JavaScript, navegadores, servidores… ya están pensadas para ir rápido.
  • Maquetación del navegador: con el fin de hacer que las páginas web más rápido los desarrolladores necesitan la capacidad de encontrar qué partes son más lentas. Esto requiere revisar el tiempo que tarda en cargar y ejecutarse el JavaScript, los CSS, la maquetación de los elementos, la gestión del DOM…
  • Consolidación: las herramientas de rendimiento de la web, servicios y similares no han llevado un único camino, sino que cada uno ha puesto sus esfuerzos de forma separada. Eso va a cambiar y pronto veremos herramientas que combinan la depuración de JavaScript, el perfil de JavaScript, DOM, el uso de la red… todo en una sola herramienta. Las métricas de rendimiento se gestionarán desde un único panel en lugar de tener que visitar múltiples servicios separados. La consolidación también va a ocurrir a nivel de empresa, donde las empresas más pequeñas relacionados con el rendimiento son adquiridos por las grandes empresas de consultoría y servicios.
  • TCP y HTTP: Los protocolos por los que funciona Internet deben ser optimizados, y SPDY es una propuesta. Tenemos que tratar de conseguir más apoyo para el pipelining. Cualquier mejora en la red llegará a todos los sitios y el usuarios.
  • Estándar: hay que establecer un estándar sobre las formas de medir, los datos, las pruebas… La Web Timing Spec es un primer ejemplo a tener presente.
  • Organizaciones en la industria: dentro del mundillo de la WPO veremos nacer y crecer organizaciones profesionales, formación, certificaciones, organismos de normalización… Un ejemplo podría ser que los editores web compartan información acerca de los anuncios de publicidad lentos.
  • Los datos: hacer seguimiento de los resultados y encontrar nuevas oportunidades de rendimiento requiere un gran análisis de datos. Es probable que comiencen a verse repositorios públicos de datos relacionados con el rendimiento.
  • Verde: los estudios realizados que cuantifican cómo mejorar el funcionamiento web confirman la reducción del consumo de energía y por ello la contaminación que generan los centros de datos.
  • Rendimiento móvil: es como un nuevo punto de partida, se necesita recopilar todo tipo de información hasta encontrar los principales problemas, las causas y encontrar soluciones y crear herramientas para así poder ofrecer información sobre todo esto.
  • La velocidad como elemento diferenciador: muchas de las decisiones que se tomarán sobre Internet se basarán en el rendimiento. Cuando alguien adquiera un dispositivo, elija un proveedor, se revise un sitio web, la lealtad de los usuarios será un factor importante a la hora de hacer mediciones.

En fin, tengo claro que para los usuarios, para las conexiones a Internet, para los buscadores… cuanto mejor vaya un sitio web, cuanto más óptimo sea, si cabe, mejores resultados van a obtenerse a medio plazo.

Dominios sin cookies

Una de las cosas de las que últimamente se habla bastante es de los CDN y los dominios cookie-less y su influencia en el rendimiento de un sitio web. Si bien es cierto que no estoy nada de acuerdo con distribuir una web dinámica por un CDN, ya que eso destrozaría todo el sentido SEO que se le puede llegar a dar, sí que se pueden plantear soluciones para los contenidos estáticos.

Una de estas soluciones es el uso de los dominios sin cookies, que básicamente lo que son es sitios donde almacenar información que no permita recibir o enviar cookies. Y es que las imágenes, estilos o javascripts no necesitan, para nada, enviar o recibir cookies ya que no las van a saber interpretar, y quieras que no, si vas sumando bytes en las conexiones, al final del día son unos cuantos.

La primera pregunta que hay que hacerse es qué se debe elegir a la hora de plantear montar un dominio sin cookies. La idea es que sea un dominio para contenidos estáticos, es decir, imágenes, ficheros cacheables, etc; y, el siguiente planteamiento es obvio: ¿por qué no usar un subdominio? Muy sencillo, depende de cómo esté configurado un dominio o sus cookies, es posible que estas se pasen también a subdominios, por lo que, finalmente, llegamos a una conclusión: los estáticos han de estar en un dominio separado, pensado para estáticos sin cookies (y ya puestos, con compresión y otras cosas más).

Con esto tendríamos algo como que:

www.dominionormal.com/imagenes/logo.png

se convertiría en algo como:

www.dominiosincookies.com/imagenes/logo.png

La verdad es que encontrar información sobre cómo conseguir configurar un servidor web sin cookies no me ha sido nunca tarea sencilla. Supongo que otros servidores web distintos de Apache debe ser algo factible, sobretodo en los más modernos, pero en Apache las cookies vienen configuradas por defecto y no se pueden eliminar. Al menos no se pueden eliminar si no se usan algunas cosas extra.

Para poder usar esto, necesitamos el módulo de Apache mod_headers que habitualmente viene configurado y activado. Una vez eso, en el fichero de configuración de Apache, dentro del VirtualHost del dominio que hayamos decidido configurar como sin-cookies, tendremos que añadir estas dos líneas:

RequestHeader unset Cookie
Header unset Set-Cookie

Creo que son bastante claras en lo que hacen… pero, en resumen, se comen y no envían ninguna galleta.

Aun todo esto, algo que no he probado y que podría funcionar, es una configuración que podría ser parecida a esta que debería funcionar tanto en la configuración global, como en la del .htaccess, aunque como digo, no lo he podido testear.

<FilesMatch "\.(ico|gif|jpg|png|flv|pdf|mp3|js|css|xml)$">
Header set Cache-Control "max-age=2592000"
Header always unset Set-Cookie
Header unset ETag
FileETag None
</FilesMatch>

En este caso, sin necesidad de un dominio distinto, lo que el servidor hace es que cuando los ficheros que se solicitan coinciden con alguna de las extensiones que hay en la lista, ejecutaría esas líneas, que básicamente son una caché de 1 mes, eliminar cookies y activar los ETag.

Otra cosa a tener en cuenta es todo lo contrario… ¿y si necesitamos que las cookies siempre se queden un mínimo de tiempo y que no se eliminen cuando se cierra el navegador? Pues esto es tan sencillo como añadir una línea tal que así en el propio .htaccess:

CookieExpires 2592000

La cifra que acompaña son el número de segundos desde que se crea la primera vez la cookie, en este caso 2592000 corresponde a 30 días.

En fin, y creo que esto, una vez más, espero que de algunas pistas sobre cómo y qué revisar para montar algo de este estilo… sin duda algo interesante a tener en cuenta si le sumamos trabajar con CDN.

NOTA: Para los usuarios de WordPress, existe una variable global interesante que limita las cookies a sólo lo que se le diga:

define('COOKIE_DOMAIN', 'www.ejemplo.com');

NOTA: Para los que no quieran registrar un dominio, se puede usar una cosa que hay en pruebas en 2Static.it.

Los servidores de Google

Siempre ha habido un montón de información extraña sobre los servidores de Google y cómo se organiza. Desde que estoy metido en el mundo de los centros de datos en Digital Parks he podido ver algunos de los problemas a los que los webmaster normalmente no se enfrentan, como es la electricidad y la refrigeración de las máquinas, o el simple sistema de conectividad de redes…

En fin, os dejo con una serie de vídeos interesantes sobre el funcionamiento de los centros de datos y contenedores que usa Google.

AMPLIACIÓN: Pero antes, de ver los vídeos, me molaría comentarios sobre una patente que ha registrado gente de Google en la que se especifican cómo deberían ser una serie de servidores bastante más eficaces todavía de los que se presentan aquí, y que Google lleva trabajando desde hace 3 años. Descargar información e imágenes.

Además de estos vídeos hay varias presentaciones sobre lo que Google hace para que sean más eficientes y “verdes”.

La mejor forma de hacer una redirección

Los sitios web van y vienen… y como no queremos perder información ni generar un montón de errores en la red de redes, lo mejor es poder migrar información de un sitio a otro fácilmente.

Y como ya comenté una vez, el 302 no es una redirección, sino que lo son el 301 y 307, por lo que si queremos migrar todo lo relacionado a un sitio, deberemos aplicar una de estas, en este caso, la redirección 301.

Hay que partir de la base de que las redirecciones en HTML (a pelo) no funcionan, al menos no para lo que nosotros queremos. Esto significa que hacer una redirección con el meta-refresh o a través de JavaScript no sirven para migrar contenidos o pesos, sino que el usuario cambia de “página vista” a un nuevo lugar. Hay que tener en cuenta que esto se ha usado tiempo atrás como método de spam, así que hay muchas posibilidades de que los buscadores consideren tu sitio un poco indeseable.

En estos casos en los que no disponemos de un sistema para generar redirecciones 301 programadas lo mejor es utilizar el sistema de “rel=canonical” que propuso Google y el resto de buscadores y que, en algunos casos, se puede usar para redirigir tráfico entre dominios.

¿Se puede utilizar rel=”canonical” para sugerir una URL canónica de un dominio completamente distinto?

Existen situaciones en las que no resulta fácil configurar los redireccionamientos. Así ocurre, por ejemplo, cuando hay que realizar una migración a un nuevo nombre de dominio a través de un servidor web que no puede crear redireccionamientos de servidor. En esos casos se puede utilizar el elemento de enlace rel=”canonical” para especificar la URL exacta del dominio que se prefiere para la indexación. Aunque el elemento de enlace rel=”canonical” se considera una sugerencia y no una directiva incuestionable, intentamos seguirlo siempre que es posible.

Básicamente sería incluir en el “head” de cada una de las páginas a redireccionar algo como:

<link rel="canonical" href="http://www.nuevodominio.com/nueva-carpeta/nuevo-fichero.html">

En el caso en el que sí que tengamos acceso al menos al servidor Apache, aunque no tengamos un lenguaje de programación para hacerlo, es utilizar el .htaccess del servidor. Por norma general, debería de funciona, aunque si tu proveedor de Internet es un poco rata puede que no te sirva mucho…

En este caso tenemos un par de opciones… la más sencilla sería esta…

Redirección 301 usando .htaccess

Redirect 301 /vieja-carpeta/viejo-fichero.html http://www.nuevodominio.com/nueva-carpeta/nuevo-fichero.html

Otra opción es usar el mod_rewrite, también del .htaccess y que en este caso usaríamos, por ejemplo, para controlar si el sitio tiene o no las www.

Redirección 301 usando mod_rewrite

RewriteEngine On
RewriteCond %{http_host} ^nuevodominio.com
RewriteRule ^(.*) http://www.nuevodominio.com/$1 [R=301,L]

En el caso de querer hacerlo con Internet Information Server (IIS) podemos seguir estos pasos…

Redirección 301 usando Internet Information Server (IIS)

  • En el Internet Services Manager, hacer botón derecho en el fichero o carpeta a redireccionar.
  • Seleccionar la opción: redireccionar a una URL.
  • Añadir la dirección URL de destino
  • Seleccionar la opción URL exacta y redirección permanente.
  • Pulsar en Aplicar / OK

Si trabajamos con alguno de los siguientes lenguajes de programación, suele ser bastante sencillo, aunque se puede complicar según queramos hacerlo más o menos extensible. Por ejemplo:

Redirección 301 usando ASP

<%@ Language=VBScript %>
<%
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.nuevodominio.com/"
%>

Redirección 301 usando ASP.net

<script runat="server">
private void Page_Load(object sender, System.EventArgs e)
{
Response.Status = "301 Moved Permanently";
Response.AddHeader("Location","http://www.nuevodominio.com/");
}
</script>

Redirección 301 usando ColdFusion

<cfheader statuscode="301" statustext="Moved permanently">
<cfheader name="Location" value="http://www.nuevodominio.com/">

Redirección 301 usando Java

<%
response.setStatus(301);
response.setHeader("Location", "http://www.nuevodominio.com/");
response.setHeader("Connection", "close");
%>

Redirección 301 usando Perl

$q = new CGI;
print $q->redirect(" http://www.nuevodominio.com/ ");

Redirección 301 usando PHP

<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://www.nuevodominio.com/");
exit;
?>

Redirección 301 usando Ruby o Ruby on Rails

head :moved_permanently, :location => "http://www.nuevodominio.com/

De todas formas, estas redirecciones mandarían cualquier página a la principal, y no a la correspondiente. para eso, por ejemplo en PHP, se podría hacer algo como esto:

<?php
header("HTTP/1.1 301 Moved Permanently");
$accion = "Location: http://www.nuevodominio.com".$_SERVER["REQUEST_URI"];
header($accion);
?>

En este caso se incluye la variable de servidor REQUEST_URI que lleva toda la dirección URL exceptuando el dominio…

Y con esto un minicursillo de redirecciones en muchos lenguajes de programación distintos… al menos espero que a alguien le sirva para tener un punto de inicio si necesita migrar un dominio y no quiere perder todo el trabajo que haya podido hacer históricamente en él.

Migrando de servidor

Seguramente algunos habréis notado que ayer tarde e incluso esta noche el sitio está haciendo un poco el tonto… y es que me ha dado por migrar el servidor web a algo mejor.

Con mejor no quiero referirme a que la máquina sea más potente (la verdad, no tengo ni idea de qué tiene) pero sí que me he dedicado a mejorar su configuración, y en vez de usar una máquina con Plesk he pedido una máquina “a pelo”.

Configurar un servidor web desde cero, con su PHP, con su SQL, todo de forma más o menos distribuida es un tema bastante interesante en cuanto a la escalabilidad que te da. Por ahora estoy en una primera fase, aunque pronto espero hacer crecer la máquina y lo que hay dentro.

En fin… poco más a explicar… voy a dejar unas cuantas horas hasta que se acaben de replicar las DNS y esas cosas… y así ya mañana sigo publicando más y mejor…

CSSTidy: optimizar CSS es fácil

Una de las cosas por las que no solemos preocuparnos mucho es por los CSS. Solemos hacer un CSS más o menos bien formado, pero a partir de ahí nos limitamos a subirlo al servidor y poco más. Pero… si os digo que se puede ahorrar hasta un 25% en un CSS, ¿no sería interesante aplicarlo?

La idea es que los CSS, al ser un elemento de los que se han de cargar antes que “se pinte” el HTML interesa que sea rápido en descargar. Además, es un elemento que suele estar en todas las páginas, y aunque el navegador suele cachearlo, vale la pena que ocupe poco…

Una de las herramientas que podemos implementar directamente en nuestro servidor es el CSSTidy, que tiene unas opciones para PHP bastante sencillas.

El ejemplo básico podría ser este:

<?php
include('class.csstidy.php');
$css_code = "a {
  color:black;
  background-color:blue;
}";
$css = new csstidy();
$css->set_cfg('remove_last_;',TRUE);
$css->parse($css_code);
echo $css->print->formatted();
?>

Un ejemplo no tan básico podría ser este:

<?php
$css_code = file_get_contents("http://www.example.com/estilo.css");
include("class.csstidy.php");
$css = new csstidy();
$css->set_cfg("preserve_css",true);
$css->load_template('high_compression');
$css->parse($css_code);
$min = $css->print->plain();
?>

Las opciones que yo dejaría son (aunque puede que se pueda mejorar con alguna otra combinación):

  • remove_bslash = true;
  • compress_colors = true;
  • compress_font-weight = true;
  • lowercase_s = true;
  • optimise_shorthands = 0;
  • remove_last_; = true;
  • case_properties = 0;
  • sort_properties = true;
  • sort_selectors = true;
  • merge_selectors = 1;
  • discard_invalid_properties = true;
  • css_level = ‘CSS2.1’;
  • preserve_css = true;
  • timestamp = false;

En fin, una interesante herramienta que podemos ver en acción directamente en CSS Compressor, que es la herramienta que habitualmente utilizo yo.