Hace años y años, era bastante común ver sitios diferentes que tienen sus blogs en diferentes formatos. Algunos usan subdominios, blog.example.com y otros subdominios para otras subsecciones de su sitio. Podrían tener el blog, y comprar.example.com para una tienda, y así sucesivamente. Otros sitios utilizan subcarpetas de la misma manera.
Estas das, es relativamente raro ver subdominios utilizados para gran parte de cualquier cosa. Todavía existen, principalmente en sitios más antiguos que han decidido ir all-in en lugar de realizar una migración costosa, pero la mayoría de los sitios nuevos están configurados para usar subcarpetas. Es mucho más probable que vea example.com/blog hoy, particularmente porque ese es el comportamiento predeterminado de muchos sistemas CMS de blogs, incluido WordPress.
Tal vez eres un blog más viejo, o eres un blog más nuevo que decidió usar un subdominio por motivos estilísticos, y has decidido cambiar. Independientemente de su motivo para realizar el cambio, debe asegurarse de minimizar los riesgos de dicha migración.
Los riesgos de cambiar las URL
Mover tu blog de un subdominio a una subcarpeta es tan arriesgado como cualquier otro cambio de URL importante. Cambiar de un / blog / año / mes / día / formato a un / blog / post-título / formato tendría los mismos riesgos .
¿Cuáles son esos riesgos? Principalmente, se trata de la pérdida de valor SEO de la antigua URL. Ver, Google identifica una página por su URL. Aquí es de donde provienen muchas penalizaciones basadas en URL. Si varias URL tienen el mismo contenido, verá advertencias de contenido duplicadas o robadas. Si el contenido en una URL desaparece, esa página pierde todo el valor SEO.
Cuando migra de una URL a otra, ya sea un cambio en el dominio, un cambio de subdominio a subcarpeta, un cambio en la estructura de la URL o cualquier otra cosa, corre el riesgo de que desaparezcan sus antiguas URL. Si de repente su blog completo desapareció, puede apostar a que su sitio perderá un montón de ranking de búsqueda. Después de todo, el objetivo principal de un blog es clasificar su sitio en una serie de consultas diferentes, para que más personas entren cuando busquen información relevante.
Si no toma medidas para decirle a Google que se trató de una migración y no de una eliminación o duplicación, se le va a marcar en su clasificación de búsqueda. Si mueve su blog y no elimina el blog anterior, de repente tiene cientos o miles de instancias de contenido duplicado, destruyendo su rango. Si mueve el blog y elimina la versión anterior sin las garantías adecuadas, desapareció un montón de contenido y perderá su clasificación hasta que Google descubra lo que sucedió.
Lo que describí a continuación son los pasos que debes seguir para migrar tu blog de un subdominio a una subcarpeta de forma segura. Todavía puede ver cierta fluctuación en el ranking de búsqueda, pero idealmente las cosas se calmarán rápidamente y no perderá el ranking de la oferta.
Mueva el blog en sí
Hay tres posibles opciones para hacer esta migración de blog.
- Duplique el blog en la nueva ubicación y canonicalice la nueva ubicación.
- Duplique el blog en la nueva ubicación y redirija la ubicación anterior.
- Duplique el blog en la nueva ubicación y elimine / redireccione la ubicación anterior.
Entre estos tres, cada uno tiene sus propios problemas.
El número 1 tiene el problema de mantener contenido duplicado en vivo en su sitio. Si la misma publicación de blog está en el subdominio y en la subcarpeta, Google verá dos ubicaciones diferentes para el mismo contenido y emitirá una penalización de duplicación a través de Panda. Idealmente, la canonización de la nueva ubicación debería resolver el problema. La canonización es esencialmente una bandera en ambas ubicaciones que le dice a Google cuál es la verdadera ubicación real. Si convierte la nueva ubicación en la URL canónica, Google eventualmente comenzará a reemplazar la antigua con la nueva en la mayoría de las consultas que no especifican la ubicación anterior como un objetivo de búsqueda.
El problema aquí es que a veces la canonización no es suficiente. También terminas dividiendo tu tráfico. Algunas personas ingresarán a la nueva URL, algunas llegarán a la anterior, y es mucho más difícil medir el rendimiento de una publicación cuando se dividen las métricas.
El número 2 es quizás el ideal. Dejas vivo el antiguo emplazamiento e implementa un redireccionamiento desde él hasta la nueva ubicación. Google se dará cuenta rápidamente de que realizó el cambio, y ningún usuario podrá llegar a la ubicación anterior a menos que la redirección falle. Sin embargo, si la redirección falla, la versión anterior todavía existe como alternativa.
El objetivo aquí es utilizar esta alternativa hasta que el tráfico en general se reduzca a la ubicación anterior, en cuyo punto puede eliminar la reserva. Sin embargo, no debes eliminar el redireccionamiento; en caso de que los enlaces antiguos sigan vivos, los quiere apuntando al destino correcto.
El número 3 es el mismo que el número 2, pero salta adelante para eliminar el contenido de la ubicación anterior. Siempre que la redirección esté en su lugar, prácticamente todos deberían terminar en la nueva ubicación, independientemente de su origen. El único problema proviene de cuando un redireccionamiento no funciona, en cuyo caso el usuario aterrizará en una página 404. Siempre que pueda manejar esto de manera efectiva, es una solución perfectamente viable.
Independientemente del método que use, recomiendo algunos consejos:
- Duplicar el blog a la nueva URL y probar para asegurarse de que funciona antes de eliminar la versión anterior del contenido.
- Durante la prueba, siempre que ambas copias estén activas, haga que la nueva versión no esté indexada para evitar penalizaciones de SEO.
- Cuando implemente la canonización, los redireccionamientos y la nueva versión en vivo, asegúrese de eliminar el comando noindex.
Desea minimizar el tiempo en que ambas versiones están en vivo y visibles para Google, por lo que no recibirá una penalización por contenido duplicado mientras se encuentra en el medio de la migración.
Asegúrese de utilizar URL optimizados para SEO
Mientras realiza esta migración, asegúrese de utilizar una estructura de URL compatible con las búsquedas. Muchos blogs antiguos usan una estructura de URL basada en parámetros, algo así como blog / post =? 20170921. En su lugar, debe usar URL legibles por humanos, algo así como blog / post / title-of-the-post-with-guiones.
Si ya usó URL amigables para el SEO con su subdominio, debe esforzarse por mantenerlas en su subcarpeta. Cuanto menos cambios hagas, mejor. La única razón por la que recomiendo más cambios sobre menos en el caso de las URL basadas en parámetros es porque puede beneficiar a su SEO una vez que todo se haya establecido. Si no necesita realizar el cambio, no lo haga. Si no está seguro, lea esta publicación para conocer las mejores prácticas para estructurar URL.
Redirigir URL antiguas a nuevas URL
Una vez que tenga las URL antiguas y nuevas establecidas y disponibles, debe implementar sus redireccionamientos. Una redirección le dice al tráfico que llega a A que vaya a B en su lugar, y lo hace a nivel de servidor, incluso antes de que su página realmente comience a cargarse.
Hay un montón de diferentes tipos de redireccionamientos , pero Google recomienda usar el redireccionamiento 301. Una redirección 301 es una redirección permanente y pasa su valor SEO, enlace de jugo, y así sucesivamente a la nueva ubicación. Una redirección 302, por ejemplo, es una redirección temporal y no transfiere el valor SEO. Como su migración es permanente, asegúrese de implementar un redireccionamiento 301.
Implementar canonicalización en nuevas URL
Incluso si piensa que tiene todas las posibilidades cubiertas con sus redireccionamientos, asegúrese de implementar la canonicalización . Es bastante fácil; todo lo que necesita hacer es agregar un indicador rel = canonical URL a cada página, apuntando a la versión apropiada de la página. Es bastante fácil de hacer.
La canonicalización es importante por otras razones también. Por ejemplo, https://www.example.com y https://example.com son la misma página, pero con diferentes URL. Si mantienes a ambos activos, corres el riesgo de que Google divida el enlace del enlace o emitiendo penalizaciones por duplicación. Google generalmente es lo suficientemente inteligente como para no hacer esto para las versiones de páginas www / non-www, pero aún puede entrar en juego. También ocurre con example.com/post y example.com/post&utmsource=source, etc., junto con otros parámetros de URL diferentes. El punto es que Google a veces es lo suficientemente inteligente como para ignorar estos, pero a veces no, y la canonización es importante para resolver las cosas .
Mantener el antiguo subdominio (por un tiempo)
Independientemente de si elimina los archivos de contenido anteriores o los mantiene ocultos detrás de redirects / noindex / canonicalization, al menos necesita mantener activo el antiguo subdominio para que los redireccionamientos funcionen. Si elimina completamente la versión anterior, simplemente se convierte en 404 y la redirección falla.
Puede resolver esto utilizando redirecciones a nivel de servidor en lugar de redirecciones a nivel de página, como en este script , aunque necesita agregar una línea para asegurarse de que el redireccionamiento sea un 301. Reemplace [L] con [L, R = 301 ] y eso debería estar bien.
No tiene que mantener la versión anterior indefinidamente, aunque no hay realmente una razón para no hacerlo. Técnicamente, una vez que hayas alcanzado un punto donde el contenido antiguo no ha tenido un solo golpe en años, no lastimarás nada al eliminarlo. Depende de usted si eso es suficiente para eliminar, sin embargo.
Enviar un nuevo mapa del sitio a Google
Una vez que haya redirigido correctamente la versión anterior de su blog y la nueva versión sea en vivo, visible, canónica y funcional, estará mejor listo. Desde este punto, está buscando errores, problemas y asistencia.
Uno de esos puntos de asistencia es generar una nueva versión de su mapa del sitio que elimine las versiones anteriores. Google rechazará un mapa del sitio que muestre las URL antiguas cuando las versiones anteriores redirijan a las nuevas versiones. Básicamente, considere un mapa del sitio como una instantánea de su sitio web de la manera que desea; todo lo que quieres está allí, todo lo que no es no lo es. Envíe ese nuevo mapa a Google a través de la consola de herramientas de su webmaster.
Ejecutar un control de enlace roto
A continuación, debe escanear su sitio con algún tipo de rastreador de URL o comprobador de enlace roto . Hay complementos de WordPress que escanearán esto por usted, o puede usar herramientas de terceros como Screaming Frog para hacer una auditoría de sitio / contenido.
Lo que está buscando son casos en que los enlaces en su contenido apuntan a versiones anteriores de las páginas. Puede revisarlos y actualizarlos para que apunten a las nuevas URL, en lugar de hacer que un usuario pase por una redirección innecesaria desde un punto de su sitio a otro. Es un poco más rápido y tiene más sentido para proteger su sitio en el futuro.
Enviar mensajes para reemplazar enlaces antiguos
Si lo desea, en este momento puede usar herramientas como Ahrefs y Majestic para extraer su perfil de vínculo de retroceso, y luego enviar correos electrónicos a los propietarios de sitios que importan, o a todos los sitios que lo enlazan, si lo desea, pidiéndoles que ajusten los enlaces a Tú sitio.
No tiene que hacer esto, y de hecho muchos webmasters no se molestarán en ajustar los enlaces antiguos. En muchos casos, esos enlaces no reciben ningún tráfico de todos modos, y para los que sí lo hacen, puede enviar más correos electrónicos personales y personalizados a esos webmasters.
De nuevo, sin embargo, esto no es necesario siempre y cuando tenga los redireccionamientos en su lugar. Siempre que Google y los usuarios puedan hacer clic en el enlace y llegar al destino correcto, todo estará bien. Google no lo penalizará por otro sitio web que no cambie sus enlaces.
Reconsiderar el movimiento
Si todo esto parece mucho trabajo y hay mucho margen para el error, siempre puede simplemente no hacer la migración después de todo. Realmente no hay una razón para hacerlo por sí mismo. Matt Cutts y John Mueller han dicho en varias ocasiones que no importa si su blog está en un subdominio o una subcarpeta, siempre que las prácticas de SEO circundantes sean válidas.
Si desea un aspecto más basado en datos, CognitiveSEO recopiló muchas historias y estudios de casos sobre las personas que realizan la migración en una dirección u otra, analizando si es beneficioso o no, y determinó que cualquier beneficio o pérdida generalmente se debe a otros factores, no a la migración en sí misma.
No hay comentarios:
Publicar un comentario