5 errores de migración de sitios SEO a evitar con Sara Moccand

¿Alguna vez ha estado involucrado en una migración catastrófica de un sitio web? Tal vez lo hayan incluido en un proyecto para lidiar con los efectos de una migración de sitio web mal pensada.

Hoy vamos a discutir cinco errores clave que debe evitar al migrar su sitio web con una mujer que el año pasado se rindió y se suscribió a Netflix y Disney Plus. Es coanfitriona de la reunión de SEO Nerds Suiza y especialista en SEO en Liip, una agencia de desarrollo web y móvil con seis oficinas en Suiza. Una cálida bienvenida al podcast In Search SEO, Sara Moccand.

Los errores a evitar son:

1. Planificación deficiente
2. No probar redireccionamientos
3. No auditar la puesta en escena
4. Migrar en un período de alta demanda
5. Tener la puesta en escena indexada

5 consejos de migración de sitios para vigilar

sara: hola

D: Hola, Sara. Puedes encontrar a Sara en liip.ch. Sara, ¿por qué la migración de sitios web es un problema tan grande para los SEO?

S: Principalmente porque puedes perder todo el tráfico orgánico que es la fuente de ingresos, diría yo. Esa es la razón principal, por lo que todos deben tener mucho cuidado con la migración de su sitio web.

D: Entonces, hoy hablaremos sobre los cinco errores clave que debe evitar al migrar su sitio web. Comenzando con el número uno, mala planificación.

1. Mala planificación

S: Sí, uno de los mayores errores es la mala planificación. Tengo un par de ejemplos. Una mala planificación puede comenzar desde el principio. Por ejemplo, en una agencia, vender el número de días equivocado, lo que significa que hay que volver a discutir el presupuesto, lo que lo hace extremadamente complicado. Hay varios ejemplos pero empecemos por los principales problemas. Obviamente, no se implementan las cosas de la manera deseada si no se planifica correctamente. El segundo problema, como decía antes, es la pérdida de tráfico. Ese es el escenario catastrófico, pérdida de tráfico, y la solución a esto es aprender el nombre de todos los involucrados. Ese es el secreto. Aprende quién es el desarrollador, quién es el front-end, el backend, el diseñador, etc. Aprende todo lo que puedas sobre sus nombres y lo que hacen para que siempre puedas contactarlos.

Cada migración de sitio web es como un nuevo proyecto. Entonces tienes el proyecto, que luego tiene un plan. Y ahí es donde puedes ver exactamente dónde puede interactuar el SEO. Eso es importante tenerlo en cuenta. Por ejemplo, al principio, los desarrolladores saben qué hacer, elegirán la tecnología con la que trabajar. Entonces es interesante para un SEO saber qué tecnología planea usar. Y tal vez también pueda influir en la tecnología que se utiliza. A veces, no muy a menudo, pero a veces. Este es solo un ejemplo sobre cómo aprender la planificación general y descubrir dónde puede interactuar.

D: Hay muchas cosas que puede incluir en un plan, por supuesto, pero ¿hay elementos estándar que incorporaría dentro de un plan? ¿O cada proyecto es bastante único?

S: Yo diría que hay tres cosas estándar. Sabiendo cuándo se elige la tecnología, sabiendo cuándo el diseñador comenzará a diseñar la arquitectura del sitio web y sabiendo en qué punto se pondrá en marcha, entonces puede analizar la puesta en escena para asegurarse de cuándo se pondrán en marcha. Esto me lleva al desglose de la migración del sitio web. Tienes tu plan y luego lo divides en fases. Primero está la fase de preparación, que es donde interactúas con los desarrolladores. Y allí también tienes que analizar cómo está el sitio web, qué páginas son importantes, etc. Y también prepararás tu mapa de redirección. La siguiente fase es tener la fase de prueba en la que se prueba todo porque todo lo que esté en preparación se activará al 100 %, por lo que si hay un problema allí, habrá un problema después.

D: También mencionaste las URL allí. Supongo que algunas migraciones de sitios web son más fáciles que otras. Algunos podrían estar migrando servidores y manteniendo la misma tecnología, CMS, posiblemente también las mismas URL... ¿Qué sucede si está cambiando cada URL o la mayoría de las URL porque tiene que hacerlo? ¿Quizás está pasando de algo que tiene ASP, por ejemplo, al final de las URL a una URL bastante simple? ¿Es posible mantener todas sus clasificaciones y cambiar las URL al mismo tiempo?

S: Como trabajo en una empresa de desarrollo, la gente viene a hacer eso. No vienen solo a cambiar un poco el servidor. Lo que quieren hacer es exactamente eso. Quieren cambiarlo todo. Ese es mi problema. Así que sí, funciona. Tienes que hacer tus redireccionamientos, tienes que hacer tu mapa de redireccionamiento y tienes tiempo en el que los motores de búsqueda necesitan adaptarse un poco. La mayoría de las veces funciona bien, porque cuando haces tu mapa de redireccionamiento, el objetivo es hacerlo de manera inteligente. Por ejemplo, sabe que si una página está clasificada por algo específico, la redirigirá al mismo tema. Luego, debe tener un poco de cuidado en su mapa de redirección, y luego funciona. Una vez más, el escenario de la mayoría de los casos que he visto es exactamente donde cambiaron todo.

D: Otra pregunta de seguimiento en relación con lo que dijiste. Dijiste que a veces los motores de búsqueda necesitan un poco de tiempo para adaptarse. ¿Cuánto tiempo es razonable darle a los motores de búsqueda antes de que veas las mismas clasificaciones que tenías antes?

S: No, quise decir antes de que entraras en pánico. Diría que depende, pero he visto algunas veces que no cambian todo, pero cambian bastante y se adaptan bastante rápido. Yo diría un máximo de un mes, un mes y medio. Y si después de eso no se adapta, entonces hay algún problema en alguna parte.

D: Pasemos al número dos, sin probar los redireccionamientos.

2. No probar los redireccionamientos

S: Sí. Hagamos un par de ejemplos en el muro de la vergüenza donde lo hice mal. Recuerdo que al principio organicé mi mapa de redirección y todos los archivos estaban bien. Luego se lo di al desarrollador para que preparara todo lo que probé. Y dije que todo está bien. Luego salió en vivo. Y cuando salimos en vivo, me preguntaba qué estaba pasando. Y luego me di cuenta de que estaba generando una cadena de redireccionamiento, lo que me sorprendió un poco. Así que tuve la suerte de tener una muy buena relación con los desarrolladores, quienes pudieron arreglar eso en el acto. Ese fue un escenario de caso en el que probé, pero no lo hice lo suficientemente bien, porque no me di cuenta antes de ponerlo en marcha.

Otra vez en el muro de la vergüenza y ser consciente de lo importante que es probar todo a la perfección. Recuerdo que había un sitio web con muchos países, pero había un rol específico para la URL. Así que le pedí al desarrollador que me ayudara a hacer un script para que podamos ir más rápido. Hizo el guión y luego reservé medio día con el desarrollador para hacer la prueba, pero luego dijo: "Oye, Sara, lo probé". Fantástico. Si ya lo hiciste, fantástico. Pero déjame probar un país. Así que lo probé en los EE. UU. y dije: "Todo está funcionando. Excelente. Gracias. Adiós. ¡Dame cinco!" Luego salimos en vivo. Revisé todo y cuando lo comprobé estaba, ”¿Qué está pasando? ¿Qué es saltar? ¿Dónde están Japón y Kuwait? Veo que migramos todo, pero nos faltaban Japón y Kuwait, de lo que no me di cuenta antes de que se pusieran en marcha. Y nuevamente, tuve suerte porque me ayudaron a recuperarlo de inmediato, por lo que no hubo repercusiones reales porque sucedió el día que corregimos todo. Pero eso es un problema. Tienes que probar.

D: Supongo que eso también se relaciona con el punto tres porque el punto tres no es auditar la puesta en escena.

3. No auditar la puesta en escena

S: Sí, eso es parte del punto tres. Al principio tenía mis boletos, los revisaba y todo estaba bien en la puesta en escena. Fantástico. Los boletos están implementados. Pero luego me di cuenta de que no estaba auditando como lo haría normalmente con un sitio web. Por ejemplo, empiezas a ver cosas raras. Recuerdo este sitio web, que sucedió recientemente y en el lado del servidor se mostraba perfectamente. Pude ver todo en el código de la consola. Así que estaba feliz. Pero tengo un problema con los elementos ocultos, siempre compruebo los elementos ocultos. Lo que sucedió fue que JavaScript se estaba comportando de manera muy extraña. Estaba eliminando todos los textos del elemento oculto. Entonces podrías verlo pero no en el código. Ese es un ejemplo de lo importante que es auditar la puesta en escena del sitio web y verificar toda la implementación.

La otra cosa que debe hacer es tener su propia lista de verificación, reparar la lista de verificación, con todas las tareas, exactamente como una auditoría, y luego siempre puede agregar una columna. Por ejemplo, si usa una hoja de Google, tenga una columna que para esta tarea tengo un boleto, para estas tareas no es obligatorio, podría tomarlo. Por ejemplo, para el caso de JavaScript que di, no abres un ticket, solo lo abres si hay un problema. Y luego das tu lista de prioridades en otra columna, el estado. Qué URL de estado hacer en progreso, y luego comentas. Los comentarios son súper importantes, todo el mundo los quita, pero los comentarios son importantes porque necesitas saber por qué algo se bloquea. Por ejemplo, si una persona está bloqueando u otro ticket está bloqueando, debe saber bloquearlo. Eso se trata un poco de auditar la puesta en escena y su importancia. Depende, pero algunos desarrolladores también usarán, por ejemplo, el noindex en todas las páginas, en el código. Y luego se olvidarán de quitarlo cuando salgan en vivo. El problema es que debe saber que lo están usando para que pueda pedirles que recuerden eliminar el noindex antes de lanzarlo, por favor.

D: Y el punto número cuatro a evitar es migrar en un período de alta demanda.

4. Migrar en un período de alta demanda

S: Sí. Esto debería ser obvio porque tienes este problema de perder tráfico, o al menos por un corto período de tiempo, no siempre es así. Nuevamente, depende de la migración del sitio web, pero existe el riesgo de tiempo de adaptación. Y luego si tienes tiempo para otras actividades… Digamos que estás en eCommerce. Probablemente entre octubre y finales de diciembre, no desea migrar su sitio web porque se acerca la Navidad y mucha gente comprará a través de su tienda de comercio electrónico. El cliente normalmente sabe que en ese periodo tiene una alta demanda. Así puedes consultar con el cliente sus analíticas para evitar algún problema.

D: Mencionaste anteriormente que algunos desarrolladores podrían incluso poner noindex en cada página para tratar de evitar que se indexen las páginas. El error número cinco es tener indexada la puesta en escena. ¿Recomendaría esa etiqueta noindex en cada página en el entorno de ensayo para evitar ese tipo de cosas?

5. Tener la puesta en escena indexada

S: No, la protección con contraseña siempre es la solución. Puede hacer noindex pero, como en mi ejemplo, puede olvidarse cuando vaya a vivir. Al final, la mejor solución que siempre funciona es estar protegido por contraseña, punto final. Recuerdo una vez que indexaron la puesta en escena hace algunos años, y esa fue probablemente la experiencia más impactante que tuve. La puesta en escena se indexó y el problema era… podías comprar entradas en el sitio web y el problema era que las personas que intentaban comprar las entradas en el sitio web de la puesta en escena eran un poco catastróficas. ¿Te imaginas a la gente tratando de comprar en el sitio web provisional? Entonces me contactaron diciendo que tienen este problema. Y pudimos resolverlo ya que es relativamente fácil de resolver. Ese es probablemente uno de los puntos principales para mí. Una vez que los desarrolladores instalaron la protección con contraseña y colocaron el archivo noindex. Por lo tanto, debo tener cuidado no solo para verificar que esté protegido con contraseña, sino también para verificar el archivo noindex.

D: Estoy seguro de que podría haber ampliado esta conversación a 101 errores para evitar al migrar nuestro sitio web, pero con suerte, tenemos sus cinco principales allí. Como siempre, ese es un gran material de Sara allí. Terminamos con el Pareto Pickle. Pareto dice que puedes obtener el 80% de tus resultados con el 20% de tus esfuerzos. ¿Cuál es una actividad de SEO que recomendaría que proporcione resultados increíbles con niveles modestos de esfuerzo?

The Pareto Pickle - Planificación de la migración del sitio web

S: Para mí, en la migración de un sitio web es la planificación. Tómese un poco de tiempo en la planificación. No es una enorme cantidad de tiempo en comparación con el trabajo que tienes que hacer. Si tiene una estructura, entonces no comete errores y luego se ahorra mucho tiempo porque para cada error, debe pedir tiempo para recuperarse de los errores, así que definitivamente planee.

D: Planifique adecuadamente. He sido su anfitrión, David Bain. Puedes encontrar a Sara en liip.ch. Sara, muchas gracias por estar en el podcast In Search SEO.

S: Gracias.

D: Y gracias por escuchar.