Guía de migración de sitio web 2018: estrategias SEO, proceso y verificación

Descubre paso a paso Como hacer una migración Web de forma exitosa

Índice del post

Guia de migracion web 2018

En la siguiente guía serán explicados todos los aspectos que tienen que ver con la migración de sitios web, desde las estrategias respecto a SEO, el proceso para llevarlas a cabo y su verificación para conocer e interpretar los resultados. Por supuesto, antes de abordar tan complejas cuestiones conocer de qué se trata en sí la migración de sitio web en verdad resulta de mucho valor.

¿En qué consiste la migración de sitios web?

De manera concreta, una migración de sitio web es un término usado de modo frecuente en ámbito de SEO profesional, para describir cualquier evento donde una página en línea atraviesa cambios sustanciales en áreas que pueden afectar su visibilidad, específicamente en lo que respecta a resultados en motores de búsqueda.

Típicamente, los cambios significativos que pueden tener las páginas web se refieren a la estructura del sitio, contenido, código, rendimiento general y concreto, así como de interfaz UX y otras tecnologías y plataformas involucradas.

De acuerdo a dicho tema de la migración de sitios web, la documentación de Google no lo cubre de manera profunda, incluso subestimando el hecho que a menudo dichas migraciones resultan en pérdidas significativas de tráfico y beneficios, lo que puede prolongarse desde semanas a varios meses dependiendo de la magnitud en la cual se han visto afectados las señales de ranking en los motores de búsqueda.

También, en cuanto a las pérdidas de tráfico y otros efectos que tiene la migración de sitios web, se debe tener en cuenta un plan de recuperación y cuánto le llevaría hacer que la página recupere su actividad normal, así como sus resultados positivos pertinentes en los motores de búsqueda.

Contenido de la guía:

  • Ejemplos de migración de sitios web
  • Tipos de migración de sitios web
  • Trampas comunes de la migración de sitios web
  • Proceso de migración de sitios web
  1. Enfoque y planeación
  2. Preparación de pre-lanzamiento
  3. Prueba de pre-lanzamiento
  4. Acciones a la hora del lanzamiento
  5. Pruebas post-lanzamiento
  6. Revisión de rendimiento
  • Apéndice: Herramientas útiles

Ejemplos de migración de sitios web

En la siguiente sección de la guía se discutirá cómo lucen las migraciones de sitio web exitosas e infructuosas, explicando también cómo podría resultar de manera cien por ciento segura salir de una migración de sitio sin tener que sufrir pérdidas significativas.

Desmitificando el mito de “expectativa de caída de tráfico”

Cualquiera que haya estado involucrado con una migración de sitio web, de manera segura ha escuchado la teoría esparcida sobre que la misma resultará en pérdida de tráfico y beneficios. Pues, aunque dicha afirmación tiene algo de realidad para algunos casos específicos, como por ejemplo cambiarse de dominio establecido a uno completamente nuevo, tampoco es que tal asunto deba tomarse como permanente.

De hecho, es completamente posible migrar de sitio web sin sufrir ningún tipo de tráfico o beneficios, incluso pudiéndose disfrutar de gran crecimiento luego de relanzar el sitio web. No obstante, dicha meta sólo puede lograrse si se siguen cada uno de los pasos que se han planeado y ejecutado con cuidado.

Ejemplos de migraciones de sitio web sin éxito

El siguiente gráfico muestra la negativa migración de sitio de una gran empresa, donde la página web perdió el 35 por ciento de su visibilidad luego de pasar de HTTP a HTTPS. En este sentido le tomó casi seis meses recuperarse de manera completa, teniendo un gran impacto en el mercadeo, beneficios e influencia de la empresa en cuanto a resultados orgánicos en motores de búsqueda.

Así que, dicho gráfico es un ejemplo típico un migración de sitio pobre posiblemente causada por un poca o nula planeación, así como implementación, puesta en arranque y evaluación.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 1

Incluso, puede ser peor aún y hacerse a recuperación del sitio completamente imposible, como muestra el gráfico de abajo sobre otra empresa donde se pasó de HTTP a HTTPS, lo que significó en una pérdida de visibilidad en resultados de motores de búsqueda de hasta un 20 por ciento permanentemente, incluso luego de haber pasado más de 6 meses de la migración.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 2

Del mismo modo, es completamente posible cambiar de HTTP a HTTPS sin perder mucho tráfico y por un largo periodo, aparte de las primeras semanas donde de manera inevitable hay una gran volatilidad, al Google notar las nuevas direcciones URL y realizar la actualización de los resultados de búsqueda.

Ejemplos de migraciones de sitio web exitosas

La manera en cómo debería lucir una migración de sitio web exitosa depende en gran parte del tipo de migración aplicada, sus objetivos y también su KPI relacionado (concepto que se explicará más adelante). Aunque, en la mayoría de los casos una migración de sitio web exitosa muestra al menos una de las siguientes características:

  • Pérdida mínima de visibilidad durante las primeras semanas (meta a corto plazo)
  • Crecimiento de la visibilidad luego de las semanas iniciales, dependiendo del tipo de migración aplicada (meta a largo plazo)

El siguiente reporte de visibilidad se tomó de una migración de sitio web de plataforma HTTP a HTTPS, el cual también se llevó a cabo con mejoras significativas en los tiempos de carga de la página en cuestión.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 3

Como ocurre usualmente con los proyectos de migración de sitio web, la fecha de lanzamiento se tiene que atrasar algunas veces debido a riesgos de lanzar la nueva página de manera prematura, así como luego de que obstáculos técnicos mayores sean completamente abordados y solucionados.

Pero, como se puede observar en el gráfico de visibilidad de abajo la espera siempre vale la pena, ya que la visibilidad en resultados orgánicos de búsqueda no solamente no cayó, sino que de hecho empezó a crecer desde la primera semana (como de hecho no cabría esperar en la mayoría de los casos donde la meta a corto plazo sería mantener estable la visibilidad).

Por ejemplo, el crecimiento en visibilidad se incrementó un mes después que la migración alcanzó el 60 por ciento, mientras que el tráfico orgánico luego de dos meses de lanzamiento excedió el 80 por ciento.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 4

Esta fue una migración bastante compleja ya que el sitio web nuevo fue rediseñado y hecho desde cero, cambiándose a una nueva plataforma con taxonomía de página mejorada que incluye nuevas páginas de inicio, estructura URL actualizada, numerosas redirecciones para preservar la equidad de enlaces más un cambio de la plataforma HTTP a HTTPS.

En general, introducir demasiados cambios al mismo tiempo puede ser algo complicado, ya que si algo sale mal se pasará un buen tiempo y muy mal rato averiguando qué es exactamente lo que está fallando. Aunque al mismo tiempo, dejar cambios mayores para después tampoco es ideal ya que requerirá más recursos, teniendo mejor relación costo-beneficio hacer muchos cambios positivos al mismo tiempo, si se sabe lo que se hace y se planea.

Antes de entrar en los asuntos esenciales sobre cómo se puede convertir un proyecto complejo de migración de sitio web en un gran éxito, es importante conocer y repasar los principales tipos de migración de sitio, así como también explicar y abordar las razones por las cuales muchas migraciones fallan en relación a su cometido principal; mejorar la visibilidad de la página web y su funcionamiento general.

Tipos de migración de sitio web

Hay muchos tipos de migración de sitio web, dependiendo de manera básica en la naturaleza de los cambios que se llevan a cabo en la página original, sus propósitos y métodos para elevar la visibilidad y rendimiento en línea.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 5

Por ejemplo, la documentación de Google mayormente cubre migraciones con cambios en cambios en la ubicación del sitio, los cuales están categorizados de la siguiente manera:

  • Reubicación del sitio con cambios en la dirección URL
  • Reubicación del sitio sin cambios en la dirección URL

Migración de ubicación de sitio

La migración de ubicación de sitio web ocurre de manera frecuente cuando un sitio cambia a una URL diferente, debido a cualquiera de las siguientes razones:

  • Cambio de protocolo: ocurre cuando una página web modifica o cambia sus protocolos de ubicación, siendo un ejemplo claro y clásico actual la migración de la plataforma HTTP a HTPPS, debido a mayor rendimiento, visibilidad en los resultados de búsqueda y actualización general del sitio para mejorarlo.
  • Cambio de sub-dominio o sub-carpeta: modificación muy común respecto a SEO internacional cuando un negocio decide mover uno o más ccTLDs (dominio de nivel superior por código de país) en subdominios o sub-carpetas.

De la misma manera, otro ejemplo común es donde un sitio móvil que se basa en un sub-dominio o sub-carpeta separada se hace responsivo, respecto a ambas plataformas existentes tanto móviles como de escritorio o equipos locales, teniendo direcciones URL uniformes para lograr tal cometido.

  • Cambio de nombre de dominio: un cambio de dominio ocurre usualmente cuando un negocio o empresa está siendo modificada en cuanto al nombre, por lo que su dominio debe cambiarse para que corresponda con el nuevo.
  • Cambio de dominio de nivel superior: dicho cambio resulta muy frecuente y común cuando un negocio decide lanzar sitios en línea internacionales, necesitando moverse de un ccTLD o dominio de nivel superior por código de país, a un gTLD o dominio de nivel superior genérico y viceversa. Por ejemplo, pasar a llamar un sitio web de una empresa de .eu a .com o de .com a .eu, teniendo alcance internacional y mundial.

Cambios en la estructura del sitio

Los cambios en la estructura del sitio involucran modificaciones en la arquitectura de la página, los cuales usualmente afectan el enlazamiento interno del mismo o links, así como también la estructura URL.

Del mismo modo, hay otros tipos de migraciones que se activan cuando ocurren cambios en el contenido del sitio, estructura, diseño, plataformas y protocolos en los que se basa, como por ejemplo:

  • Cambio de plataforma: este es el caso cuando un sitio pasa de una plataforma o CMS a otra, como por ejemplo sería cuando una página cambia su plataforma base de WordPress a Magento, así como simplemente pasar a la última versión de los mismos a la que pertenezca.

También, un cambio de plataforma puede en muchos casos resultar en cambios de dirección URL por las limitaciones técnicas que ocurren al cambiar plataformas, siendo la principal razón por la cual modificar plataformas signifique tener un sitio web completamente distinto al previo.

  • Migraciones de contenido: grandes cambios de contenido como reediciones, consolidación de contenido o depuración del mismo puede tener un gran impacto en la visibilidad del sitio en los resultados de búsqueda orgánicos, dependiendo de la escala del cambio. Asimismo, dichos cambios de manera frecuente pueden afectar la taxonomía de la página web, navegación y enlazamiento interno o links.
  • Cambios de configuración móvil: con tantas opciones disponibles en cuanto a cambios de configuración móvil de un sitio web, activando la indexación de apps, construir un sitio AMP o una página PWA pueden ser considerados también como migraciones parciales, sobre todo cuando una página web existente se reemplaza con una aplicación, AMP o PWA.
  • Cambios estructurales: los cambios de estructura usualmente son causados por grandes cambios en la taxonomía del sitio que impacta de gran manera en la navegación de la página, enlazamiento interno o links, así como en el rendimiento del sitio al ser utilizado por los usuarios.
  • Rediseños del sitio: los cambios en el diseño de una página web pueden variar, al ser desde modificaciones mayores en el aspecto e interfaz hasta convertirse en un sitio completamente nuevo, el cual también puede incluir material multimedia significativo, código y otros cambios.
  • Migraciones híbridas: existen muchísimas migraciones híbridas o mixtas que pueden combinarse entre sí prácticamente de cualquier modo posible. Claro, a más cambios se introduzcan al mismo tiempo se incrementa la complejidad y por lo tanto los riesgos.

Aunque, si bien hacer muchos cambios al mismo tiempo eleva los riesgos y la complejidad de la migración de sitio y de que algo salga mal, de la misma manera dicho método resulta ser mejor en cuanto a costo-efectividad, desde una perspectiva del uso de recursos y si las migraciones se planean y ejecutan de buena forma.

Trampas comunes de la migración de sitios web

Aunque cada migración de sitio es diferente hay algunos temas comunes detrás de los desastres más típicos en relación a la migración de páginas web, gracias a problemas de distinta índole que van desde la poca planificación o inconvenientes propios, hasta fallos causados por falta de recursos.

Razones por las cuales la migración de sitio falla

Poca o nula estrategia (Objetivos no claros o poco realistas) Involucramiento tardío
Poca o nula planificación Poco o nulo testeo o puesta a prueba
Falta de consulta especializada en SEO y UX Respuesta lenta a resolución de problemas y fallos
Falta de recursos o presupuesto Subestimación de escala

 

A continuación se repasarán algunas de las razones por las cuales migración de sitio web suele fallar, lo cual puede significar en el efecto contrario al propósito por lo cual se hace la migración, disminuyendo la visibilidad en los resultados en motores de búsqueda, así como bajo rendimiento y otras consecuencias. Dichas causas comunes de falla en migración de sitio son:

Estrategia nula o pobre

Algunas migraciones de sitio están condenadas a fallar desde su concepción y mucho antes de que el nuevo sitio sea lanzado. Y es que, una estrategia que está basada y construida sobre objetivos poco claros y nada realistas probablemente no tendrá éxito, siendo sus posibilidades muy pocas o casi nulas.

En este sentido, establecer objetivos realistas y medibles es esencial para conocer los resultados exactos de la migración y su post-lanzamiento. Asimismo, para la mayoría de las migraciones de sitio el objetivo principal es debe ser la retención e incluso incremento del tráfico actual de la página, así como de los beneficios y sus niveles.

En ciertos casos, la barra puede establecerse más alto pero en general anticipar o prever crecimiento debe ser un objetivo secundario, ya que de ese modo se ayuda a evitar tener expectativas poco realistas que luego llevarán a la falla completa de la migración, e incluso del sitio web y su tráfico y beneficios de manera permanente.

