Analítica web o autopsia


Idealmente, cuando uno analiza un site, debe encontrar los puntos fuertes y los débiles, y dar recomendaciones de mejora. Como dije una vez, se acabó lo de dinamitar la web para construir una nueva. Lo que hay que hacer es ir mejorando lo que existe, en función de los datos.

Sin embargo, para mejorar lo que existe, hay que tener algo a lo que agarrarse. Me he encontrado con sites que necesitan un cambio tan radical, que la propuesta de mejora se resume la siguiente frase: hay que empezar de nuevo. Si eso no es poner dinamita en los cimientos, se parece mucho.

El hecho de llegar a la conclusión de que se debe rehacer la web no nos libera del análisis. Tenemos que determinar qué ha funcionado (si es que algo ha funcionado), y qué no.

Cuando damos con aquello que no ha funcionado, lo importante es determinar porqué no ha funcionado. El objetivo es dar información necesaria para no repetir los errores. En esos casos tengo la sensación de que mi trabajo es más de forense que de analista. Me dedico a certificar la muerte, y ha desentrañar las causas de la misma.

Para que una web deba rehacerse desde cero se deben dar una serie de factores. Un diseño y una estructura deficientes no son causas suficientes. Para dar una web por perdida se deben considerar cuestiones que van desde la programación hasta los proveedores de servicios, pasando por la tecnología de desarrollo.

Cuando una web debe ser mejorada a nivel de programación, y los desarrolladores de la misma se manifiestan incompetentes para hacerlo, estamos ante un caso grave. Es raro que programadores distintos accedan a hacerse cargo de un producto que no es de ellos. Descifrar el código puede ser casi imposible. Incluso si se ha trabajado sobre una plataforma de desarrollo, otros proveedores verán el proyecto con desconfianza.

Si la plataforma de desarrollo está obsoleta, y no hay posibilidad de una actualización, estamos ante otro factor de peso.

En definitiva, antes de tomar una decisión radical como la de rehacer el site, hay que asegurarse de que no es posible mejorar lo que se tiene. La “imposibilidad”, dejando de lado la incompetencia, debe responder a factores principalmente técnicos.

¿Es posible modificar las URLs para que sean amigables? ¿Es sencillo definir títulos, descripciones y palabras clave para cada una de las páginas? ¿Es posible optimizar el código para mejorar los tiempos de carga? ¿pasa el código de nuestra web los test de validación estándar? Si no lo hace ¿nuestros desarrolladores pueden solucionar el problema?

Unas sencillas pruebas

Para determinar si nuestra web pasa los test de validación estándar podemos usar el “Markup Validation Service” y el CSS Validation Service, del W3C (http://validator.w3.org/ y http://jigsaw.w3.org/css-validator/, respectivamente.

Esta herramientas revisan el código de las páginas de una web, y nos dice por qué ha fallado la validación, en caso de que eso suceda.

Muy relacionados con la calidad del código, están los tiempos de carga. A parte de Page Speed (http://pagespeed.googlelabs.com/pagespeed/) podemos usar GTmetrix (http://gtmetrix.com/) y medir los tiempos de carga de las principales páginas de nuestro site. GTMetrix, genera un informe, que podemos descargar en PDF, con las recomendaciones necesarias para que la web sea más rápida.

Que el site tenga o no URLs amigables es sencillo de averiguar: basta con cargar una página cualquiera, y ver qué pone en la barra de navegación. Una URL amigable es del tipo siguiente:

http://www.misitio.com/perfumes/mujer/chanel/chanel-5/12323

Aquí estamos viendo la categoría del producto (perfume), la subcategoría (mujer), la marca (chanel), y el producto (chanel-5), y su identificador (12323).

No es lo mismo que ver:

http://www.misitio.com/product_info.php?cPath=9&products_id=453

En cuanto a título, descripción y palabras clave, hay que buscarlos en los metas tags del código… Para ello, basta con seleccionar la opción de “ver código fuente” cuando estemos en las páginas más importantes de nuestro site, y buscar las siguientes líneas, entre las etiquetas <head> y </head> (al principio):

  • <title>
  • <description>
  • <keywords>

Si no están, debería ser sencillo generarlas. Cada página debe tener metas propios, distintos a los de otras páginas del site.

Pero ojo: no pasar estar estos test, tener tiempos de carga de bajos, no contar con URLs amigables y no tener los metas básicos es solucionable en la mayoría de los casos. Como hemos dicho antes, sólo debemos plantear el rehacerlo todo si técnicamente no podemos solventar estos problemas.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: