La página web del Grupo Planeta, Planeta.es, ha perdido un 75% de visibilidad en Google después de llevar a cabo un rediseño de su sitio Web.
Un rediseño Web debería ser un motivo de alegría ya que crea expectativas sobre los resultados venideros. Sin embargo, muchas veces sucede todo lo contrario y las visitas que deberían llegar a través de Google no aumentan sino que se reducen drásticamente. Migraciones como las de Planeta.es no son una excepción y por ello deseo explicar hoy, cómo se debe llevar a cabo una correcta migración.
- Planificación de la migración, ejecución y control
- 1) Planificación: Encontrar todas las URL que cambiarán
- 2) Ejecución: Redireccionamientos de URLs que cambian o se eliminan
- 2.1) Creación de los 301 en PHP, Apache, NGNIX, Lightttpd o IIS
- 2.2) Informar a Google de los cambios
- 3) Control: Control de los redireccionamientos y sus parámetros
- Otras herramientas gratis:
Empecemos por analizar el caso de Planeta.es ya que es bastante simple aunque muy común. Si comparamos la página Web antigua con la nueva, vemos que en principio la estructura es básicamente la misma con casi los mismos contenidos. Aún así, el directorio más relevante del sitio Web http://www.planeta.es/es/ES/ se ha desplomado en un 100%.
Si la estructura del sitio Web no ha variado tanto entre la versión anterior y la nueva, ¿por qué esta caída tan radical? Porque los 301-redirects simplemente son… de otro planeta:
- El primer 301-redirect redirige correctamente: www.planeta.es -> http://www.planeta.es/es.
- El segundo, redirige desde hace más de 6 años (no he querido investigar más): www.editorial.planeta.es/ -> http://www.planetadelibros.com/editorial-editorial-planeta-8.html
- El tercer 301-redirect también redirige correctamente: www.planeta.es/es/ES/Default.htm -> http://www.planeta.es/es
Y paramos de contar. A partir de aquí todos los 301-Redirect redirigen a un 404 que posee el mismo diseño de la página de inicio, en lugar de redirigir al nuevo contenido correspondiente. Algunos destinos ya no están disponibles (N/A) y los destinos con códigos de estado 200 son simplemente gráficas de 1 pixel. Pulsando sobre el recuadro con la flecha anterior a la URL se puede comprobar.
Casos como estos se ven casi todas las semanas en la lista de Ganadores y Perdedores de SISTRIX. Así, que he decido escribir una pequeña guía para intentar ayudar para que esto no ocurra.
Planificación de la migración, ejecución y control
El SEO debe formar parte de la planificación y de la ejecución de una migración. El SEO no es un accesorio que se puede añadir después o que se pueda implementar rápidamente, SEO es un trabajo continuado que en caso de una migración, debe procurar que un sitio Web se pueda visualizar mejor (en todos los aspectos) y que la información que ofrece el sitio Web, pueda ser fácilmente encontrada y valorada por los usuarios y por Google.
Una migración implica siempre un cierto riesgo pero también una gran oportunidad para mejorar los contenidos, el CMS o el tiempo de carga, pero no se deberían ajustar muchas tuercas al mismo tiempo para no generar errores y después no estar en capacidad de identificar las causas.
1) Planificación: Encontrar todas las URL que cambiarán
Muchos usuarios de sitios Web intentan memorizar la estructura del sitio (subdominios, directorios y URLs) que usan para acceder rápidamente a la información deseada. Google procede de la misma forma, aunque su capacidad de memorizar es superior a la del usuario. En ambos casos si se cambia la estructura de un sitio Web, las rutas antiguas también deberían llevar a los nuevos contenidos, para ello están los 301-Redirects.
De no hacerse redirects o no hacerlos correctamente, ni el usuario, ni Google, ni todos los links conseguidos hasta ese momento encontrarán la información deseada. La consecuencia de no hacerlo correctamente la vimos en el ejemplo anterior de Planeta.es.
Ejemplo: Imaginemos que una tienda Online desea mejorar sus URLs aprovechando la migración:
www.dominio.es/producto?p=1&sID-Tag=Navidad -> www.dominio.es/navidad/
Primero se tienen que identificar todas las URLs que deben ser cambiadas o eliminadas:
a) Crear un XML o HTML Sitemap del sitio antes de la migración. Este proceso se puede hacer de forma automatizada y permite cómodamente identificar las URLs del sitio Web.
b) Se puede hacer uso de Google Analytics para identificar las URLs y la Landingpages que reciben visitas orgánicas desde Google, como también desde la redes sociales. La exportación es sencilla. (Si usas SISTRIX puedes sincronizar Google Analytics):
c) Haciendo uso de Google Search Console se pueden identificar la páginas con muchas impresiones o visitas. Basta con ir a “Tráfico de búsqueda > Análisis de búsqueda“. Estos datos también se pueden descargar. (Si usas SISTRIX puedes sincronizar Google Search Console)
d) Si se tiene en cuenta el gran costo que puede tener una migración mal hecha y el gran costo que tiene perder enlaces para los cuales se ha trabajado, el uso de una herramienta profesional se amortiza con rapidez. Además de cuidar los nervios, ahorra tiempo y trabajo, con SISTRIX por ejemplo, se pueden identificar las URLs de un sitio Web que poseen los backlinks más valiosos y que en definitiva, son los que se deberían conservar:
Igualmente se pueden ver las URLs con más señales sociales:
2) Ejecución: Redireccionamientos de URLs que cambian o se eliminan
Cualquier URL que vaya a ser redireccionada, debe redireccionar a su homólogo del nuevo contenido. No olvidemos que los backlinks, los usuarios y Google “memorizaron“ la antigua URL, a través de un 301-Redirect nos aseguramos que la reputación ganada hasta ese momento sea transferida y no genere estrés a nadie.
Las URLs que no tienen ningún futuro y serán eliminadas, deberían responder con un código de estado 404 ó 410. Si un usuario pulsa sobre “iPhone 6“ quiere ser redireccionado a “iPhone 6“ y NO a la categoría “Móviles“, ni a “Samsung Galaxy S6“, ni a la página de inicio de la tienda. Todos estos casos son molestos para el usuario y Google los valora como un error soft-404. Hay que elegir la solución que menos perjudique al usuario.
2.1) Creación de los 301 en PHP, Apache, NGNIX, Lightttpd o IIS
La creación de los 301 es simple, igual si usamos PHP o .htaccess en servidores Apache, u otras alternativas como NGNIX, Lighttpd o IIS. Siguiendo nuestro ejemplo, www.dominio.es/producto?p=1&sID-Tag=Navidad -> www.dominio.es/navidad/ veamos cómo se hace:
a) Con PHP se introduce el código directamente en el documento del documento antiguo, en nuestro caso, www.dominio.es/producto?p=1&sID-Tag=Navidad, para redirigir al nuevo:
<?php header("HTTP/1.1 301 Moved Permanently"); header("Location: http://www.dominio.es/navidad/"); header("Connection: close"); ?>
Así, se entrega el código de estado “301 Movido Permanentemente“ y se redirige al nuevo contenido.
b) Con Apache hay que asegurarse de que el modo mod_rewrite esté activado. La mayoría de proveedores ofrecen un paquete que incluye .htaccess en el cual se puede introducir:
RewriteEngine On Redirect 301 /producto?p=1&sID-Tag=Navidad http://www.dominio.es/navidad/
El comando “RewirteEngine On“ comunica el modo mod_rewrite al servidor Apache. Después se define el código de estado, “Redirect 301“. Por último se define la ruta a modificar y separando con un espacio, se introduce el destino definitivo.
Para el resto de servidores, la cosa no es tan fácil para principiantes como yo, así que os dejo unas guías más completas:
c) Definir un 301 Redirect para servidores NGINX
d) Definir un 301 Redirect para servidores Lighttpd
e) Definir un 301 Redirect para servidores IIs
2.2) Informar a Google de los cambios
Una vez llevada a cabo la migración se debe crear un sitemap en HTML o XML y subirlo a Google Search Console. Después se tiene que hacer uso de “Rastreo > Explorar como Google“ para informar al buscador de los cambios realizados.
3) Control: Control de los redireccionamientos y sus parámetros
Una vez realizada la migración hay que controlar los redireccionamientos y su éxito. Haciendo uso de Google Analytics se puede controlar si ha habido una perdida de tráfico orgánico significativa o no, como también si las visitas a través de las redes sociales son satisfactorias.
El Índice de visibilidad de SISTRIX también indicará si las medidas han tenido éxito para el buscador Google o no. Una forma de ahorrar tiempo y esfuerzos es observado si han habido perdidas o descensos en el raking de Google. En “Cambios en el raking“ podemos ver rápidamente si las palabras claves más importantes son accesible para el usuario y para el buscador. Pulsado sobre el recuadro con la flecha anterior a la URL podemos comprobar su estado:
Creando un proyecto en optimizer para rastrear todo el dominio, se pueden reconocer los problemas del dominio. Una vez rastreado el sitio Web deseado, se debe ir a “OnPage > Errores“ y ver los errores más graves del dominio. En este ejemplo podemos ver que el rastreador de SISTRIX encontró en 25 HTMLs que poseen el enlace www.planeta.es/en/about-us que no lleva a ninguna parte porque ha sido eliminado.
Pulsando sobre “Verificar“ se puede obtener toda la información del documento HTML:
Pulsando sobre “HTML“ en el Menú, se puede ver el código fuente. En la línea 179 se encuentra en enlace roto:
Otras herramientas gratis:
SeeRoobts: Útil para identificar las páginas que deseamos que el buscador Google indexe o no. Esta herramienta fue desarrollada por Andre Alpar, uno de sus trabajos más famosos fue Zalando, además fue ponente en SEOPro de Madrid.
Redirect Path de Ayima: Ideal para controlar los códigos de estado.
Y por último, si se poseen varios dominios de la misma marca pero en diferentes formas de escritura, por ejemplo, los dominios IDN, estos deben ser redireccionados también con 301-redirect al dominio principal y no hacer uso del código de estado 302-redirect, sino hay necesidad.
¡Espero que os sea útil y que os haya gustado!