Planificación deficiente o inexistente

Realizar un plan o proyecto detallado tan pronto como sea posible ayudará a evitar retrasos en el camino, siendo un factor que ahorrará tiempo y valiosos recursos en todos los ámbitos, respecto a circunstancias inesperadas que de seguro van a presentarse en el camino.

De hecho, no importa que tan bien pensado, planificado y detallado sea el proyecto a llevar a cabo, es muy poco probable que todo vaya de acuerdo a lo planeado sin complicaciones, por lo que se debe ser flexible en cuanto a lo que se previó y aceptar la inserción de cambios, así como de posibles retrasos debido a diversas cuestiones e inconvenientes.

Para ello, se puede realizar un mapa sobre todas las dependencias y posibles cambios o factores que pueden presentar inconvenientes, para luego hacérselos saber a todos los involucrados en el proyecto.

Así, se debe evitar el lanzamiento del sitio cerca de los picos estacionales de la empresa, ya que si algo sale mal no habrá tiempo de rectificar las fallas o inconvenientes presentados. Por ejemplo, los negocios deben evitar lanzar un sitio cerca a los meses de septiembre u octubre, para evitar poner en riesgo la ocupada temporada de pre-navidad y navidad como tal.

En este caso, sería muchísimo más sensato lanzar el sitio durante los meses más tranquilos de la estación de verano, aunque eso depende del negocio y el servicio o producto que venda, lo cual hace que cada pico estacional de una empresa sea distinto.

Carencia de recursos

Antes de llevar a cabo un proyecto de planeación y realización de una migración web, se debe estimar el tiempo, esfuerzo y recursos requeridos para hacer que sea un éxito. Ahora, si el presupuesto es limitado se debe estudiar si vale la pena o no hacer la migración, en cuanto a la probabilidad de que falle en alcanzar sus objetivos establecidos y cause pérdida de beneficios.

Como regla, se debe incluir un excedente de al menos un 20 por ciento total del presupuesto en recursos adicionales, en relación a lo que se planeó en primera instancia sobre los gastos que requerirá el proyecto.

Concretamente, el excedente mencionado anteriormente permitirá luego abordar y solucionar cualquier problema que aparezca, asegurando un poco más el éxito de la migración. Por otro lado, si los recursos son muy apretados y se empieza a recortar en varios factores en ésta parte temprana de la migración, la misma puede ponerse en riesgo en gran manera y jugar en contra del negocio que la lleva a cabo si se realiza sin los recursos adecuados.

Falta de consulta SEO y UX

Cuando se están llevando a cabo cambios en una página web, cada decisión que se tome deber ser consultada desde el punto de vista de UX y SEO. Por ejemplo, remover grandes cantidades de contenido o enlaces para mejorar UX, sin duda alguna puede dañar la habilidad y capacidad del sitio de enfocar palabras clave críticas del negocio, así también significando caída en los lugares en el ranking de motores de búsqueda, entre otros problemas.

Por otro lado, tener mucho texto escrito y pocas imágenes puede tener un impacto negativo en el interés del usuario, dañando las conversiones de la página web y afectando en general su visibilidad y crecimiento. Por eso, más bien se recomienda mantener contenido e imágenes balanceadas y siempre consultar con SEO y UX los cambios en un sitio web.

Y es que, para evitar riesgos siempre se debe contar con expertos en SEO y UX para consultar los cambios y las posibles consecuencias en la página en cuestión, quienes podrán expresar su conocimiento a los interesados en el aspecto en línea del negocio o empresa, así como si los cambios y sus consecuencias a sufrir valen la pena para dicha empresa.

Interés o implicación tardía

Las migraciones de sitios web pueden tomar varios meses, así como requerir mucha planeación y tiempo de sobra para realizar pruebas. En ese sentido, es muy arriesgado buscar apoyo profesional de manera tardía, ya que al llevar a cabo la migración sin supervisar puede haber problemas o pasos cruciales mal o no llevados a cabo.

Falta de pruebas pertinentes

En adición a una buena estrategia y plan bien pensado y elaborado, se debe dedicar tiempo y esfuerzo a pruebas profundas de rendimiento y otros factores antes de lanzar el sitio. De hecho, es mucho más preferible retrasar el lanzamiento si las pruebas han identificado problemas críticos existentes, en vez de acelerar y apurar el proceso de manera descuidada.

Es decir, jamás se debe lanzar un sitio web sin el previo estudio y pruebas parciales previas que demuestren su buen funcionamiento y no existencia de problemas, sobre todo corroboradas por expertos SEO y de UX, permitiendo ahorrar recursos y tiempo y problemas mayores al lanzar una página que aún no está lista para mejorar tráfico y beneficios, sino que incluso puede empeorarlos.

De la misma manera, la atención a cada aspecto y sobre todo a los pequeños detalles es también muy importante, por lo que debe asegurarse que los desarrolladores sepan muy bien sobre los riesgos asociados a la implementación pobre o ineficiente. Así que, educar a los desarrolladores sobre el impacto directo de su trabajo en el tráfico de un sitio, y por lo tanto beneficio es crucial y puede marcar una gran diferencia.

Lenta respuesta para corregir errores

De manera segura siempre habrá errores o bugs para corregir una vez que el sitio web nuevo se lanza. Sin embargo, algunos errores o fallas son más importantes e influyentes que otros y requieren inmediata atención en comparación a los de menor impacto.

Por ejemplo, si se lanza el sitio nuevo y se encuentra que las arañas de los motores de búsqueda tienen dificultades para rastrear e indexar el contenido de la página, dicha falla requerirá atención y solución inmediata para no afectar el sitio de manera negativo en los resultados de ranking de los motores de búsqueda.

Y es que, desde una lenta respuesta hasta una falla técnica mayor puede algunas veces ser catastrófico, tomando muchísimo tiempo para recuperar los daños que pueden ocasionar respecto a visibilidad y lugar en el ranking de Google.

Subestimación de escala

Los inversores, responsables y dueños de negocios y empresas de manera frecuente no anticipan que las migraciones de sitio consuman tanto tiempo y recursos. De hecho, no es muy común que los inversores mayores demanden que el nuevo sitio web sea lanzado el día planeado previamente, a pesar de que se encuentre listo al cien por ciento o no.

En este sentido, el lema “lancemos el sitio ASAP y arreglemos luego” es un error clásico, no obstante lo que la mayoría de los inversores no saben es que dicho movimiento puede tomar varios días para que la visibilidad de búsqueda orgánica se estabilice, aunque la recuperación total puede tomar varios meses.

Por eso, es la responsabilidad del administrador del proyecto consultante educar a los clientes, aclarando todas las diferentes fases y escenarios posibles que pueden presentarse, explicando también los detalles concretos de cada uno de ellos. De esta manera, los inversores y dueños de negocios están más informados y pueden tomar decisiones más certeras, teniendo expectativas mucho más realistas y sencillas de manejar.

Proceso de migración de sitios web

De manera concreta, el proceso de migración se puede dividir en seis fases esenciales principales, siendo cada una de ellas muy importante y significando el fracaso de la migración si al menos una se omite, ya que son un conjunto unido que se entrelaza para hacer que cada fase se lleve a cabo y permita pasar a la siguiente de modo correcto.

Fase 1: Enfoque y planeación Fase 2: Preparación de pre-lanzamiento Fase 3: Pruebas de pre-lanzamiento Fase 4: Actividades de día de lanzamiento Fase 5: Revisión post-lanzamiento Fase 6: Revisión de rendimiento
Objetivos Revisión de cuadro de trabajo Revisión de contenido, Revisión técnica Acciones de lanzamiento del sitio Comprobaciones y acciones post-lanzamiento Priorización de actividad BAU
Riesgos, oportunidades de crecimiento, previsión de escenarios Especificación técnica de SEO Prueba de redirecciones Prueba del sitio en tiempo real Revisión de corrección de errores Rendimiento del sitio migrado
Estrategia Identificación de páginas prioritarias Evaluación de riesgo del lanzamiento del sitio Soporte de medios pagados Monitoreo de rendimiento Reportes
Plan de proyecto Plan de contingencia Pruebas de rendimiento

 

Fase 1: enfoque y planeación

En primer lugar, cuando se trata de migración al empezar se debe diseñar un enfoque y planeación para saber que se quiere lograr, las maneras de hacerlo, tiempo estipulado y otras cuestiones relacionadas, teniendo así al menos una perspectiva teórica para llevar a cabo. A continuación, los pasos a seguir para iniciar la fase 1 son:

Trabajar en el enfoque del proyecto

Sin importar las razones detrás de un proyecto de migración de sitio web, se requiere estar completamente claro sobre los objetivos a lograr desde el principio, ya que éstos ayudarán a establecer y administrar las metas reales con las expectativas.

Por ejemplo, mover un sitio web de HTTP a HTTPS es muy diferente a realizar un recorrido y cambio total o parcial de una página, porque ambos tienen objetivos muy diferentes. En primera instancia, el objetivo debe ser retener y mantener los niveles de tráfico del sitio, cuestión que al lograrse se pasa al segundo objetivo de lograr que dicho tráfico se incremente.

Asimismo, una migración de sitio es una gran oportunidad para abordar y solucionar problemas heredados o preexistentes, siendo recomendable incluir todos los posibles en el enfoque del proyecto, debiendo tener mucho balance en cuanto a costo-efectividad, ya que abordar dichos problemas luego del lanzamiento del sitio web requerirá muchos más recursos y tiempo de manera significativa.

Sin embargo, en cada caso se identificará los aspectos más críticos para que el proyecto sea exitoso, cómo reconocer todos los riesgos que pueden resultar en un impacto negativo en la visibilidad del sitio en los rankings de motores de búsqueda, considerando al mismo tiempo cuales son las precauciones que se deben tomar.

De manera ideal, realizar una planificación de escenarios anticipados basado en los diferentes riesgos y oportunidades de crecimiento es muy recomendable. Ahora, cabe destacar que los escenarios anticipados deben ser preparados y realizados por consultantes y expertos en migración de sitios web con amplia experiencia en el campo.

Al mismo tiempo, incluir a tantos inversores posibles en esta etapa temprana de la migración ayudará a adquirir un mayor conocimiento, en relación a los más grandes desafíos y oportunidades entre las divisiones. Es decir, pedir recomendaciones al equipo SEO, de contenido, UX y de analíticos se aconseja bastante, juntando así una lista de las mayores oportunidades y problemas más prioritarios.

Luego, se necesita trabajar en el potencial ROI y abordar cada uno de los que aparezcan. Finalmente, se escogerá una de las opciones disponibles basado en los objetivos y recursos a mano, lo cual formará la estrategia  de migración del sitio web a modificar.

Ahora, debe restar realizar una lista de actividades prioritarias a llevar a cabo, las cuales se esperan tenga un ROI positivo si se implementan. Después, dichas actividades y ROI deben ser discutidas y comunicadas a los inversores, para establecer así enfoques y metas realistas de acuerdo al proyecto, también con las expectativas correctas.

Preparar el proyecto y planificación

La planeación resulta igualmente importante porque las migraciones de sitio son usualmente proyectos complejas, los cuales fácilmente pueden requerir varios meses para mostrar resultados.

Durante la fase de planificación, cada tarea necesita un dueño o ejecutante; consultante SEO o de UX, editor de contenido o desarrollador web son grandes ejemplos, así como una fecha de entrega establecida para cada cosa por hacer.

Del mismo modo, cualquier dependencia debe ser identificada e incluida en el pan de proyecto para que todos estén conscientes de cualquier actividad que no se pueda llevar a cabo, gracias a que son dependientes de otros. Por ejemplo, las redirecciones no se pueden probar a menos que el mapeo de redirecciones haya sido completado, así como que las mismas hayan sido implementadas en la plataforma.

Es decir, el plan de proyecto debe ser compartido con cada persona involucrada tan pronto como sea posible, para que haya suficiente tiempo para discutir cambios, modificaciones, ideas y aclaraciones. De la misma manera, cada actividad requiere ser descrita en gran detalle para que los inversores estén al tanto de cada tarea que debe llevarse a cabo, así como los tiempos que requieren y los recursos a utilizar.

Cabe destacar, el manejo y control del proyecto debe ser perfecto y sin fallas para organizar y llevar a cabo las actividades requeridas, de acuerdo al horario y planificación realizadas.

Por otro lado, una parte importante y crucial del plan o proyecto es tener una fecha anticipada de lanzamiento del sitio web nuevo que sea precisa. De modo ideal, la nueva página debería ser lanzada en un tiempo donde el tráfico más bien sea bajo. Ya que, se debe evitar lanzar el sitio durante picos o periodos fuertes, teniendo graves consecuencias si las cosas no salen como se planearon.

Finalmente, una cuestión a considerar es que como la mayoría de veces las migraciones de sitios web no salen como se planearon al principio, se requiere un grado de flexibilidad para realizar cambios, esperar situaciones adversas y demás recomendaciones para que dicha migración se lleve a cabo de manera exitosa, así se requiere posponerla, modificarla e incluso replantearla.

Fase 2: preparación del pre-lanzamiento

La preparación del pre-lanzamiento son las actividades que necesitan llevarse a cabo mientras el nuevo sitio web está siendo desarrollado.

Asimismo, en este punto los requerimientos de las estrategias SEO del nuevo sitio web ya deberían saberse y estar sobre la mesa, así como también lo que respecta a la función de los diseñadores y arquitectos de información, dando información sobre prototipos y cuadros de trabajo antes del que sitio sea accesible a los usuarios.

Revisión de cuadros de trabajo o prototipos

En cuanto a este aspecto, se debe realizar una revisión de los prototipos o cuadros de trabajo que están siendo desarrollados en la página web, e incluso antes de que los mismos sean aplicados para escoger los que mejor se adapten a las necesidades de la página web.

De la misma manera, revisar las plantillas principales del nuevo sitio web puede ayudar a identificar problemas en cuanto a SEO y UX en una etapa temprana, donde resulta ideal encontrarlos y solucionarlos de manera más sencilla y con menos recursos.

Por ejemplo, se puede conseguir que grandes porciones de contenido han sido removidas de las páginas de categorías, lo cual hace que sean marcados de manera inmediata e instantánea. Por otro lado, se puede descubrir que algunas páginas de tráfico alto no aparecen más en la navegación principal.

Es decir, cualquier tipo de cambio radical en el diseño o interfaz de las páginas deben ser profundamente estudiados, evitando así cualquier tipo de inconveniente de tipo SEO y también de funcionamiento general en la página.

Preparando las especificaciones técnicas de SEO

Una vez que los prototipos y cuadros de trabajo han sido revisados, se debe preparar una especificación técnica detallada en cuanto a SEO. En ese sentido, el objetivo de este vital documento es capturar todos los requerimientos esenciales de SEO que necesitan los desarrolladores, así como conocerlos y entenderlos antes de trabajar en el proyecto y su enfoque, en relación a términos de trabajo y costos.

Incluso, es durante esta etapa que el presupuesto se estima y dirige a cada aspecto del proyecto. Ahora, si los requerimientos SEO no están incluidos en este punto es imposible asignarlos luego, lo que resultaría en un gran problema en cuanto a planificación, ejecución y puesta en marcha del proyecto, migración y lanzamiento del nuevo sitio web.

Como se dijo anteriormente, las especificaciones técnicas de SEO deben ser muy detalladas aunque escritas de una manera que los desarrolladores puedan llevarlas a cabo, sin dar cabida a confusiones u otros inconvenientes. De hecho, esta guía no es un documento para explicar la razón de porque deben implementarse los pasos descritos, sino cómo hacerlo porque son importantes y críticos.

Concretamente, se debe asegurar en incluir requerimientos específicos que cubran necesidades SEO en diferentes áreas como:

  1. Estructura de dirección URL.
  2. Metadatos (incluyendo dinámicamente valores generados por defecto).
  3. Datos estructurados.
  4. Directivas canónicas y meta-robots.
  5. Copia y título.
  6. Navegación principal y secundaria.
  7. Enlazamiento interno o links (de cualquier forma).
  8. Paginación.
  9. Mapas de sitio XML.
  10. Mapas de sitio HTML.
  11. Hreflang (si hay sitios web internacionales).
  12. Configuración móvil (incluyendo aplicación, AMP o sitio PWA).
  13. Redirecciones.
  14. 404 page personalizada.
  15. JavaScript, CSS y archivos de imágenes.
  16. Tiempos de carga de página (para equipos móviles y de escritorio).

De la misma manera, las especificaciones deberían también incluir áreas relacionadas concretamente a funcionalidades CMS que permitan a los usuarios:

  1. Especificar direcciones URL personalizadas y derogar las establecidas por defecto.
  2. Actualizar títulos de página.
  3. Actualizar meta-descripciones.
  4. Actualizar cualquier título h1-h6.
  5. Añadir o enmendar la etiqueta canónica por defecto.
  6. Establecer los atributos de meta-robots para indexar, desindexar, seguir o no seguir.
  7. Añadir o editar el texto ALT de cada imagen.
  8. Incluir campos Open Graph para descripción, dirección URL, imagen, tipo y nombre del sitio.
  9. Incluir campos de Open Graph de Twitter para tarjeta, dirección URL, título, descripción e imagen.
  10. Ingresar o enmendar redirecciones.
  11. Actualizar el archivo Robot.txt.

También es importante asegurarse que al actualizar un atributo particular, como por ejemplo podría ser una h1, otros elementos no son afectados como el título de la página o cualquier menú de navegación.

Identificando páginas prioritarias

Uno de los más grandes desafíos con las migraciones de sitio web es que el éxito de la misma dependerá de la calidad y la cantidad de las páginas que han sido migradas. Por lo tanto, resulta muy importante que haya enfoque en las páginas que en verdad importan, siendo dichas páginas las que han dirigido tráfico hacia el sitio original, así como las que han generado enlaces, páginas que tienen buena conversión, entre otros.

Asimismo, para lograr llevar a cabo una identificación de páginas prioritarias de calidad, los tres pasos que sin duda se deben seguir son los siguientes:

  1. Rastrear el sitio de origen.
  2. Identificar todas las páginas que se pueden indexar.
  3. Identificar las páginas con mayor rendimiento.

 

Cómo rastrear el sitio origen

Rastrear el viejo sitio web de origen para que se puedan copiar todas las direcciones URL, títulos de páginas, metadatos, encabezados, redirecciones, enlaces rotos, entre otros es muy recomendable. Ahora, sin importar qué aplicación de rastreado se use, hay que asegurarse de que dicho rastreado no sea muy restrictivo o prohibitivo, cuestión que se puede evitar prestando atención a la configuración del rastreador antes de buscar el sitio origen, considerando si:

  1. Ignorar los archivos robots.txt (en caso de que algunas partes vitales del sitio sean bloqueadas por accidente)
  2. Seguir enlaces internos de “nofollow” (para que el rastreador alcance muchas más páginas)
  3. Rastrear todos los subdominios (dependiendo del enfoque)
  4. Rastrear fuera de la carpeta de inicio (dependiendo del enfoque)
  5. Cambiar el agente de usuario a Googlebot (equipo de escritorio)
  6. Cambiar el agente de usuario a Googlebot (equipo móvil o teléfono inteligente)

Como consejo profesional, mantener una copia de los datos de rastreo del sitio web previo ya sea en un archivo local o en la nube es recomendable, así pase un tiempo prudente o meses luego de que la migración de sitio se haya completado. Dicha recomendación sirve en caso de necesitar los datos del viejo sitio por cualquier razón, una vez que la nueva página está a bordo y funcionando.

Cómo identificar las páginas que se pueden indexar

Una vez que el rastreo está completo, se debe trabajar en identificar las páginas indexadas del sitio origen, siendo todas ellas páginas escritas en lenguaje HTML con las siguientes características:

  1. Regresar una respuesta a 200 servidores.
  2. O no tener etiqueta canónica o tener una dirección URL canónica a nombre de sí misma.
  3. No tener meta-robots no indexados.
  4. No ser excluidas de los archivos robots.txt.
  5. Estar enlazadas internamente con otras páginas (páginas no huérfanas).

De modo específico, las páginas con posibilidad de indexarse son las únicas que tienen el potencial de llevar tráfico al sitio, por lo tanto las mismas requieren ser priorizadas para el propósito de la migración de sitio web que llevaría a cabo cualquier empresa, negocio o persona interesada.

Por lo tanto, dichas páginas indexadas valen la pena optimizarse si es que van a estar presentes en el nuevo sitio, así como ser redirigidas si es que no van a estarlo.

Cómo identificar las páginas con más rendimiento

Unas vez que se han identificado todas las páginas que se pueden indexar, ahora podría haber la posibilidad de llevar a cabo más trabajo, especialmente si el sitio origen consiste en un gran número de páginas, ya que optimizarlas o redirigirlas todas resulta casi imposible a relación a factores cruciales como el tiempo, recursos, asuntos técnicos y demás asuntos.

Por lo que, sí resulta ser el caso de tener un amplio sitio destino con muchas páginas que optimizar y re-direccionar, también es importante identificar las páginas con más rendimiento, lo cual ayudará a priorizar las páginas a enfocarse durante las fases siguientes, por lo tanto facilitando el trabajo de la migración en muchos sentidos como se explicará a continuación.

Así que, para llevar a cabo la identificación de las páginas con mayor rendimiento del sitio destino, lo que se recomienda es preparar una hoja de registro que incluya los siguientes campos nombrados más abajo, siendo los más cruciales en cuanto a este tema:

  1. Dirección URL de páginas del sitio destino (incluyendo las páginas que se pueden indexar de la data rastreados)
  2. Visitas orgánicas durante los últimos 12 meses (dato que se puede obtener con Google Analytics)
  3. Beneficio, conversiones y rango de la misma durante los últimos 12 meses (dato que se puede obtener fácilmente con Google Analytics)
  4. Vistas de página durante los últimos 12 meses (información que ofrece Google Analytics)
  5. Número de clics de los últimos 90 días (dato que se puede obtener a través de la plataforma Search Console)
  6. Top de páginas enlazadas (dato que ofrecen software como Majestic SEO o Ahrefs)

Con la realización de la hoja de registro con los datos anteriormente descritos, ahora será muchísimo más fácil identificar las páginas más importantes en las cuales enfocarse: las que generan numerosas visitas orgánicas, las que convierten de manera eficiente, las que contribuyen a tener beneficios, las que tienen un buen número de enlaces a dominios referentes, entre otros. Así, éstas son las páginas en las que se debe tener mayor enfoque para una migración exitosa.

En el mismo orden de ideas, las páginas con más rendimiento de manera ideal deberían estar presentes también en el nuevo sitio web, y si por alguna razón no lo están entonces deben ser redirigidas a la página más relevante, para que los usuarios que las requieren no caigan en el error 404 y la equidad de enlace que tuvieron previamente se mantenga en el sitio nuevo.

Por otro lado, si alguna de las páginas de mayor rendimiento deja de existir por alguna razón y no son redirigidas apropiadamente, los rankings del sitio web en los resultados mostrados por los motores de búsqueda y el tráfico serán afectados de manera negativa, teniendo un impacto tanto en los recursos como en la visibilidad.

Pruebas de rendimiento

Ahora, una vez que el lanzamiento del nuevo sitio web está cerca a la fecha programada, lo próximo a realizar es una prueba de rendimiento al sitio origen. Y es que, probar el rendimiento general y específico de varios aspectos es esencial, no solamente para comparar el rendimiento del nuevo sitio web con el anterior, sino para conocer de manera precisa que áreas funcionan con menor desempeño en dicho sitio, pudiendo así ser arregladas rápidamente.

Rastreo de ranking de palabras clave

Si no se rastrean los rankings del sitio web de manera frecuente, dicha tarea debe empezar a llevarse a cabo antes de que se lance el nuevo sitio web. De otro modo, será muy complicado luego averiguar si la migración salió bien y sin fallas, o si falló y cuáles fueron los motivos por los que pasó eso.

De la misma manera, el rastreo de ranking no se debe dejar para último en caso de que algo salga mal, siendo un tiempo ideal realizarlo al menos una semana antes para tener una idea, resultando beneficioso para comparar pros y contras de la migración y lanzamiento del sitio cuando se realice.

Claro, realizar un estudio de los rankings del sitio lleva tiempo, así como también realizar tareas que se relacionan con trabajar con palabras clave y cuáles son los más representativos, respecto de los resultados de visibilidad de la búsqueda orgánica del sitio, rastreándolos tanto en equipos de PC locales o de escritorio como dispositivos móviles.

Ya que, monitorear miles de combinaciones de palabras clave cortas, medianas o largas es usualmente poco realista, siendo la menor opción viable el monitorear palabras clave que llevan tráfico al sitio (palabras clave en ranking de página 1) y que tengan búsqueda decente enfocada en volumen corto, mediano y extenso.

Por otro lado, si se obtiene tráfico de palabras clave comerciales y no comerciales, se debe decidir también en qué tipos de palabras clave enfocarse más desde el punto de vista del rastreo. En general, palabras clave no comerciales tienen a ser más competitivas y volátiles, por lo que para la mayoría de los sitios tendría mucho sentido enfocarse en ellas de manera exclusiva.

Como asunto imperativo, no se debe olvidar monitorear los rankings relacionados a equipos locales o de escritorio y dispositivos móviles, haciendo que sea mucho más sencillo diagnosticar problemas luego de realizado el lanzamiento, respecto a problemas de rendimiento en cada tipo de dispositivo desde donde el usuario realiza la búsqueda.

Por ejemplo, si se recibe un alto volumen de tráfico de más de un país, considerar monitorear rankings de palabras clave en otros mercados es una muy buena idea también, ya que la visibilidad y resultados de búsqueda pueden variar de modo significativo de una nación a otra.

Rendimiento del sitio

Los tiempos de carga del sitio web Nuevo pueden tener un gran impacto tanto en el tráfico como en las ventas del negocio o empresa dueña. Por lo menos, muchos estudios han mostrado que mientras más tarde una página en cargar, el rango de rebote se incrementa, queriendo decir que el usuario intentando acceder al sitio simplemente lo cierra porque no le muestra información de manera rápida y eficaz.

Por eso, a menos que los tiempos de carga del sitio origen y su puntaje en cuanto a rendimiento sean guardados, en verdad será muy complicado atribuir cualquier pérdida de beneficio o tráfico relacionada al rendimiento del sitio una vez que se lanza, ya que virtualmente se hace imposible comparar datos si no se guardan de manera previa.

Por lo tanto, se recomienda que se revisen todos los tipos principales de páginas usando la herramienta de Google PageSpeed Insights y de Lighthouse. También, se pueden usar tablas de resumen como la que se encuentra más abajo para medir el rendimiento de algunas de las métricas de desempeño más importantes, las cuales serán útiles para comparar una vez que el sitio nuevo sea lanzado.

Móvil Velocidad Fcp Dcl Optimización Puntaje De Optimización
Página principal Rápida 0.7s 1.4s Buena 81/100
Categoría de página Lenta 1.8s 5.1s Media 78/100
Sub-categoría de página Promedio 0.9s 2.4s Media 69/100
Página de producto Lenta 1.9s 5.5s Buena 83/100

 

Datos de rastreo del sitio previo

Unos días antes de que el nuevo sitio reemplace al anterior, se recomienda hacer un rastreo del sitio previo, ya que al hacerlo en verdad podría ser muy importante en expectativa de problemas de optimización de la nueva plataforma. Por lo que, un rastreo final permitirá guardar valiosa información sobre los títulos del sitio web anterior, meta descripciones, encabezados h1-h6, estado de servidor, etiquetas canónicas, páginas “nofollow” o no indexadas, enlace, nivel, ETC.

Por lo tanto, tener toda la información anteriormente descrita podría significar ahorrar muchos problemas en el futuro, en cuanto a situaciones como que el nuevo sitio no esté aún bien optimizado o sufra desperfectos, así como malas configuraciones técnicas. También, guardar una copia del archivo robots.txt del sitio previo se recomienda, así como sus mapas de sitio XML en caso de que se necesiten luego.

Datos de Search Console

Considerar también exportar tanta información como sea posible respecto de los datos de Search Console del sitio previo es ampliamente recomendado. No obstante, dichos datos solamente están disponibles por un lapso de 90 días, por lo que hay probabilidades de que una vez el sitio nuevo sea lanzado los datos de Search Console del sitio anterior se borren tarde o temprano. La exportación de los datos que vale la pena incluye:

  1. Búsqueda de consultas y páginas de análisis.
  2. Errores de rastreo.
  3. Recursos bloqueados.
  4. Problemas de usabilidad móvil.
  5. Parámetros de direcciones URL.
  6. Errores de datos estructurados.
  7. Enlaces al sitio.
  8. Links internos.
  9. Estado de indexación.

 

Preparación de redirecciones

La implementación de redirecciones es una de las actividades más cruciales durante la realización de la migración de un sitio web, ya que si las direcciones URL del sitio web origen dejan de existir y no están re-direccionadas de manera correcta, los ranking del nuevo sitio y la visibilidad se irán por los suelos o se estancarán.

¿Por qué resultan tan importantes las redirecciones para las migraciones de sitio?

Sin duda, las redirecciones son extremadamente importantes para las migraciones de sitio porque ayudan tanto a los usuarios como a los motores de búsqueda a encontrar páginas que pueden ya no existir, que han sido renombradas o movidas a otra lugar o ubicación.

Desde el punto de vista del SEO, las redirecciones ayudan a los motores de búsqueda a encontrar e indexar las direcciones URL de un sitio web nuevo más rápido, así como también entender como las páginas del sitio previo se asocian con las del nuevo de muchas maneras.

Asimismo, dicha asociación le permitirá a las señales de ranking pasar de las viejas páginas a las nuevas, reteniendo dicho ranking sin que resulte una estrategia que afecte solamente de manera negativa.

¿Qué sucede cuándo las redirecciones no se implementan de manera correcta?

Cuando las redirecciones se implementan de manera pobre o incorrecta, las consecuencias sin duda pueden ser catastróficas y generar un sinfín de problemas que resultarán en gasto de recursos, pérdida de beneficios, tiempo y lo más grave; merma irreversible de tráfico y lugares en el ranking de los resultados mostrados por los motores de búsqueda.

Por ejemplo, al aplicar redirecciones incorrectamente los usuarios o caerán en errores 404 de “Página no encontrada” o en sitios que no corresponden con su búsqueda de manera precisa. En cualquier caso, los ratios de rebote y conversión del sitio en cuestión serán afectados de manera negativa, haciendo que la gente salga del sitio, no lo viste y también pierda enlaces.

En lo que respecta directamente a cómo trabajan los motores de búsqueda para encontrar y mostrar las páginas, implementar pobremente las redirecciones tiene de igual manera muy malas consecuencias. Por ejemplo, los buscadores no podrán asociar las páginas del sitio previo con las que están en el nuevo si las direcciones URL no son auténticas, por lo que las señales de ranking no pasaran encima del sitio previo al nuevo, significando pérdida de visibilidad y resultados.

En adición a eso, le tomará mucho más tiempo a los motores de búsqueda descubrir e indexar las páginas del nuevo sitio web, significando también en poca visibilidad y caída en los rankings de resultados, teniendo un efecto nefasto en lo que respecta a estrategia y propósito SEO.

¿Código 301 (redirecciones permanentes), código 302 (redirecciones temporales), redirecciones de JavaScript o meta actualización?

Cuando las direcciones URL entre la versión previa y más nueva del sitio son diferentes, se recomienda utilizar redirecciones de código 301 o permanentes, ya que éstas le indican a los motores de búsqueda indexar las nuevas direcciones URL, así como también dirigir cualquier señal de ranking de las direcciones URL anteriores a las nuevas.

Por lo tanto, se deben utilizar redirecciones 301 si el sitio se mueve desde y hacia otro dominio o subdominio, por ejemplo si se cambia de plataforma y protocolo HTTP a HTTPS o si el sitio o sus partes han sido reestructuradas.

Ahora, a pesar de algunas declaraciones de Google que dicen que las redirecciones de código 302 pasan por PageRank, indexar las nuevas direcciones URL serían más lento y tomarle mucho más tiempo a las señales de ranking ser pasadas del sitio previo al nuevo.

Por otro lado, las redirecciones de tipo 302 o temporales deben usarse solamente en situaciones donde una redirección no requiere ser permanente, y por lo tanto indexar la nueva dirección URL no resulta en una prioridad.

De manera concreta, con las direcciones de tipo 302 los motores de búsqueda inicialmente dudarán en indexar el contenido dirección URL redirigida destino y pasar cualquier señal de ranking a ella.

No obstante, si las redirecciones temporales permanecen durante mucho tiempo sin ser removidas o al menos actualizadas, las mismas pueden terminar comportándose de manera similar a las redirecciones de tipo 301 o permanentes. Por lo tanto, usar redirecciones de tipo 302 es aconsejable cuando es probable que la misma requiera actualizarse o ser removida en el futuro cercano, ya sea de país, lenguaje o redirecciones de dispositivos específicas.

En caso de las redirecciones de JavaScript o de meta actualización, las mismas es mejor evitarlas y no utilizarlas en ningún sentido, siendo mejor las anteriormente nombradas. Aunque, Google se está haciendo cada vez mejor en lo que respecta a rastrear JavaScript, aún no hay garantía de que serán descubiertas por el buscador o pasar por señales de ranking para el nuevo sitio web.

Redirección de proceso de mapeo

Si se es lo suficientemente afortunado para trabajar y llevar a cabo una migración que no involucre cambios en las direcciones URL, esta sección de la guía puede ser saltada. De otro modo y como es más probable, la lectura es necesaria al involucrar cambios de URL casi todas las migraciones, mostrando porqué páginas origen cualesquiera que no estarán disponible en la misma dirección URL luego de la migración deben ser redirigidas.

Específicamente, el archivo de redirección de mapeo es una hoja de cálculo que incluye las siguientes dos columnas: Dirección URL de sitio origen – una dirección URL de una página en el sitio anterior, así como Dirección URL del nuevo sitio web – una dirección URL de una página en el sitio nuevo.

Cuando se mapea (redirige) una página del sitio web al nuevo, siempre se debe intentar mapear a la página correspondiente más relevante. Ahora, en casos donde una página relevante no exista, es mejor evitar redirigir la página a la página principal del sitio.

Primero y más importante, redirigir usuarios a páginas irrelevantes resulta en una experiencia de uso muy pobre. De hecho, Google ha establecido que redirigir páginas “en masa” a sitios irrelevantes será considerado como errores 404, por lo que no tendrán ningún tipo de valor SEO y no tendrán ningún tipo de efecto, al menos de manera positiva.

Por lo tanto, si no se encuentra una página equivalente a la cual direccionar una existente porque no hay parecido o similitud, lo mejor es intentar mapearla e insertarla al menos en una categoría o diseñar contenido que se asemeje.

Una vez que el mapeo se completa, el archivo tendrá que ser enviado al equipo de desarrollo para que se creen las redirecciones, para que las mismas puedan ser probadas antes del lanzamiento de nuevo sitio. Sin embargo, la implementación de redirecciones es otra parte de la migración de sitios web donde las cosas usualmente pueden salir mal si no hacen de manera precisa.

Incrementando la eficiencia durante la redirección de proceso de mapeo

Redirigir el mapeo requiere gran atención a los detalles y necesita ser llevado a cabo única y exclusivamente por expertos SEO con mucha experiencia.

El mapeo de direcciones URL en sitios pequeños pudiera ser realizado en teoría de manera manual, al mapear cada dirección URL del sitio origen a una del nuevo sitio web.

Por otra parte, en sitios grandes que consisten en miles e incluso cientos de miles de páginas, mapear las direcciones URL de manera manual sería prácticamente imposible, por lo que se requiere de manera necesaria la automatización.

En el mismo orden de ideas, confiar en ciertos atributos comunes entre el sitio origen y el nuevo puede resultar en una gran ahorro de tiempo y recursos. Por ejemplo, dichos atributos pueden incluir los títulos de página, encabezados H1 u otros identificadores de página únicos como códigos de producto, SKU, entre otros.

Ahora, debe haber seguridad en que los atributos en los cuales se confía para la redirección de mapeo sean únicos y no se repitan a través de varias páginas, ya que de otro modo se tendrá como resultado un mapeo incorrecto que puede tener consecuencias negativas para el sitio.

Como consejo profesional, se debe asegurar que la estructura URL del sitio web nuevo esté completamente terminada antes de empezar a trabajar en la redirección del mapeo, ya que no hay nada más arriesgado que mapear direcciones URL que serán actualizadas antes de que el nuevo sitio web sea lanzado.

Por ejemplo, cuando las direcciones URL se actualizan luego que las redirecciones del mapeo se completan, se pueden presentar situaciones indeseadas con las cuales lidiar luego del lanzamiento del nuevo sitio, tales como redirecciones rotas, cadenas redirigidas y ciclos interminables de redirecciones.

En este sentido, un congelamiento de contenido debe ser puesto en el sitio anterior antes de la fecha de migración, para que haya así un punto de corte para el nuevo contenido que se publique en el sitio origen. De esta manera, se logra y asegura que no se perderán páginas de la redirección de mapeo y garantiza que todas las páginas del sitio anterior sean redirigidas.

No olvidar las redirecciones del sitio origen

Sin lugar a dudas, se deben mantener las redirecciones preexistentes del sitio web anterior y asegurar que se tomen en cuenta, en relación a preparar el mapeo de redirecciones para el nuevo sitio web. Si no se realiza lo expresado anteriormente, es probable que el archivo actual de redirecciones del sitio resulte sobreescrito por el nuevo en la fecha del lanzamiento.

Si dicha cuestión ocurre, todas las redirecciones heredadas del sitio origen que se pusieron anteriormente dejarán de existir, provocando que el sitio nuevo pierda una cantidad decente de enlaces, siendo la extensión de la cual depende de gran manera el volumen de redirecciones heredadas del sitio.

Por ejemplo, un sitio web que ha pasado por algunas migraciones previas en el pasado debería tener una buena cantidad de redirecciones heredadas puestas, las cuales nadie quiere que se pierdan por lo que podría significar luego en cuanto a pérdida de tráfico, enlaces y por lo tanto visibilidad en los rankings de búsqueda y funcionamiento general.

De modo ideal, se deben preservar tantas redirecciones heredadas como sea posible, asegurándose al mismo tiempo que las mismas no causarán ningún problema cuando se combinen con las redirecciones del nuevo sitio.

De la misma forma, se recomienda en gran manera eliminar posibles cadenas de redirecciones en este punto de inicio, lo cual puede llevarse a cabo de manera fácil al chequear ya sea que la misma URL aparezca tanto como “dirección URL heredada” y “dirección URL de sitio nuevo” en la hoja de cálculo de redirección del mapeo. En este caso, se necesitará actualizar la “dirección URL de sitio nuevo” de manera apropiada.

Ejemplo:

  1. Dirección URL A redirige a dirección URL B (redirección heredada).
  2. Dirección URL B redirige a dirección URL C (nueva redirección).
  3. Lo cual resulta en la siguiente cadena de redirecciones: URL A – URL B – URL C.

 

Para eliminar lo anterior, lo que se debe hacer es corregir la redirección heredada del sitio origen actual y crear una completamente nueva, así que:

  1. URL A redirige a URL C (redirección heredada corregida).
  2. URL B redirige a URL C (redirección nueva).

Como consejo profesional, chequear la hoja de cálculo de redirección del mapeo para redirigir bucles es muy recomendado. Asimismo, esto ocurre cuando la “dirección URL heredada” es idéntica a la “dirección URL del sitio nuevo.”

Por otra parte, los bucles de redirección tienen que ser removidos al resultar en páginas de carga infinitas que son inaccesibles a los usuarios y a los motores de búsqueda, también teniendo que eliminarse los bucles al ser aniquiladores instantáneos de tráfico, conversión y de ranking en resultados mostrados por Google.

Implementar reglas de redirección generales para evitar contenido duplicado

Se recomienda ampliamente intentar trabajar con reglas en relación a las redirecciones que cubran tantas peticiones de dirección URL como sea posible. Por ejemplo, implementar reglas de redirección en un servidor web es mucho más eficiente que confiar en números de redirecciones una a una.

Por otra parte, Si el documento de redirección de mapeo consiste en un gran número de redirecciones que deben ser implementadas con regla de tipo una a una, el rendimiento del sitio pudiera ser afectado de manera negativa. De cualquier manera, se debe chequear bien con el equipo de desarrollo el número máximo de redirecciones que el servidor web puede tolerar y manejar al mismo tiempo, por supuesto sin que se presente ningún tipo de problema.

En todo sentido, hay algunas reglas estandarizadas en cuanto a redirecciones que deben ser puestas a lugar, evitando así generar problemas de duplicado de contenido, las cuales son:

Caso de dirección URL: todas las direcciones URL que contienen letras mayúsculas deberían ser de tipo de redirección 301 a todas las direcciones URL con caracteres en letra minúscula. Ejemplo, https://www.sitioweb.com/Pagina debería re-direccionar automáticamente a https://www.sitioweb.com/pagina.

Alojamiento: todas las direcciones URL sin “www” deben ser de tipo 301 en cuanto a redirección a su equivalente web con “www”. Ejemplo, https://.sitioweb.com/Pagina debería ser redirigido a https://www.sitioweb.com/Pagina.

Protocolo: en un sitio web seguro las peticiones hechas por direcciones URL basadas en HTTP deben ser redirigidas a una dirección URL HTTPS que sea equivalente. Ejemplo: http://www.sitioweb.com/Pagina debe llevar de manera automática a https://www.sitioweb.com/Pagina.

Barra diagonal: cualquier dirección URL que no contenga una barra diagonal debe llevar a una versión con una barra diagonal. Ejemplo: https://www.sitioweb.com/Pagina debe redirigir a la página https://www.sitioweb.com/Pagina/.

Inclusive, si algunas de estas reglas de redirección estandarizadas existen en el sitio web heredado, no necesariamente se tiene que asumir que las mismas estén presentes en el nuevo sitio web, a menos que sean requeridas de manera explícita y anticipada.

Evitar redirecciones internas

Se debe actualizar los enlaces internos del sitio para que los mismos no activen redirección internos. Y es que, aunque los motores de búsqueda pueden seguir redirecciones internas, las mismas no se recomiendan porque añaden latencia adicional innecesaria a los tiempos de carga de la página, teniendo también un impacto negativo en el tiempo de rastreo de las arañas o Googlebots del buscador.

No olvidar los archivos de imágenes

Si las imágenes de un sitio se han movido a una ubicación nueva, Google recomienda redirigir las URL de las imágenes anteriores a las URL de las imágenes nueva, ayudando así al buscador a descubrir e indexar las nuevas imágenes de manera más rápida. Ahora, si no es fácil redirigir todas las imágenes, se debe enfocar en hacerlo al menos en aquellas direcciones URL de imágenes que ya tienen enlaces en otros sitios.

Fase 3: pruebas de pre-lanzamiento

Cuando se trata de migraciones web mientras se empiece a probar antes mejor, y aunque ciertas cosas necesitan ser implementadas de manera obligatoria y completa para ser probadas, otras en realidad no tanto y más bien pueden resultar optativas o a elección para conocer un punto específico de la migración y su rendimiento antes del lanzamiento.

Por ejemplo, problemas de navegación de usuario se pueden identificar desde los prototipos tempranos y cuadros de trabajo del nuevo sitio web, así como también los problemas relacionados con el contenido entre el sitio web antiguo y el nuevo o inconsistencias del mismo (como por ejemplo entre un sitio móvil y otro de escritorio), los cuales también pueden ser identificados en una etapa temprana como en este punto.

Sin embargo, los componentes de naturaleza más técnica deben ser probados una vez que están implementados de manera completa: cosas como redirecciones, etiquetas canónicas o mapas de sitio XML son ejemplos muy claros. Aunque, de la misma manera como los demás mientras más rápido se identifiquen los problemas, más probable será solucionarlos antes de lanzar el nuevo sitio.

Ahora, identificar ciertos tipos de problemas en una etapa más tardía afectara el balance costo-efectividad, así como requerir más recursos y causar retrasos de manera significativa. Por eso, el testeo imperfecto y mal implementado y no llevar el tiempo requerido para probar profundamente todos los aspectos de desarrollo, así como los factores relacionados a rendimiento SEO y UX puede tener consecuencias nefastas al poco tiempo de que se lance el nuevo sitio.

Asegurarse que los motores de búsqueda no accedan al desarrollo y pruebas del sitio

Antes de que el nuevo sitio web sea accesible en un ambiente de desarrollo y prueba, se deben tomar precauciones para que los motores de búsqueda no lo indexen. Asimismo, hay varias maneras distintas para llevar a cabo este cometido, cada una con sus pros y contras pero que evitan que Google detecte un sitio no terminado y por lo tanto poco optimizado.

Acceso al sitio para direcciones IP específicas (lo más recomendado)

Hacer el sitio a probar solo accesible mediante direcciones IP específicas es una manera muy efectiva de prevenir que los motores de búsqueda lo rastreen. Por ejemplo, cualquiera que intente al sitio de prueba a través de dirección URL no podrá ver ningún tipo de contenido, a menos que su dirección IP se encuentre en la lista de acceso permitido.

Asimismo, la mayor ventaja en cuanto a esto es que los usuarios permitidos mediante IP pueden acceder y rastrear el sitio sin ningún tipo de problema, aunque por otro lado su mayor desventaja es que páginas de herramientas basadas en terceros (ejemplo claro Google Tools) no pueden usarse, debido a que las mismas también son restringidas si no tienen acceso a la IP.

Protección por contraseña

La protección por contraseña para el punto de desarrollo y prueba del nuevo sitio web es otra manera de mantener alejados los rastreadores de los motores de búsqueda, aunque dicha solución tiene varios inconvenientes o problemas con los que lidiar.

Dependiendo del tipo de implementación que se realice, podría no ser posible rastrear y probar un sitio web protegido con contraseña, si la aplicación de rastreo no pasa de la pantalla de ingreso. Asimismo, otro inconveniente en cuanto a las páginas protegidas con contraseña es que las que usan formas de autenticación pueden ser rastreadas usando aplicaciones desarrolladas por terceros, habiendo un riesgo de causar inesperados problemas que pueden ser muy serios.

Y es que, lo anteriormente descrito sucede porque los clics de rastreo en cada enlace en una página (cuando ya se está ingresado) pudiesen terminar cliqueando en enlaces que crean o borran páginas, así como instalar o desinstalar plugins o programas insertados en páginas, los cuales pueden tener resultados inesperados en cuanto a respuesta, tiempos de carga y lugares en puestos de ranking en Google.

Bloqueo de archivos robots.txt

En cuanto a este tema, añadir las siguientes líneas de código a los archivos robots.txt de la página a probar va a prevenir que los motores de búsqueda rastreen el sitio en desarrollo, siendo otro tipo de protección viable mientras se realizan las pruebas pertinentes al mismo y se asegura que todo funcione bien al momento de su lanzamiento.

User-agent: *

Disallow: /

De la misma forma, el método de bloqueo de los archivos robots.txt de la página también tiene sus inconvenientes. Por ejemplo, a pesar que el contenido que aparece en servidor de prueba no será indexado, las direcciones URL no permitidas podrían aparecer en los resultados mostrados por google.

De la misma manera, otro inconveniente resulta en que si los archivos de robots.txt se mueven al sitio lanzado, los mismos causarán problemas severos de desindexación que suelen aparecer a menudo, por lo que se recomienda utilizar este método d bloqueo de sitio en última instancia, poniendo por encima las demás opciones para evitar los problemas abordados anteriormente.

Revisión de experiencia de usuario

Si el sitio en cuestión ha sido rediseñado o reestructurado, hay posibilidades de que la experiencia de usuario en el mismo sea afectada de alguna forma, así que revisar tal factor tan pronto como sea posible de buena manera mientras el sitio se lanza es recomendado, aunque también se dificulta debido a la falta de datos de usuario al ser un sitio que no ha tenido uso externo aún.

No obstante, un profesional experimentado en UX será capaz de abordar cualquier aspecto o duda que pudieran tener un rango de conversión con impacto negativo en el sitio. Del mismo modo, al ser el testeo de tipo A/B casi imposible de realizar en este punto inicial, pudiera valer la pena llevar a cabo pruebas de usuario e intentar obtener algo de retroalimentación o datos de usuarios reales.

Desafortunadamente, los problemas relacionados con experiencia de usuario en el sitio pueden ser unos de los más difícil de abordar y reparar, ya que los mismos requieren cambios amplios en la estructura y diseño de la página web, los cuales obviamente toman muchísimo tiempo, recursos y esfuerzo.

Ahora, realizando un resumen general y total del sitio, no todas las decisiones respecto a UX pueden ser respaldadas siempre con datos, por lo que muchas decisiones relacionadas van a tener que ser basadas en práctica, experiencia pasada y hasta simplemente “presentimientos” que solamente podrían tener expertos en UX/CRO involucrados, haciendo una labor que a generar dividendos luego.

Revisión de la arquitectura del sitio

Una migración de sitio es de manera frecuente una buena oportunidad para mejorar la arquitectura del mismo. En otras palabras, con la migración se tiene una gran oportunidad de reorganizar, ordenar y mejorar el sitio, en cuanto a contenido enfocado con palabras clave y maximizar su potencial de tráfico y visibilidad en búsquedas.

Por ejemplo, llevar a cabo una investigación y búsqueda extensa de palabras clave ayudará a identificar las mejores páginas de categorías y sub-categorías, para que los usuarios y los motores de búsqueda puedan llegar a cualquier página en el sitio solamente con unos pocos clics, ya que mientras menos de éstos mejor y se termina con un sitio con un orden no muy profundo o complicado, lo cual facilita su navegación.

En el mismo orden de ideas, identificar nuevas palabras clave con potencial decente en cuanto a tráfico y mapearlas dentro de nuevas páginas puede hacer una gran diferencia, respecto directamente de los niveles de tráfico orgánico del sitio. Por otra parte, impulsar la arquitectura del sitio necesita ser pensado y abordado de manera muy pensada y pausada.

Y es que, dicho impulso de la arquitectura del sitio puede causar problemas si, por ejemplo páginas importantes se mueven más profundo en la nueva arquitectura del sitio, o hay demasiadas páginas similares optimizadas para las mismas palabras clave. Ahora, algunas de las migraciones de sitio más exitosas son las que ubican recursos significativos para impulsar y fortalecer la arquitectura del sitio.

Revisión de meta-datos

Hay que asegurarse que los títulos de las páginas del sitio, meta – descripciones y encabezados sean hayan sido transferidos del sitio previo al nuevo sin problemas. Ahora, si se han creado páginas nuevas las mismas deben estar optimizadas y no enfocarse en palabras clave que ya estén siendo utilizadas en otras páginas del sitio.

Por otro lado, si se está haciendo un cambio de plataforma hay que estar pendiente sobre los valores de configuración por defecto que puede tener la nueva plataforma, respecto a cuándo páginas nuevas son creadas. Si se lanza el nuevo sitio sin títulos de páginas optimizados u otra meta – datos acordemente, dicha situación tendrá un impacto negativo inmediato en el ranking y tráfico del sitio.

Tampoco hay que olvidar revisar cualquier contenido generado por el usuario, como podría ser por ejemplo reseñas y comentarios y si han sido subidos de manera apropiada.

Revisión de enlazamiento o links internos

Definitivamente, los enlaces internos o enlazamiento es uno de los respaldos más importantes de un sitio web. Y es que, no importa que tan bien optimizado y estructurado esté una página en línea ya que eso no es suficiente para que sea exitosa, a menos que esté apropiadamente respaldada por un esquema de links internos sin fallas.

Asimismo, los enlaces internos deben ser revisados en absolutamente todo el sitio, incluyendo los links que se encuentran en:

  1. Navegación principal y secundaria.
  2. Enlaces de encabezado y pie de página.
  3. Enlaces en contenido.
  4. Enlaces de paginación.
  5. Enlaces horizontales (artículos relacionados, productos similares, entre otros).
  6. Enlaces verticales.
  7. Enlaces de sitios cruzados (enlaces entre sitios internacionales) .

 

Chequeos técnicos

Una serie de chequeos técnicos debe ser llevado a cabo para asegurarse que la configuración técnica del nuevo sitio sea la correcta, evitando fallas de este tipo luego de que se lance el sitio, lo cual afectaría de manera negativa la navegación y rendimiento y por lo tanto la experiencia de usuario, significando pérdida de visibilidad y bajas en el ranking de búsqueda de Google.

Por ejemplo, los chequeos técnicos involucran el funcionamiento y desarrollo del sitio en cuanto a programación, protocolos, servidores, recursos, plataformas y otras tecnologías y software que hacen que el sitio funcione y sea visto por otros usuarios.

Revisión de archivos robots.txt

Los archivos robots.txt del nuevo sitio deben prepararse en el ambiente de desarrollo del mismo, de ese modo se puede testear para encontrar errores u omisiones y evitar experimentar problemas de rastreo de motores de búsqueda, cuando finalmente el sitio web sea lanzado. Por ejemplo, un error clásico en la migración de sitios web es cuando los archivos robots.txt evitan que los motores de búsqueda tengan acceso usando la siguiente directiva:

Disallow: /

De la misma manera, si lo anteriormente descrito ocurre de manera accidental (lo cual pasa muy a menudo) en el lanzamiento del nuevo sitio, dicha cuestión significará que los motores de búsqueda no podrán rastrear el sitio, lo que al mismo tiempo quiere decir que las palabras clave asociadas con la página serán rebotadas de los resultados de búsqueda, eventualmente haciendo que el sitio sea no indexado, lo cual tiene un impacto negativo como ya se ha expresado.

Pero, si los archivos robots.txt en el desarrollo están poblados con las directivas de los archivos robots.txt del nuevo sitio, dicho contratiempo puede evitarse y no evitaría que los motores de búsqueda accedan e indexen el sitio de manera correcta para ser mostrado en la web. Asimismo, cuando se prepara el archivo robots.txt del nuevo sitio hay que asegurarse de que:

  1. No bloqueen el acceso de los motores de búsqueda a páginas que tienen la intención de ser indexadas.
  2. No bloqueen ningún recurso de tipo JavaScript o CSS que los motores de búsqueda requieren para condensar contenido de página.
  3. El contenido de los archivos robots.txt del sitio origen hayan sido revisados y traídos de ser necesario.
  4. Se referencien los nuevos mapas de sitio XML en vez de cualquiera de los heredados del sitio origen que no existan.

Revisión de etiquetas canónicas

Revisar las etiquetas canónicas del sitio es algo que sin duda debe realizarse. Buscar páginas que ya sea que no tengan una etiqueta canónica o si la tengan y que apunten a otra dirección URL, preguntándose si es una cuestión intencional también es pertinente.

No hay que olvidar rastrear las etiquetas canónicas y encontrar si las mismas regresan una respuesta al servidor 200, y si no lo hacen se tendrán que actualizar para así eliminar respuestas de servidor de tipo 3xx, 400 y 500 que son errores que afectan el sitio de manera negativa en todo lo que respecta a SEO, Google y tráfico.

De la misma manera se deben buscar páginas que tienen etiquetas canónicas apuntando a otra dirección URL combinadas con directivas no indexadas, ya que éstas dos son señales en conflicto y se tendrán que eliminar al menos una.

Revisión de meta – robots

Una vez que se ha rastreado el sitio en desarrollo, se debe buscar por páginas con propiedades y funciones de meta – robots establecidos para “noindex” o “nofollow.” Si tal es el caso, hay que revisar cada una de ellas para asegurarse que sea intencional y remover las directivas “noindex” o “nofollow” si no lo están.

Revisión de mapas de sitio XML

Preparar dos diferentes tipos de mapas de sitio; uno que contenga todas las páginas que son posibles indexar del sitio nuevo, y otro que incluya todas las páginas posibles de indexar del sitio previo.

De manera concreta, el sitio anterior ayudará a Google a notar la existencia de las direcciones URL indexadas del nuevo sitio web, mientras que el sitio actual a crear ayudará a Google a notar las redirecciones que están puestas, así como el hecho de que algunas de las direcciones URL indexadas se han movido a nuevas ubicaciones, para que el buscador pueda descubrirlas y actualizar los resultados de búsqueda mostrados de modo mucho más rápido y sencillo.

De la misma manera, es necesario chequear cada mapa de sitio XML para estar seguro de que:

  1. Se valida sin ningún tipo de problema.
  2. Está programado como UTF – 8.
  3. No contiene más de 50.000 filas.
  4. Si tamaño no exceda los 50 MB cuando se descomprime.

No obstante, si hay más de 50.000 filas o el archivo se excede de 50 MB en cuanto al peso, será necesario romper el mapa de sitio en piezas más pequeñas, lo que previene que el servidor presenta sobrecarga si Google requiere el mapa de sitio de modo muy frecuente.

En adición a ello, es necesario rastrear cada mapa de sitio XML para asegurarse sólo incluya direcciones URL indexadas. Y es que, cualquier dirección URL no indexable debe ser excluida de los mapas de sitio XML, como:

  1. Páginas con errores de tipo 3xx, 4xx, y 5xx, ejemplo: páginas redirigidas, no encontradas, peticiones erróneas, entre otros.
  2. Páginas con errores de tipo 404 parciales sin contenido que regresa una respuesta del servidor 200, en vez de identificarse como error 404.
  3. Páginas canonizadas (aparte de las referidas a sí mismas como direcciones URL canónicas)
  4. Páginas con una directiva “noindex” de meta – robots

 

Páginas con una etiqueta X-Robots “noindex” en el encabezado HTTP (Ejemplo)

HTTP/1.1 200 OK

Date: Tue, 10 Nov 2017 17:12:43 GMT

(…)

X-Robots-Tag: noindex

(…)

Páginas bloqueadas de los archivos robots.txt

Construir mapas de sitio XML limpios puede ayudar a monitorear los niveles de indexación verdaderos del nuevo sitio una vez que el mismo ya se haya lanzado. Si no, en verdad resultará muy complicado encontrar errores o problemas de indexación de cualquier índole.

Como recomendación profesional, descargar y abrir cada mapa de sitio XML en el software Excel de la suite ofimática de Microsoft es muy recomendable, ya que así se obtiene una visión detalladas de cualquier atributo adicional, ya sea hreflang o atributos de imágenes.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 6

Revisión de mapas de sitio HTML

Dependiendo del tamaño y el tipo de sitio que está siendo migrado y se encuentra en tal proceso, tener un mapa de sitio de tipo HTML puede en algunos casos ser muy beneficioso. Concretamente, un mapa de sitio HTML que consista en direcciones URL que no están enlazadas desde la navegación principal del sitio pueden significar un gran impulso, específicamente en lo que respecta a visibilidad y descubrimiento de páginas e indexación.

Sin embargo, hay que evitar genera un mapa de sitio HTML que incluya demasiadas direcciones URL, y si lo que se necesita es exactamente incluir muchas direcciones URL hasta por cientos o miles, es mejor considerar hacer un mapa de sitio HTML de tipo segmentado.

Por otro lado, el número de mapas de sitio anidados y también el número máximo de direcciones URL que se deben incluir en cada mapa de sitio dependen de la importancia, impacto e influencia del sitio en cuestión, respecto de factores que van desde tráfico, enlaces, clics, rango de rebote, entre otros.

En este sentido, mientras más influyente es un sitio web de acuerdo a los factores nombrados anteriormente, más alto será el número de mapas de sitios anidados y direcciones URL que podrá soportar y tener sin problemas.

Por ejemplo, la página web del periódico The New York Times tiene un mapa de sitio de tipo HTML que consiste en tres niveles, donde cada uno de ellos incluye hasta 1000 direcciones URL por cada mapa de sitio.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 7

Asimismo, dichos mapas de sitio HTML anidados ayudan a los rastreadores o arañas de los motores de búsqueda a descubrir artículos publicados desde el año 1851. De otro modo, realizar tal tarea sería muy difícil e incluso casi imposible para descubrir e indexar tanta información y datos, ya que no todos ellos habrían estado enlazados internamente.

Revisión de estructura de datos

Los errores en el marcado de estructura de datos necesitan ser identificados de manera temprana, para que así haya tiempo de arreglarlos antes de que el sitio web nuevo sea lanzado. De modo ideal, se deben probar cada plantilla de página en vez de hacerlo con cada página usando la herramienta de Google Structured Data Testing Tool, diseñada específicamente para el cometido de revisar la estructura de datos.

También, hay que asegurarse de chequear el marcado tanto en páginas de equipos de escritorio como en las de dispositivos móviles, especialmente si éste último no está funcional o no es responsivo por alguna razón.

En cuanto al funcionamiento del software, la herramienta de Google para revisar la data estructurada sólo reportará cualquier error existente pero no las omisiones.

Por ejemplo, si la plantilla de página de producto no incluye el esquema de datos estructurados del producto, la herramienta de Google no va a reportar ningún tipo de error. En adición a ello, para comprobar errores también hay que asegurarse de que cada plantilla de página incluya el marcado de estructura de datos apropiado, la cual debe ser acorde al tipo de contenido de la misma.

Revisión de rastreo de JavaScript

Se debe probar cada plantilla de página del Nuevo sitio para asegurarse que Google será capaz de rastrear el contenido incluido que requiere análisis de JavaScript. Ahora, si es posible utilizar la herramienta de recuperación y renderizado de Google en el sitio en desarrollo, en definitiva es algo que se debe realizar. De otro modo, también se pueden hacer otras pruebas manuales.

A continuación, los pasos para auditar contenido Javascript y llevar a cabo una revisión del rastreo del mismo de manera más precisa:

  1. Auditar la página visualmente.
  2. Auditar la fuente HTML por contenido perdido.
  3. Auditar el Renderizado-JS HTML por contenido perdido.
  4. Comparar la fuente HTML y la fuente de Renderizado-JS para buscar contradicciones.
  5. Identificar contenido dependiente en eventos de usuario.

Aunque, como han probado algunos estudios llevados a cabo por distintos investigadores donde destaca el de Bartosz Gerulewicz, incluso si Google es capaz de rastrear e indexar contenido generado a través de JavaScript, dicha cuestión no significa que vaya a ser capaz de rastrear contenido originado en dicha plataforma, en lo que respecta a todos los cuadros de trabajo principales de Javascript.

Por ejemplo, la siguiente tabla resume los resultados mostrados por la investigación hecha por Bartosz, enseñando que algunos marcos de trabajo de JavaScript no son amigables en lo que respecta a SEO y sus propósitos, con Angular JS siendo el más problemático de todos en este sentido hasta la fecha.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 8

Del mismo modo, Bartosz también encontró a través de su estudio que otros motores de búsqueda como Bing, Yandex y Baidu luchan y se les complica la tarea de indexar contenido generado con la plataforma JavaScript, lo cual es importante de saber si el sitio en cuestión a migrar y su tráfico se basa en dichos motores de búsqueda mencionados anteriormente, los cuales aunque no sean los más influyentes de igual manera tienen cuota de mercado.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 9

Por supuesto, dicha realidad mencionada en los párrafos anteriores se espera que mejore con el tiempo, aunque con la creciente popularidad de los cuadros de trabajo de JavaScript y su uso en el desarrollo web, lo más seguro es que tarde un poco pero igual debe ser considerado prioridad para el sitio.

Finalmente, se debe chequear si algunos recursos internos están siendo bloqueados. De manera desafortunada, tal cosa no es una cuestión que se pueda controlar en un cien por ciento, ya que muchos recursos como JavaScript y archivos CSS son alojados por sitios web de terceros, los cuales pueden estar bloqueándolos a través de sus propios archivos robots.txt.

Otra vez, las herramientas de renderizado y recuperación de Google pueden ayudar a diagnosticar el tipo de problema explicado anteriormente, ya que si el mismo se deja sin resolver puede significar en un impacto negativo para el sitio desde varios puntos de vista, empezando por SEO y motores de búsqueda.

Revisión SEO de sitio móvil

La revisión y verificación de funcionamiento general de sitio móvil en cuanto a SEO es esencial, ya que se comprueban todos los aspectos que pudieran estar afectando positiva o negativamente su plataforma, respecto de su respuesta, indexación, tiempos de carga, enlaces y otros. La revisión SEO de sitio móvil se realiza llevando a cabo los siguientes pasos.

Revisión de bloqueo de activos o recursos

En primer lugar, hay que asegurarse que el archivo de robots.txt no esté bloqueando de modo accidental recursos relacionados a JavaScript, CSS o imágenes que son esenciales para que el sitio móvil y su contenido sea renderizado correctamente.

Ahora, lo anterior podría tener un impacto negativo en cómo los motores de búsqueda renderizan e indexan el contenido de las páginas web del sitio móvil, lo cual de manera consecuente afectaría también de mala forma la visibilidad en búsqueda y rendimiento general del sitio.

Revisión de primer índice móvil

Para evitar cualquier problema asociado con el primer índice móvil de Google, revisar profundamente el sitio web móvil es recomendable, haciendo que no existan inconsistencias entre el sitio para equipos de escritorio y el sitio para dispositivos móviles, en lo que respecta a las siguientes áreas:

  1. Títulos de página.
  2. Meta – descripciones.
  3. Etiquetas canónicas.
  4. Atributos de meta – robots (por ejemplo “noindex” y “nofollow”.
  5. Enlaces internos.
  6. Data estructurada.

 

Sin duda, un sitio web responsivo debería ofrecer el mismo contenido, enlaces y marcado entre dispositivos, así como los atributos SEO mencionados previamente deben ser idénticos entre los sitios para equipos de escritorio y dispositivos móviles. En adición, se deben llevar a cabos nuevas y más exhaustivas técnicas de comprobación, dependiendo de la configuración del sitio web móvil.

Revisión de sitio web responsivo 

Un sitio web responsivo debe ofrecer a todos los dispositivos el mismo código HTML, el cual se ajusta vía uso de plataforma CSS, dependiendo del tamaño de pantalla utilizado por el usuario.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 10

Asimismo, los Googlebots o robots de Google son capaces de detectar automáticamente la configuración móvil expresada previamente, siendo importante que asegurarse que los mismos puedan acceder a todos los recursos o activos esenciales como imágenes, JavaScript y archivos CSS.

En este sentido, para señalar a los navegadores que una página es responsiva una meta – etiqueta debe ser puesta con el encabezado de cada página HTML. Ejemplo:

<meta name=”viewport” content=”width=device-width, initial-scale=1.0″>

Sin embargo, si la etiqueta de la meta –ventana no está presente el tamaño de la fuente puede aparecer de una manera inconsistente y poco amigable para el usuario, pudiendo provocar que Google considere a la página como no apta para dispositivos móviles, sabiendo ya en este punto lo que puede provocar tal realidad en relación a visibilidad y ranking en motores de búsqueda.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 11

Revisión de direcciones URL móviles separadas

Si el sitio web móvil utilizar direcciones URL separadas respecto de las utilizadas en equipos de escritorio, siempre hay que asegurarse de tener las siguientes cualidades para ofrecer el mejor funcionamiento:

  1. Que cada página de equipo de escritorio tenga una etiqueta apuntando a la dirección URL móvil que le corresponda.
  2. Que cada página móvil tenga una etiqueta canónica apuntando a la dirección URL de escritorio que le corresponda.
  3. Que cuando las direcciones URL de escritorio sean requeridas por dispositivos móviles, las mismas sean redirigidas a la respectiva dirección URL móvil.
  4. Que la redirección de página web y direcciones URL trabajen a través de todos los dispositivos móviles, incluyendo las plataformas de este tipo de equipos como Android, IOS y Windows Phone.
  5. Que no hayan enlaces cruzados irrelevantes entre las plataformas móviles y de escritorio del sitio, significando que los enlaces internos ubicados en una página de escritorio deberían enlazar solamente a páginas del mismo tipo, así como los enlaces en páginas móviles deben enlazar solamente a páginas de la misma categoría.
  6. Las direcciones URL móviles regresan una respuesta de servidor de tipo 200.

Revisión de servicio dinámico

Los sitios web de servicio dinámico ofrecen diferente codificación para cada dispositivo, aunque ubicada en la misma URL.

De la misma manera, sobre dichos sitios se recomienda revisar si el encabezado HTTP variado ha sido configurado de manera correcta, siendo necesario porque los sitios de servicio dinámico cambian el código HTML para agentes de usuario móvil, y el encabezado HTTP variado ayuda a los Googlebots o robots de Google a descubrir contenido móvil.

Revisión de compatibilidad con dispositivos móviles

Indiferentemente de si la configuración de un sitio web móvil es responsiva, con direcciones URL separadas o de servicio dinámico, es recomendable verificar las páginas usando un agente de usuario móvil para asegurar que:

  1. La ventana ha sido configurada de manera correcta, ya que si la misma se establece de tipo ancho fijo entre los dispositivos causará problemas de usabilidad en dispositivos móviles.
  2. El tamaño de la fuente no sea muy pequeña.
  3. Los elementos táctiles como botones y enlaces no estén demasiado cerca.
  4. No haya ningún elemento intrusivo entre sitios, ya sean avisos publicitarios, formularios de registro de correo o servicios, ventanas emergentes de descarga de aplicación o mostrando “problemas” inexistentes. Para evitar dichos inconvenientes lo mejor es usar ya sea un HTML de tipo pequeño o banner de imagen.
  5. Las páginas móviles no sean muy lentas al cargar, por lo que sus tiempos de carga deben ser lo más bajo posibles.

De manera afortunada, con el uso de la herramienta de Google Mobile-Friendly Test Tool se pueden diagnosticar los problemas explicados anteriormente de manera muy sencilla, como se muestra en la siguiente imagen donde se enumeran los problemas encontrados.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 12

Revisión de sitio AMP

Si hay un sitio web de tipo AMP y una versión de escritorio del mismo está disponible, se debe asegurar que:

  1. Cada página no AMP (como por ejemplo de escritorio o móvil) tenga una etiqueta que apunte a la dirección URL AMP que le corresponde.
  2. Cada página tenga una etiqueta canónica apuntando a la página de escritorio que le corresponde.
  3. Cada página AMP que no tenga una dirección URL correspondiente tenga una etiqueta canónica que se refiera a ella misma.

De la misma forma, hay que asegurarse que los sitios AMP sean válidos, lo cual se puede probar utilizando la herramienta oficial de Google AMP Test Tool.

Errores de mezcla de contenido

Con Google haciendo fuerza para que los sitios sean completamente seguros, así como el convertir a su navegador oficial Chrome en el primero de su tipo en marcar las páginas escritas en HTTP como no seguras, de manera obligatoria hay que lanzar el nuevo sitio en lenguaje HTTPS y asegurándose que tanto como imágenes, archivos de CSS y JavaScript sean requeridos a través de conexiones HTTPS seguras, lo cual es necesario para evitar problemas de mezcla de contenido.

De modo específico, la mezcla de contenido ocurre cuando una página que está cargada sobre una conexión HTTPS segura requiere activos y recursos a través de conexiones HTTP no seguras. Asimismo, la mayoría de navegadores o bloquean las peticiones HTTP peligrosas o muestran advertencias para evitar riesgos que dañan la experiencia de usuario.

Ahora, hay muchas maneras de identificar errores de mezcla de contenido, los cuales incluyen el uso de aplicaciones de rastreo, la herramienta oficial de Google Lighthouse, entre otros.

Revisión de archivos de imágenes

Google rastrea imágenes de manera menos frecuente en comparación a como lo hace con páginas HTML. En ese sentido, si migrar las imágenes de un sitio de una ubicación a otra (por ejemplo, de un dominio a un CND) hay maneras de ayudar a Google a descubrir las imágenes migradas de modo muchísimo más rápido.

Por ejemplo, construir una imagen de mapa de sitio XML ayudará pero también hay que asegurarse que los Googlebots o los robots de Google puedan alcanzar las imágenes del sitio cuando el mismo sea rastreado.

Sin embargo, la parte más complicada con la indexación de imágenes es que tanto la página web donde aparecen dichas imágenes como los archivo originales mismos deben ser indexados.

Revisión de rendimiento del sitio

Definitivamente, se debe medir el tiempo de carga de las páginas del sitio web anterior y ver cómo éstos se comparan con los del nuevo sitio, al momento de que el mismo se haga disponible luego de su etapa de desarrollo y migración.

En este punto, se recomienda enfocarse en el rendimiento de los aspectos dependientes de la conexión, tales como el uso de recursos externos como imágenes, JavaScript, CSS, código HTML y la configuración del servidor web. No obstante, información más detallada sobre este tema será mostrada más adelante.

Revisión de métricas de rastreo

Asegurarse que las métricas de rastreo estén configuradas apropiadamente es muy importante. Aunque, dicho tipo de revisión debería ser llevada a cabo de manera ideal por especialistas en consultas de métricas, quienes buscarán más allá de la implementación del código de rastreo.

Por ejemplo, hay que asegurarse que las Metas y Eventos estén configurados de modo apropiado, el rastreo e impulso de e-commerce esté implementado, entre otros. Y es que, no hay nada más frustrante que no tener datos de métricas luego que el nuevo sitio sea lanzado de manera oficial.

Prueba de redirecciones

Probar las redirecciones antes de que el nuevo sitio se lance es crítico y puede ayudar a ahorrar muchos problemas luego. De hecho, hay muchas maneras de comprobar las redirecciones en un estado de desarrollo y prueba, aunque el propósito o meta final es que no se debe lanzar el nuevo sitio web sin que las redirecciones hayan sido testeadas.

Una vez que las redirecciones están disponibles en una etapa de desarrollo y prueba, se recomienda rastrear la lista completa de las mismas y chequear si se presentan los siguientes inconvenientes para abordar su pronta resolución, tomando ventaja de esta etapa temprana:

  1. Bucles de redirecciones (una dirección URL que infinitamente se redirige a sí misma).
  2. Redirecciones con respuestas de servidor de código 4xx y 5xx.
  3. Cadenas de redirecciones (una dirección URL que redirige a otra dirección URL, la cual en respuesta redirige a otra URL, ETC.).
  4. Direcciones URL canónicas que reenvían una respuesta de servidor de código 4xx y 5xx.
  5. Bucles canónicos (la página A tiene una dirección canónica a la página B, la cual al mismo tiempo tiene una dirección canónica a la página C).
  6. Cadenas canónicas (una canónica que apunta a otro sitio que tiene una canónica apuntando a otro sitio y así sucesivamente).
  7. Inconsistencias de protocolo o alojamiento, siendo ejemplos claros cuando las direcciones URL se redirigen tanto a direcciones URL HTTP como HTTP, o también de tipo con “www” y sin “www”.
  8. Conducir y rastrear whitespace characters. Para esto se puede utilizar trim() en el programa ofimático Excel de Microsoft para eliminarlos.
  9. Caracteres inválidos en direcciones URL.

Como consejo profesional, es recomendable asegurarse que una de los direcciones URL del sitio anterior se redirija a la dirección URL correcta en el nuevo sitio web. En este punto, al no existir aún de manera oficial el sitio que se está desarrollando, solamente se puede probar si la dirección URL redirigida de destino es la que se quiere, aunque definitivamente vale la pena.

Y es que, el hecho de que una dirección URL redirija no quiere decir que lo haga a la página correcta, por lo que tiene que comprobarse.

Fase 4: Actividades en el día de lanzamiento

Mientras el nuevo sitio está reemplazando al antiguo, hay muchas probabilidades de que el primero esté temporalmente fuera de servicio. Asimismo, el tiempo fuera debe mantenerse a lo más mínimo posible, y mientras eso sucede el servidor web debe responder a cualquier pedido de dirección URL del sitio con el código 503, el cual quiere decir (servicio no disponible).

Así, se les dirá de manera clara a las arañas rastreadoras del motor de búsqueda que el sitio está temporalmente fuera de servicio, ya sea por mantenimiento o por cualquier otra razón de ese tipo, por lo que los rastreadores volverán a realizar el trabajo para que fueron programados luego.

No obstante, si el sitio permanece fuera de servicio demasiado tiempo sin ofrecer un respuesta de tipo 503 y los motores de búsqueda rastrean el sitio web, como producto la visibilidad orgánica en búsquedas se verá afectada de manera negativa y su recuperación no será inmediata una vez que dicho sitio esté en marcha de nuevo, teniendo consecuencias a mediano y largo plazo.

En adición a esto, mientras el sitio web está temporalmente fuera de servicio el mismo debe tener ofrecer una página informativa, en la cual se le notifica a los usuarios que el sitio está temporalmente fuera de servicio por mantenimiento, siendo una estrategia que salva la reputación de la nueva plataforma desde sus inicios.

Controles técnicos puntuales

En este punto, ya el sitio está lanzado y listo para que los motores de búsqueda puedan rastrearlo y mostrarlo a los usuarios que lo requieran mediante su la información que requieren, simplemente insertando unas palabras clave. Pues, tan pronto como el sitio esté en línea rápidamente se deben mirar:

  1. Los archivos robots.txt para asegurarse que los motores de búsqueda no estén bloqueados para rastrear el sitio apropiadamente.
  2. Redirecciones de páginas principales, por ejemplo: ¿las peticiones por las páginas principales del sitio anterior redirigen de manera correcta?
  3. Etiquetas canónicas de páginas principales
  4. Respuestas de servidor de páginas principales
  5. Directivas “noindex” y “nofollow, en caso de que ocurran sin intención.

Por otra parte, los controles técnicos puntuales deben ser llevados a cabo de manera obligatoria en las plataformas móviles y de escritorio del sitio, a menos que el mismo sea completamente de tipo responsivo.

Acciones en la Search Console (consola de configuración de Google)

Ya que el sitio está vivo y en línea, a continuación se muestran las actividades a llevar a cabo relacionadas con varios aspectos para asegurar el funcionamiento óptimo del sitio:

  1. Prueba y carga de los mapas de sitio XML
  2. Configurar la ubicación preferida del dominio (ya sea de tipo “www” o no)
  3. Configurar el enfoque o direccionamiento internacional (si aplica)
  4. Configurar los parámetros de las direcciones URL para afrontar cualquier problema potencial de tipo contenido mezclado
  5. Subir el archivo de Desautorizado (si aplica)
  6. Usar la herramienta de Cambio de Dirección (si se intercambian los dominios)

En cuanto a la Search Console de Google, se aconseja usar la característica “Explorar como Google” para cada tipo de página diferente (ejemplo: la página principal, una categoría, subcategoría, una página de producto) para asegurar que los Googlebots o robots de Google puedan renderizar las páginas sin ningún tipo de problema.

También, revisar cualquier reporte de bloqueo de recursos y no olvidar utilizar la característica “Captar y Renderizar” (Del inglés Fetch and Render) para la plataforma móvil y local de la página, sobre todo si el sitio móvil aún no es responsivo por cualquier razón.

Fase 5: revisión post-lanzamiento

Una vez que el nuevo sitio está vivo y completamente lanzado, una nueva ronda de comprobaciones profundas debe llevarse a cabo. De hecho, la mayoría son las mismas que aparecen en la “fase 3: pruebas de pre-lanzamiento” aunque obviamente con algunas diferencias.

Sin embargo, la diferencia principal durante esta fase es que ahora es posible y se sabe cómo acceder a muchos más datos, información y herramientas general a utilizar. Asimismo, no se debe poco estimar la cantidad de esfuerzo que se requiere poner en esta fase, ya que cada problema encontrado ahora afecta de modo directa el rendimiento del sitio en los resultados de los motores de búsqueda.

Por otro lado, mientras más pronto se identifique y se repare un problema es mucho más posible que no tenga consecuencias negativas, o que las mismas tengan poco impacto con reversibilidad rápida.

En adición a esto, aparte de repetir las mismas tareas comprobatorias que fueron mostradas en la sección de la fase 3, en algunas áreas las cosas pueden ser testeadas de modo mucho más profundo, preciso y detallado, así como también tener la ventaja de manejar la Search Console de Google de manera completa.

Chequear los registros de las estadísticas de rastreo y servidores

En cuanto a esta prueba, hay que vigilar las estadísticas de rastreo disponibles en la Search Console de Google, para asegurarse que el buscador está en efecto rastreando las páginas del nuevo sitio web.

En general, cuando los robots de Google o Googlebots se cruzan con nuevas páginas, se tiende a acelerar el número promedio de páginas que los mismos rastrean por día. Aunque, si no se puede observar un pico en el tiempo de la fecha de salida, algo puede estar afectando de manera negativa la habilidad de los robots de Google o Googlebots para rastrear el sitio.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 14

Ahora, comprobar los archivos de registro del servidor es por mucho la manera más efectiva de observar cualquier problema de rastreo, así como inconvenientes relacionados al rendimiento y eficiencia.

Por ejemplo, herramientas como Botify y On Crawl pueden ser muy útiles al combinar rastreos con datos de registro del servidor, pudiendo resaltar las páginas que los motores de búsqueda no están rastreando, páginas que no están enlazadas internamente (páginas huérfanas), páginas de bajo valor que están muy enlazadas internamente, entre muchas otras.

Revisión de errores de rastreo de modo frecuente

Es ideal vigilar los errores de rastreo reportados, sobre todo diariamente durante las primeras semanas de haberse lanzado el sitio a la luz, por lo que descargar dichos errores de manera diaria, rastrear las direcciones URL reportadas y tomar las acciones necesarias (como implementar redirecciones adicionales de tipo 301 o arreglar errores menores de código 404) ayudarán a una recuperación mucho más rápida, así como menos impacto de los problemas en el sitio.

No obstante, es altamente improbable que se necesite redirigir cada error de tipo 404 que sea reportado, aunque se debería añadir redirecciones para la mayoría de los más importantes, al menos. Ahora, gracias a Google Analytics de manera sencilla se pueden encontrar cuales son las direcciones URL requeridas con error 404, siendo las primeras que deben repararse.

Otras funciones útiles de la Search Console o consola de búsqueda de Google

La Search Console de Google tiene otras funciones y características que valen la pena probarse, las cuales incluyen Bloqueo de Recursos, errores de Datos Estructurados, errores de Usabilidad Móvil, Mejores en HTML, así como Enfoque y Dirección Internacional.

Asimismo, se aconseja vigilar de cerca los parámetros de las direcciones URL en el caso estén causando problemas de contenido duplicado. Si en efecto ese es el caso, hay que considerar tomar alguna acción urgente para arreglar la situación.

Medir la velocidad del sitio

Al estar el sitio en línea, medir la velocidad es una acción aconsejable regularmente para asegurarse que las páginas del sitio cargan lo más rápido posible, tanto en la plataforma de escritorio como en la de los dispositivos móviles.

Asimismo, con la velocidad de carga del sitio siendo un factor de ranking para los resultados en motores de búsqueda, así como también las páginas de carga lenta pierden cada día usuarios y potenciales consumidores y clientes, comparar la velocidad del sitio nuevo con el sitio previo es en verdad muy importante.

En ese sentido, si los tiempos de carga de las páginas del nuevo sitio parecen ser más altos es necesario tomar acciones inmediatas, ya que de otro modo el tráfico del mismo y las conversiones tendrán un golpe negativo de manera casi segura.

Evaluando la velocidad utilizando las herramientas de Google

Para evaluar la velocidad del sitio en relación a varios factores y campos, Google ofrece dos herramientas que resultan muy útiles y que han sido nombradas de manera previa en esta guía: Lighthouse y Pagespeed Insights.

En primer lugar, la herramienta de Google Pagespeed Insights mide el rendimiento del sitio tanto en su plataforma de escritorio como en su plataforma móvil, mostrando datos de carga de página en tiempo real basados en información que la propia Google recolecta de su navegador Chrome.

De la misma manera, la herramienta Pagespeed Insights Tool también comprueba si una página ha aplicado las mejores prácticas más comunes de rendimiento, dando un puntaje de optimización. También, dicha herramienta incluye las siguientes categorías principales:

  1. Puntaje de velocidad: categoriza una página como Rápida, Lenta o Promedio usando dos métricas: First Contentful Paint (FCP) y DOM Content Loaded  (DLC). De manera concreta, una página se considera rápida si ambas métricas están a un tercio del tope de su categoría.
  2.  Puntaje de optimización: categoriza una página como Buena, Media o Baja basado en el rendimiento y optimización de la misma, de acuerdo a sus recursos y capacidad de carga y respuesta, entre otros factores.
  3. Distribuciones de carga de páginas: categoriza una página como Rápida (tercio más rápido), Promedio (tercio medio) o Lenta) (tercio más bajo), al compararse contra todos los eventos de tipo FCP y DLC en el Reporte de Experiencia de Usuario del navegador Google Chrome.
  4. Estadísticas de página: puede indicar si la página podría ser más rápida si el desarrollador modifica la apariencia y funcionalidad de la misma.
  5. Sugerencias de optimización: una lista de las mejores prácticas que pudiesen ser aplicadas a una página para mejorar su desempeño y rendimiento general.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 15

En segundo lugar, la herramienta Lighthouse de Google es muy útil para rendimiento móvil, accesibilidad y auditorías de Aplicaciones Web Progresivas. Asimismo, la herramienta provee bastantes métricas que pueden usarse para medir el rendimiento de las páginas en dispositivos móviles, como:

  1. First Meaninful Paint (FMP): que mide cuando el contenido primario de la página es visible.
  2. Time to Interactive: es el punto en el cual la página está lista para que un usuario interactúe con ella.
  3. Speed Index: mide y muestra qué tan rápido una página se hace visible.

Como ventaja adicional, ambas herramientas mencionadas anteriormente proveen recomendaciones para mejorar cualquier sitio reportado con problemas de rendimiento, así como de otros tipos.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 16

Aunque, también hay otra opción de Google en cuanto a pruebas de sitios web y rendimiento llamada Test My Site, la cual provee un estimado bruto en el porcentaje de usuarios que se pueden estar perdiendo desde la plataforma web, debido precisamente a problemas de lentitud de carga de páginas.

Del mismo modo, dicha herramienta también provee una comparación en cuanto a la industria, para hacerse una idea de que tan lejos se encuentra el sitio del rendimiento tope de páginas del mismo nicho con los mejores tiempos de carga.

Midiendo la velocidad de usuarios reales

Una vez que el sitio se lanza y está disponible en línea, se puede empezar a evaluar la velocidad el mismo con base en los usuarios que lo visitan diariamente. Para este cometido, sin duda alguna Google Analytics es de las mejores herramientas que hay, pudiendo comparar los tiempos promedio de carga del sitio nuevo con el previo de modo directo.

En adición a esto, también se tiene acceso a una herramienta de Monitoreo de Usuario Real en la página. Asimismo, el mapa más abajo ilustra cómo diferentes usuarios experimentan distintos tiempos de carga, los cuales dependen de su región geográfica, velocidad y tipo de conexión, dispositivos utilizados, entre otros factores.

Por ejemplo, en la imagen siguiente los tiempos de carga del sitio parecen ser satisfactorios para usuarios de Estados Unidos, Alemania y el Reino Unido, aunque para usuarios que residen en otros continentes el tiempo de carga se incrementa.

Guia de migracion de sitio web estrate gias SEO, proceso y verificación 17

Fase 6: Medir el rendimiento de la migración del sitio web

Ha llegado la hora de saber si en realidad la migración web tuvo frutos o no, para la cual hay que medir una serie de parámetros en un momento proceso, a través del uso de herramientas útiles que se han nombrado anteriormente.

Cuando medir

Es hora de resolver la pregunta: ¿ha sido exitosa la migración de sitio web? Sin duda esta es la interrogante más importante que todos los involucrados quieren saber, incluso nada más se lanza el sitio a la red para que esté disponible a los usuarios.

Sin embargo, mientras más se espere más clara será la respuesta, ya que la visibilidad durante las primeras semanas e incluso meses puede ser bastante volátil, dependiendo del tamaño e influencia del sitio en cuestión.

 

Ahora, para sitios web más pequeños un periodo de cuatro a seis semanas debería ser más que suficiente, antes de llevar a cabo una comparación de visibilidad entre el sitio nuevo y el previo. En lo que respecta a sitios considerados grandes con cientos de páginas, se debería esperar por lo menos tres meses antes de hacer una medición.

En adición, si el sitio nuevo es significativamente diferente en comparación con el anterior, los usuarios necesitarán algún tiempo para acostumbrarse al nuevo aspecto, diseño y ambiente general del mismo, así como a la nueva taxonomía, orden, menús, recursos, navegación, entre otros.

Por supuesto, tales cambios inicialmente tienen un impacto negativo muy significativo en el rango de conversión del sitio, aunque el mismo debería mejorar en unas semanas mientras los usuarios regresan al sitio y se van acostumbrando. De cualquier manera, llegar a conclusiones de datos obtenidos en este punto sobre la plataforma UX del sitio puede ser riesgoso.

Aunque, lo anteriormente recomendado corresponde a reglas básicas y generales que se toman en cuenta junto a otros factores. Por ejemplo, si algunos días o semanas luego de que el nuevo sitio se lance se llevan a cabo cambios adicionales significativos (como sería abordar un problema técnico) la evaluación de migración de sitio debe ser pospuesta para no comprometer los datos obtenidos.

Cómo llevar a cabo la medición o evaluación

Medir el rendimiento es muy importante, y aunque los inversores del negocio solo estarían interesados en escuchar sobre el beneficio y el impacto positivo de tráfico web, hay otras muchas métricas a las que se les debe prestar atención por su importancia e influencia.

Por ejemplo, pueden haber varias razones por las cuales los beneficios disminuyen consecuentemente de una migración de sitio, incluyendo tendencias de temporada, interés en marca más bajo, problemas de tipo UX que tienen disminuido de manera significativa el rango de conversión del sitio, rendimiento pobre en dispositivos móviles, tiempos de carga largos, entre otros.

Así que, aparte del tráfico orgánico y el beneficio en general que no se niega tienen su importancia, también se debe prestar atención a lo siguiente descrito más abajo:

  1. Visibilidad en equipos de escritorio y dispositivos móviles (de SearchMetrics, SEMrush o Sistric, por ejemplo).
  2. Rankings en equipos de escritorio y dispositivos móviles (de cualquier herramienta de rastreo de ranking confiable).
  3. Compromiso del usuario (rango de rebote tiempo promedio usando el sitio).
  4. Sesiones por tipo de página (ejemplo: si están teniendo las páginas de categoría tantas sesiones como antes).
  5. Rango de conversión por tipo de página (ejemplo: si están haciendo conversión las páginas de productos del mismo modo que antes).
  6. Rango de conversión por dispositivo: (ejemplo: si se ha incrementado o disminuido el rango de conversión ya sea móvil o local desde el lanzamiento del nuevo sitio).

De la misma manera, aunque no resulta completamente necesario revisar lo mostrado más abajo pudiera ser muy útil también, especialmente si se le mira desde el punto de vista de resolver problemas técnicos:

  1. Número de páginas indexadas (se puede usar Search Console).
  2. Páginas ingresadas e indexadas en mapas de sitio XML (Se puede hacer a través de Search Console).
  3. Páginas recibiendo al menos una visita (usando Google Analytics).
  4. Velocidad de sitio (a través de PageSpeed Insights, Lighthouse y Google Analytics).

Así, sólo después de que se han observado y llevado a cabo las áreas anteriormente nombradas, de manera segura se podrá concluir mediante los datos obtenidos si la migración de sitio web fue exitosa o no, también de acuerdo a unas expectativas realistas propuestas en el plan realizado inicialmente donde se tomó en cuenta presupuesto, propósitos y recursos.

Apéndice: Herramientas útiles

Rastreadores

  • Screaming Frog: dicha herramienta es como la navaja suiza en lo que respecta a SEO, ya que es ideal para rastrear pequeñas y medianos sitios web.
  • Sitebulb: Sitebulb es una aplicación de rastreo muy intuitiva con una limpia y clara interfaz de uso, con reportes bien organizados y variados visualización de datos que resultan muy útiles.
  • Deep Crawl: rastreador especial basado en la nube con la habilidad de rastrear sitios en desarrollo, así como hacer comparaciones de rastreo. Del mismo modo, Deep Crawl permite ser utilizado en grandes sitios.
  • Botify: otra herramienta poderosa de rastreo basada en la nube, la cual tiene habilidades excepcionales de análisis de archivo de registro del servidor, y que pueden ser muy detalladas en términos de entender cómo los motores de búsqueda rastrean un sitio.
  • On-Crawl: On-Crawl es un rastreador y analizador de registro de servidor para auditorías de SEO de empresas, la cual incluye muchas herramientas útiles como identificar presupuestos de rastreo, calidad de contenido y problemas de rendimiento, entre otros.

Útiles complementos del navegador Chrome de Google

  • Web Developer: es una colección de herramientas del desarrollador que incluyen sencillas maneras de activar y desactivar JavaScript, CSS, imágenes, entre otros.
  • User Agent Switcher: dicha herramienta permite cambiar entre diferentes agentes de usuario que incluyen Googlebot o robots de Google, móvil y otros agentes.
  • Ayima Redirect Path: Ayima es un gran comprobador de redirecciones, etiquetas y títulos.
  • SEO Meta in 1 Click: esta herramienta es un inspector de meta atributos, encabezados y enlaces que trabaja directamente en el navegador en página.
  • Scraper: una manera fácil de raspar información de sitios web que los organiza en una hoja de trabajo o registro.

Herramientas de monitoreo de sitio

  • Uptime Robot: página web gratuita de monitoreo de tiempo de actividad.
  • Robotto: herramienta gratuita de monitoreo de archivos Robots.txt.
  • Pingdom Tools: página que monitorea tiempo de actividad y velocidad de página de usuarios reales (servicio RUM).
  • SEO Radar: herramienta que monitorea todos los elementos críticos de tipo SEO y que emite alertas cuando son modificados por alguna razón.

Herramientas de rendimiento de sitio web

  • PageSpeed Insights: mide el rendimiento de la página en su plataforma móvil y de escritorio, así como también comprueba si una página ha aplicado las mejores prácticas comunes de rendimiento, dando un resultado que tiene un rango de 0 a 100 puntos.
  • Lighthouse: Lighthouse es una útil extensión o complemento de Chrome para saber el rendimiento, accesibilidad y realizar auditorías de Aplicaciones Web Progresivas en el sitio. De la misma manera, Lighthouse puede ejecutarse desde la línea de comandos o desde un módulo Node.
  • Webpagetest-org: dicha página es una herramienta de pruebas detallada de varias ubicaciones, conexiones y dispositivos, incluyendo gráficos en cascada muy precisos y con bastante información.

Herramientas de prueba de data estructurada

  • Google Structured Data Testing Tool.
  • Google Structured Data Testing Tool Chrome Extension.
  • Bing Markup Validator.
  • Yandex Structured Data Testing Tool.
  • Google Rich Results Testing Tool.

Herramientas de prueba móvil

  • Google Mobile-Friendly Testing Tool.
  • Google AMP Testing Tool.
  • AMP Validator Tool.

Fuentes de datos de enlaces

  • Ahrefs
  • Majestic SEO.

(Fuente: moz.com/blog/website-migration-guide Traducción de esta increíble y completa Guía de nuestros amigos de MOZ)

Puntúalo!

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Cargando…

Deja una respuesta