Migración de sitio web: pasos para evitar pérdidas

La redirección de URLs es la práctica de resolver una URL existente hacia una diferente, indicando eficazmente a sus visitantes y a Google Search que una página tiene una nueva ubicación. Las redirecciones son especialmente útiles en las siguientes circunstancias:

Ha trasladado su sitio a un nuevo dominio y desea que la transición sea lo más fluida posible.

Los usuarios acceden a su sitio a través de varias URLs diferentes. Si, por ejemplo, se puede acceder a su página de inicio de varias formas (por ejemplo, http://example.com/home, http://home.example.com o http://www.example.com), es una buena idea elegir una de esas URLs como su destino preferido (canónico) y utilizar redirecciones para enviar el tráfico de las otras URLs a su URL preferida.

Está fusionando dos sitios web y quiere asegurarse de que los enlaces a URLs obsoletas se redirijan a las páginas correctas.

Si utiliza una plataforma como Blogger o Shopify, es posible que la plataforma ya tenga soluciones de redirección integradas. Intente buscar artículos de ayuda (por ejemplo, busque “redirecciones de blogger”).

Descripción general de los tipos de redirección

Aunque sus usuarios generalmente no podrán notar la diferencia entre los distintos tipos de redirecciones, Google Search utiliza las redirecciones como una señal fuerte o débil de que el destino de la redirección debe ser el canónico. La elección de una redirección depende de cuánto tiempo espera que la redirección esté vigente y qué página desea que Google Search muestre en los resultados de búsqueda:

La siguiente tabla explica las diversas formas que puede utilizar para configurar redirecciones permanentes y temporales, ordenadas según la probabilidad de que Google pueda interpretarlas correctamente (por ejemplo, una redirección del lado del servidor tiene la mayor probabilidad de ser interpretada correctamente por Google). Elija el tipo de redirección que funcione para su situación y sitio:

Redirecciones del lado del servidor

La configuración de redirecciones del lado del servidor requiere acceso a los archivos de configuración del servidor (por ejemplo, el archivo .htaccess en Apache) o establecer los encabezados de redirección con scripts del lado del servidor (por ejemplo, PHP). Puede crear redirecciones permanentes y temporales en el lado del servidor.

Redirecciones permanentes del lado del servidor

Si necesita cambiar la URL de una página tal como se muestra en los resultados de los motores de búsqueda, le recomendamos que utilice una redirección permanente del lado del servidor siempre que sea posible. Esta es la mejor manera de garantizar que Google Search y las personas sean dirigidas a la página correcta. Los códigos de estado 301 y 308 significan que una página se ha movido permanentemente a una nueva ubicación.

Redirecciones temporales del lado del servidor

Si solo desea enviar a los usuarios a una página diferente de forma temporal, utilice una redirección temporal. Esto también garantizará que Google mantenga la URL antigua en sus resultados durante más tiempo. Por ejemplo, si un servicio que ofrece su sitio no está disponible temporalmente, puede configurar una redirección temporal para enviar a los usuarios a una página que explique lo que está sucediendo, sin comprometer la URL original en los resultados de búsqueda.

Implementar redirecciones del lado del servidor

La implementación de redirecciones del lado del servidor depende de su entorno de alojamiento y servidor, o del lenguaje de scripting del backend de su sitio.

Para configurar una redirección permanente con PHP, utilice la función header(). Debe establecer los encabezados antes de enviar nada a la pantalla:

Si tiene acceso a los archivos de configuración de su servidor web, es posible que pueda escribir las reglas de redirección usted mismo. Siga las guías de su servidor web:

Apache: Consulte el Tutorial de .htaccess de Apache, la Guía de reescritura de URLs de Apache y la documentación de Apache mod_alias. Por ejemplo, puede usar mod_alias para configurar la forma más sencilla de redirecciones:# Redirección permanente: Redirect permanent “/old” “http://example.com/new” # Redirección temporal: Redirect temp “/two-old” “http://example.com/two-new”Para redirecciones más complejas, use mod_rewrite. Por ejemplo:RewriteEngine on # redirigir la página de servicio a una nueva página con una redirección permanente RewriteRule “^/service$” “/about/service” [R=301] # redirigir la página de servicio a una nueva página con una redirección temporal RewriteRule “^/service$” “/about/service” [R]

NGINX: Lea sobre la creación de reglas de reescritura de NGINX en el blog de NGINX. Al igual que con Apache, tiene múltiples opciones para crear redirecciones. Por ejemplo:location = /service { # para una redirección permanente return 301 $scheme://example.com/about/service # para una redirección temporal return 302 $scheme://example.com/about/service }Para redirecciones más complejas, use la directiva rewrite:location = /service { # para una redirección permanente rewrite service?name=$1 ^service/offline/([a-z]+)/?$ permanent; # para una redirección temporal rewrite service?name=$1 ^service/offline/([a-z]+)/?$ redirect; }

Para todos los demás servidores web, consulte con su administrador de servidor o proveedor de alojamiento, o busque guías en su motor de búsqueda favorito (por ejemplo, busque “redirecciones de LiteSpeed”).

meta refresh y su equivalente HTTP

Si no es posible implementar redirecciones del lado del servidor en su plataforma, las redirecciones meta refresh pueden ser una alternativa viable. Google diferencia entre dos tipos de redirecciones meta refresh:

Redirección meta refresh instantánea: Se activa tan pronto como la página se carga en un navegador. Google Search interpreta las redirecciones meta refresh instantáneas como redirecciones permanentes.

Redirección meta refresh retrasada: Se activa solo después de un número arbitrario de segundos establecido por el propietario del sitio. Google Search interpreta las redirecciones meta refresh retrasadas como redirecciones temporales.

Coloque la redirección meta refresh en la sección head del HTML o en el encabezado HTTP con código del lado del servidor. Por ejemplo, aquí hay una redirección meta refresh instantánea en la sección head del HTML:

Aquí hay un ejemplo del equivalente de encabezado HTTP, que puede inyectar con scripts del lado del servidor:

Para crear una redirección retrasada, que Google interpreta como una redirección temporal, establezca el atributo content en el número de segundos que debe retrasarse la redirección:

Redirecciones de ubicación de JavaScript

Google Search interpreta y ejecuta JavaScript utilizando el Web Rendering Service una vez que se ha completado el rastreo de la URL. Utilice redirecciones de JavaScript solo si no puede realizar redirecciones del lado del servidor o meta refresh. Aunque Google intenta renderizar cada URL que Googlebot rastreó, el renderizado puede fallar por varias razones. Esto significa que si configura una redirección de JavaScript, es posible que Google nunca la vea si el renderizado del contenido falló.

Para configurar una redirección de JavaScript, establezca la propiedad location en la URL de destino de la redirección en un bloque de script en el head del HTML. Por ejemplo:

Cripto-redirecciones

Si no puede implementar ninguno de los métodos de redirección tradicionales, aún debe esforzarse por informar a sus usuarios que la página o su contenido se ha movido. La forma más sencilla de hacerlo es agregar un enlace que apunte a la nueva página acompañado de una breve explicación. Por ejemplo:

Esto ayuda a los usuarios a encontrar su nuevo sitio y Google puede entender esto como una cripto-redirección. No confíe en las cripto-redirecciones para informar a los motores de búsqueda que su contenido se ha movido a menos que no tenga otra opción. Comuníquese con su proveedor de alojamiento para obtener ayuda con las redirecciones tradicionales antes de recurrir a las cripto-redirecciones.

Versiones alternativas de una URL

Cuando redirige una URL, Google realiza un seguimiento tanto de la fuente de redirección (la URL antigua) como del destino de la redirección (la nueva URL). Una de las URLs será la canónica; cuál, depende de señales como si la redirección fue temporal o permanente. La otra URL se convierte en un nombre alternativo de la URL canónica. Los nombres alternativos son diferentes versiones de una URL canónica que los usuarios pueden reconocer y en las que pueden confiar más. Los nombres alternativos pueden aparecer en los resultados de búsqueda cuando la consulta de un usuario sugiere que podrían confiar más en la URL antigua.

Por ejemplo, si se mudó a un nuevo nombre de dominio, es muy probable que Google continúe mostrando ocasionalmente las URLs antiguas en los resultados, aunque las nuevas URLs ya estén indexadas. Esto es normal y, a medida que los usuarios se acostumbren al nuevo nombre de dominio, los nombres alternativos desaparecerán sin que usted haga nada.

Recomendaciones para todos los traslados de sitio

Divida su traslado en pasos más pequeños, si tiene sentido para su sitio. Recomendamos mover inicialmente solo una parte del sitio para probar cualquier efecto en el tráfico y la indexación de búsqueda. Después de eso, puede mover el resto de su sitio de una vez o en partes. Al elegir la sección de prueba inicial del sitio, elija una sección que cambie con menos frecuencia y que no se vea afectada significativamente por eventos frecuentes o impredecibles. También tenga en cuenta que, si bien mover solo una sección es una excelente manera de probar su traslado, no es necesariamente representativo de un traslado de sitio completo cuando se trata de búsqueda. Cuantas más páginas mueva, más probable es que encuentre problemas adicionales que resolver. Una planificación cuidadosa puede minimizar los problemas.

Programe su traslado para que coincida con un tráfico menor, si es posible. Si su tráfico es estacional o disminuye ciertos días de la semana, tiene sentido trasladar su sitio durante las caídas de tráfico recurrentes. Esto significa que menos personas se verán afectadas por posibles problemas que pueden ocurrir durante el traslado del sitio, y más recursos de su servidor pueden dedicarse al rastreo de su sitio por parte de Googlebot.

Espere una fluctuación temporal en la clasificación del sitio durante el traslado. Con cualquier cambio significativo en un sitio, puede experimentar fluctuaciones de clasificación mientras Google vuelve a rastrear y reindexar su sitio. Como regla general, un sitio web de tamaño mediano puede tardar algunas semanas en mover la mayoría de las páginas en nuestro índice; los sitios más grandes pueden tardar más. La velocidad a la que Googlebot y nuestros sistemas descubren y procesan las URLs movidas depende en gran medida del número de URLs y de la velocidad de su servidor. Enviar un sitemap puede ayudar a que el proceso de descubrimiento sea más rápido, y está bien mover su sitio en secciones.

Haga preguntas en Google Search Central. Hay muchos buenos consejos en nuestra página de ayuda y casos específicos respondidos en nuestros foros de usuarios. Si no puede encontrar una respuesta, puede hacer una pregunta en vivo a uno de nuestros especialistas de Google Search durante nuestro horario de oficina de SEO.

Si implica un cambio de URL, podría considerar una prueba A/B o una prueba piloto. Planifique unas semanas para permitir que el rastreo y la indexación detecten los cambios, además de tiempo para monitorear el tráfico.

Trasladar un sitio sin cambios de URL

Esta guía muestra cómo minimizar el impacto en su rendimiento en Google Search al migrar la infraestructura de alojamiento de su sitio. Por ejemplo, al cambiar de proveedor de alojamiento o al mudarse a una red de distribución de contenido (CDN). Esta guía es solo para migraciones que no afectan la URL visible para el usuario. ¿Cambiar las URLs? Si está realizando cambios visibles en la URL, comience con Traslados de sitio con cambios de URL.

Descripción general

Revise las preguntas frecuentes y la información básica sobre los traslados de sitio. Sepa qué esperar y cómo podría afectar a sus usuarios y clasificaciones.

Prepare la nueva infraestructura de alojamiento. Cargue su contenido en los nuevos servidores o configure su CDN y sus servidores de origen, y pruébelo.

Inicie el traslado del sitio. Cambie la configuración de DNS de su nombre de dominio para que apunte a la nueva infraestructura de alojamiento. Este paso es el paso real de traslado del sitio que inicia el proceso de enviar su tráfico a la nueva infraestructura.

Apague. Apague la antigua infraestructura de alojamiento cuando esté seguro de que todos los usuarios están recibiendo contenido correctamente desde la nueva infraestructura y nadie está utilizando la antigua infraestructura.

Prepare la nueva infraestructura de alojamiento

Copie y pruebe su nuevo sitio

Primero, cargue una copia de su sitio en su nuevo proveedor de alojamiento. Una vez que lo haga, verifique que funcione como se espera probando exhaustivamente todos los aspectos de cómo sus usuarios interactúan con su sitio. Aquí hay algunas sugerencias:

Abra su nuevo sitio en un navegador web y revise todos los elementos de su sitio: páginas web, imágenes, formularios y descargas (como archivos PDF).

Cree un entorno de prueba, tal vez con acceso restringido por IP, a través del cual pruebe todas las funciones antes de que el sitio web se publique.

Permita pruebas públicas con un nombre de host temporal para su nueva infraestructura (como beta.example.com) para que pueda probar la accesibilidad mediante navegadores. Un nombre de host temporal puede ayudarlo a probar si Googlebot puede llegar a su sitio o no.

Verifique que Googlebot pueda acceder a la nueva infraestructura de alojamiento

Si aún no tiene una cuenta de Search Console, cree una nueva cuenta para su sitio para ayudarlo a monitorear el acceso y el tráfico de Google. Si creó un nombre de host temporal para su nuevo sitio, cree una cuenta para ese nombre de host también. Verifique que Googlebot pueda acceder a su nueva infraestructura utilizando la herramienta de inspección de URL en Search Console. Precaución: Verifique la configuración de su firewall o la protección contra denegación de servicio (DoS). Asegúrese de que no bloquee la capacidad de Googlebot para llegar al DNS o a los servidores del proveedor de alojamiento.

Reduzca el valor TTL para sus registros DNS

Puede ayudar a que el traslado de su sitio sea más rápido si reduce el valor TTL de los registros DNS de su sitio, lo que permitirá que la nueva configuración se propague a los ISP más rápidamente. La configuración de DNS suele ser almacenada en caché por los ISP según la configuración de Time to Live (TTL) especificada. Considere reducir el TTL a un valor bajo conservador (por ejemplo, unas pocas horas) al menos una semana antes del traslado del sitio para actualizar las cachés de DNS más rápidamente.

Revise la verificación de Search Console

Si está utilizando el método de archivo HTML para verificar la propiedad de su sitio en Search Console, asegúrese de no olvidar incluir su archivo de verificación actual en su nueva copia del sitio.

Del mismo modo, si incluye en las plantillas de su sistema de gestión de contenido una metaetiqueta o Google Analytics para verificar la propiedad, asegúrese de que la nueva copia del CMS también los incluya.

Inicie el traslado del sitio

Elimine cualquier bloqueo temporal al rastreo. Mientras construye la nueva copia de un sitio, algunos propietarios de sitios utilizan un archivo robots.txt para no permitir todo el rastreo por parte de Googlebot y otros rastreadores, o utilizan metaetiquetas noindex o encabezados HTTP para bloquear la indexación de contenido. Asegúrese de eliminar dichos bloqueos de la nueva copia del sitio cuando esté listo para comenzar el traslado.

Actualice la configuración de DNS. Inicia el traslado del sitio actualizando los registros DNS para que apunten al nuevo proveedor de alojamiento. Consulte con su proveedor de DNS cómo hacerlo. Debido a que la configuración de caché de DNS se almacena en caché, los registros tardan algún tiempo en propagarse por completo a todos los usuarios en Internet.

Monitorear el tráfico

Esté atento a los registros del servidor tanto en los servidores nuevos como en los antiguos. A medida que la configuración de DNS se propaga y el tráfico del sitio se mueve, notará una caída en el tráfico registrado en los servidores antiguos y un aumento correspondiente en el tráfico en los nuevos servidores.

Utilice diferentes herramientas de verificación de DNS público. Verifique que los diferentes ISP de todo el mundo estén actualizando su nueva configuración de DNS correctamente.

Monitorear el rastreo. Monitoree los gráficos de cobertura de índice en Search Console. Deje que Googlebot decida. En lugar de establecer manualmente una tasa de rastreo máxima en Search Console, mantenga la configuración en Dejar que Googlebot decida. De esta manera, la configuración diseñada solo para el sistema antiguo no interferirá con los requisitos de su nuevo sistema.

Una nota sobre la tasa de rastreo de Googlebot

Es normal ver una caída temporal en la tasa de rastreo de Googlebot inmediatamente después del lanzamiento, seguida de un aumento constante durante las próximas semanas, potencialmente a tasas que pueden ser más altas que antes del traslado.

Esta fluctuación ocurre porque determinamos la tasa de rastreo de un sitio en función de muchas señales, y estas señales cambian cuando cambia su alojamiento. Siempre que Googlebot no encuentre problemas graves o ralentizaciones al acceder a su nueva infraestructura de servicio, intentará rastrear su sitio tan rápido como sea necesario y posible.

Apagar el alojamiento antiguo

Verifique los registros del servidor en el proveedor antiguo y, una vez que el tráfico al proveedor antiguo llegue a cero, puede apagar su antigua infraestructura de alojamiento. Esto completa el traslado del sitio.

Trasladar un sitio con cambios de URL

Este artículo describe cómo cambiar las URLs de las páginas existentes en su sitio con un impacto mínimo en sus resultados de Google Search. Ejemplos de este tipo de traslado de sitio incluyen:

¿No cambia las URLs? Si está realizando cambios en el sitio sin cambios visibles en la URL, comience aquí en su lugar.

Descripción general

Revise la información básica sobre los traslados de sitio. Sepa qué esperar y cómo podría afectar a sus usuarios y clasificaciones. Si se traslada de HTTP a HTTPS, revise las mejores prácticas para HTTPS.

Inicie el traslado del sitio configurando el servidor para redirigir desde las URLs antiguas a las nuevas.

Preguntas frecuentes para todos los traslados de sitio con cambios de URL

¿Recomienda Google que mueva todo junto, o está bien moverlo en secciones? Moverlo en secciones está bien.

¿Cómo puede probar cuántas páginas se indexaron? Verifique los datos de cada propiedad por separado en Search Console. Utilice el informe de estado de índice para una vista amplia. Utilice el informe de Sitemaps para ver cuántas URLs enviadas en un sitemap han sido indexadas.

¿Cuánto tiempo tardará Google en reconocer los cambios de URL? No hay frecuencias de rastreo fijas; depende del tamaño de su sitio y de la velocidad de rastreo que sea posible. El traslado se realiza por URL.

¿Pierde crédito por los enlaces cuando redirige a nuevas URLs? No, las redirecciones 301 o 302 no causan una pérdida en PageRank.

Migración de HTTP a HTTPS

Asegúrese de agregar la propiedad HTTPS a Search Console. Search Console trata HTTP y HTTPS por separado; los datos de estas propiedades no se comparten en Search Console. Por lo tanto, si tiene páginas en ambos protocolos, debe tener una propiedad de Search Console separada para cada una.

Preguntas frecuentes sobre la migración de HTTP a HTTPS

Como con todas las migraciones, puede experimentar alguna fluctuación de clasificación durante una migración. Sin embargo, para evitar problemas específicos de HTTPS, revise la información de mejores prácticas para páginas HTTPS.

Los sitios HTTPS reciben un pequeño impulso en la clasificación, pero no espere un cambio visible. Google utiliza HTTPS como una señal de clasificación positiva. Esta señal es una entre muchas otras, y actualmente tiene menos peso que el contenido del sitio de alta calidad; no debe esperar una ventaja de SEO importante por mudarse a HTTPS a corto plazo. A largo plazo, Google puede aumentar la fuerza del impulso de HTTPS.

Sí, eso está bien. Comience con una parte, pruébela, luego mueva más a su propio ritmo.

Si está migrando de HTTP a HTTPS en partes, y desea evitar la indexación temprana de las URLs puestas en escena, recomendamos usar rel=canonical en lugar de redirecciones. Si usa redirecciones, no podrá probar las páginas redirigidas.

Verifique HTTP y HTTPS por separado en Search Console, y use el informe de cobertura de índice para ver qué páginas se han indexado.

No hay frecuencias de rastreo fijas; depende del tamaño de su sitio y de la velocidad de rastreo que sea posible. El traslado se realiza por URL.

Recomendamos que actualice su archivo robots.txt para que apunte a la versión HTTPS de sus archivos de sitemap. También recomendamos listar solo las URLs HTTPS en su sitemap.

Tenga en cuenta que si está redirigiendo cada URL de su sitio de HTTP a HTTPS, seguirá teniendo solo un archivo robots.txt accesible para los rastreadores. Por ejemplo, si http://example.com/robots.txt redirige a https://example.com/robots.txt, el contenido de la versión HTTP no será visible para Google y otros motores de búsqueda.

Puede crear un sitemap separado solo para la sección actualizada de su sitio. Esto le permitirá rastrear la indexación de la sección de prueba con mayor precisión. Asegúrese de no duplicar estas URLs en ningún otro sitemap, sin embargo.

Liste todas las nuevas URLs HTTPS en su sitemap y elimine las antiguas URLs HTTP. Si prefiere crear un nuevo sitemap, liste solo las nuevas URLs HTTPS en él.

HSTS aumenta la seguridad, pero agrega complejidad a su estrategia de reversión. Consulte las mejores prácticas de HTTPS para obtener más información.

Si desea utilizar un sitemap de Google News para la nueva sección HTTPS, deberá comunicarse con el equipo de News para informarles sobre el cambio de protocolo, y luego en su propiedad HTTPS en Search Console puede enviar un nuevo sitemap de Google News a medida que migra cada sección de su sitio a HTTPS.

Google News Publisher Center maneja los traslados de HTTP a HTTPS de forma transparente. En general, no tiene que hacer nada desde la perspectiva de Google News, a menos que también esté utilizando sitemaps de News. En ese caso, comuníquese con el equipo de News y hágales saber sobre el cambio. También puede informar al equipo sobre el cambio de secciones, por ejemplo, en caso de que se mude a HTTPS, puede especificar que está moviendo http://example.com/section a https://example.com/section.

Prepare el nuevo sitio

Los detalles de la preparación del sitio varían para cada traslado de sitio, pero normalmente hará una o más de las siguientes cosas:

Transfiera imágenes y descargas (como documentos PDF) que aloja actualmente. Es posible que estos ya estén recibiendo tráfico de Google Search o enlaces, y es útil informar a los usuarios y a Googlebot sobre su nueva ubicación.

Para un traslado a HTTPS, obtenga y configure los certificados TLS requeridos en su servidor.

Configure un robots.txt para su nuevo sitio

El archivo robots.txt para un sitio controla qué áreas puede rastrear Googlebot. Asegúrese de que las directivas en el archivo robots.txt del nuevo sitio reflejen correctamente las partes que desea bloquear del rastreo.

Tenga en cuenta que algunos propietarios de sitios bloquean todo el rastreo mientras están en desarrollo. Si sigue esta estrategia, asegúrese de preparar cómo debería verse el archivo robots.txt una vez que comience el traslado del sitio. Del mismo modo, si utiliza directivas noindex durante el desarrollo, prepare una lista de URLs de las que eliminará las directivas noindex cuando comience el traslado del sitio.

Proporcione errores para contenido eliminado o fusionado

Para el contenido en el sitio antiguo que no se transferirá al nuevo sitio, asegúrese de que esas URLs huérfanas devuelvan correctamente un código de respuesta de error HTTP 404 o 410. Puede devolver el código de respuesta de error en la URL antigua en el panel de configuración de su nuevo sitio, o puede crear una redirección para una nueva URL y hacer que devuelva el código de error HTTP. Evite redirecciones irrelevantes

No redirija muchas URLs antiguas a un destino irrelevante, como la página de inicio del nuevo sitio. Esto puede confundir a los usuarios y podría tratarse como un error 404 suave. Sin embargo, si ha consolidado contenido previamente alojado en varias páginas en una nueva página única, es aceptable redirigir las URLs antiguas a esa nueva página consolidada.

Asegure la configuración correcta de Search Console

Si aún no lo ha hecho, verifique que posee tanto el sitio antiguo como el nuevo en Search Console. Asegúrese de verificar todas las variantes tanto del sitio antiguo como del nuevo. Por ejemplo, verifique www.example.com y example.com, e incluya tanto las variantes de sitio HTTPS como HTTP si utiliza URLs HTTPS. Haga esto tanto para el sitio antiguo como para el nuevo.

Asegúrese de que su verificación de Search Console continúe funcionando después del traslado del sitio. Si utiliza un método de verificación diferente, tenga en cuenta que los tokens de verificación pueden ser diferentes cuando cambia la URL.

Si está utilizando el método de archivo HTML para verificar la propiedad de su sitio en Search Console, asegúrese de no olvidar incluir su archivo de verificación actual en su nueva copia del sitio.

Del mismo modo, si verifica la propiedad con un archivo de inclusión que hace referencia a una metaetiqueta o Google Analytics para verificar la propiedad, asegúrese de que la nueva copia del CMS también los incluya.

Si había cambiado algunas de las configuraciones de configuración en Search Console para su sitio antiguo, asegúrese de que la configuración del nuevo sitio se actualice para reflejar esos cambios también. Por ejemplo:

Parámetros de URL: Si ha configurado parámetros de URL para controlar el rastreo o la indexación de sus URLs antiguas, asegúrese de que la configuración también se aplique al nuevo sitio si es necesario.

Geotargeting: Su sitio antiguo podría tener una orientación geográfica explícita, como un dominio orientable geográficamente o un dominio de nivel superior con código de país (como .co.uk). Aplique la misma configuración al nuevo sitio si desea continuar orientándose a la misma región. Sin embargo, si su traslado de sitio tiene como objetivo ayudar a su empresa a expandirse globalmente y no desea que su sitio esté asociado con ningún país o región, seleccione No listado en la lista desplegable de la página Configuración del sitio.

Tasa de rastreo: Recomendamos no limitar la tasa de rastreo de Googlebot en Search Console tanto para las URLs antiguas como para las nuevas. Le recomendamos que tampoco configure una tasa de rastreo. Solo haga esto si sabe que su sitio no puede manejar el volumen de rastreo de Googlebot. Si ya ha limitado la tasa de rastreo de Googlebot para su sitio antiguo, considere eliminarla. Google tiene algoritmos que detectan automáticamente que se ha implementado un traslado de sitio y alteramos el comportamiento de rastreo de Googlebot para que nuestra indexación refleje rápidamente el traslado del sitio.

Backlinks desautorizados: Si ha cargado un archivo para desautorizar enlaces en su sitio antiguo, le recomendamos que lo vuelva a cargar utilizando la cuenta de Search Console del nuevo sitio.

Si su nuevo sitio es para un dominio comprado recientemente, querrá asegurarse de que esté limpio de cualquier problema pendiente del propietario anterior. Verifique la siguiente configuración:

Acción manual por spam anterior. Para los sitios que no cumplen con nuestras políticas de spam, Google está dispuesto a tomar medidas manuales, como degradarlos o incluso eliminarlos de nuestros resultados de búsqueda por completo. Verifique la página Acciones manuales en Search Console para ver si se han aplicado acciones manuales al nuevo sitio, y solucione cualquier problema enumerado allí antes de presentar una solicitud de reconsideración.

URLs eliminadas. Asegúrese de que no queden eliminaciones de URL del propietario anterior, especialmente una eliminación de URL en todo el sitio. Además, antes de enviar solicitudes de eliminación de URL para su contenido, asegúrese de comprender cuándo no utilizar la herramienta de eliminación de URL.

Utilice análisis web

Durante un traslado de sitio, es importante analizar el uso tanto en el sitio antiguo como en el nuevo. El software de análisis web puede ayudar con esto. Normalmente, la configuración de análisis web consiste en una pieza de JavaScript incrustada en sus páginas. Los detalles para rastrear diferentes sitios varían según su software de análisis y su configuración de registro, procesamiento o filtrado. Consulte con su proveedor de software de análisis para obtener ayuda. Además, si ha estado planeando realizar cambios de configuración en su software de análisis, ahora es un buen momento. Si utiliza Google Analytics, considere crear un nuevo perfil para su nuevo sitio si desea una separación limpia en sus informes de contenido.

Asegúrese de que su servidor tenga suficientes recursos informáticos

Después de una migración, Google rastreará su nuevo sitio más intensamente de lo habitual. Esto se debe a que su sitio redirige el tráfico del sitio antiguo al nuevo, y cualquier rastreo del sitio antiguo será redirigido al nuevo sitio, además de cualquier otro rastreo. Asegúrese de que su nuevo sitio tenga suficiente capacidad para manejar el mayor tráfico de Google.

Actualizar el marcador de datos

Si utilizó el marcador de datos para mapear sus páginas antiguas, asegúrese de rehacer el mapeo para su nuevo sitio.

Actualizar enlaces de aplicaciones

Tan pronto como sus páginas HTTPS estén listas, actualice cualquier enlace de aplicación destinado a abrir sus páginas web en una aplicación cuando se muestren en los resultados de Google Search. Actualice estos enlaces para que apunten a las nuevas URLs HTTPS. Las redirecciones no funcionarán para estos enlaces; los clics en el navegador móvil abrirán la página en el navegador en lugar de la aplicación a menos que actualice el manejo de enlaces de su aplicación.

Es importante mapear las URLs de su sitio antiguo a las URLs del nuevo sitio. Esta sección describe una serie de enfoques generales que puede tomar para evaluar correctamente las URLs en sus dos sitios y facilitar el mapeo. Los detalles exactos de cómo genera este mapeo variarán según la infraestructura actual de su sitio web y los detalles del traslado del sitio.

Preparar el mapeo de URLs

Es importante mapear las URLs de su sitio antiguo a las URLs del nuevo sitio. Esta sección describe una serie de enfoques generales que puede tomar para evaluar correctamente las URLs en sus dos sitios y facilitar el mapeo. Los detalles exactos de cómo genera este mapeo variarán según la infraestructura actual de su sitio web y los detalles del traslado del sitio.

Determinar sus URLs antiguas

En los traslados de sitio más simples, es posible que no necesite generar una lista de sus URLs antiguas. Por ejemplo, podría usar una redirección del lado del servidor con comodines si está cambiando el dominio de su sitio (por ejemplo, mudarse de example.com a example.net).

En traslados de sitio más complejos, deberá generar una lista de URLs antiguas y mapearlas a sus nuevos destinos. Cómo obtiene una lista de URLs antiguas depende de la configuración actual de su sitio web, pero aquí hay algunos consejos útiles:

Comience con sus URLs importantes. Para encontrarlas: Busque en sus sitemaps porque es probable que sus URLs más importantes se hayan enviado en Search Console de esa manera

Verifique la función Enlaces a su sitio en Search Console para páginas que tienen enlaces internos y externos

Utilice su sistema de gestión de contenido, que normalmente puede proporcionar una manera fácil de obtener una lista de todas las URLs que alojan contenido.

Verifique los registros de su servidor para las URLs que se visitaron al menos una vez recientemente. Elija un período de tiempo que tenga sentido para su sitio, teniendo en cuenta la variación estacional del tráfico.

Incluya imágenes y videos: Asegúrese de incluir URLs de contenido incrustado en sus planes de traslado de sitio: videos, imágenes, JavaScript y archivos CSS. Estas URLs deben moverse de la misma manera que todo el demás contenido en su sitio web.

Crear un mapeo de URLs antiguas a nuevas

Una vez que tenga la lista de URLs antiguas, decida a dónde debe redirigir cada una. Cómo almacena este mapeo depende de sus servidores y del traslado del sitio. Puede usar una base de datos o configurar algunas reglas de reescritura de URL en su sistema para patrones de redirección comunes.

Actualizar todos los detalles de la URL

Una vez que tenga definido su mapeo de URLs, querrá hacer tres cosas para preparar las páginas para el traslado.

Actualice las anotaciones para que apunten a las nuevas URLs en el HTML o la entrada de sitemaps para cada página: Cada URL de destino debe tener una etiqueta rel=”canonical” autorreferencial.

Si el sitio que trasladó tiene páginas multilingües o multinacionales anotadas usando anotaciones rel-alternate-hreflang, asegúrese de actualizar las anotaciones para usar las nuevas URLs.

Si el sitio que trasladó tiene una contraparte móvil, asegúrese de actualizar las anotaciones rel-alternate-media para usar las nuevas URLs. Obtenga más información en nuestras pautas para sitios web de teléfonos inteligentes.

Actualizar enlaces internos. Cambie los enlaces internos en el nuevo sitio de las URLs antiguas a las nuevas URLs. Puede usar el mapeo generado anteriormente para ayudar a encontrar y actualizar los enlaces según sea necesario.

Guarde las siguientes listas para su traslado final: Un archivo de sitemap que contenga las nuevas URLs en el mapeo. Consulte nuestra documentación sobre la creación de un sitemap.

Una lista de sitios que enlazan a sus URLs antiguas. Puede encontrar los enlaces a su sitio en Search Console.

Prepararse para redirecciones 301

Una vez que tenga un mapeo y su nuevo sitio esté listo, el siguiente paso es configurar redirecciones HTTP 301 en su servidor desde las URLs antiguas a las nuevas URLs como indicó en su mapeo.

Utilice redirecciones HTTP 301. Aunque Googlebot admite varios tipos de redirecciones, recomendamos que utilice redirecciones HTTP 301 si es posible.

Evite encadenar redirecciones. Aunque Googlebot puede seguir hasta 10 saltos en una “cadena” de múltiples redirecciones (por ejemplo, Página 1 > Página 2 > Página 3), recomendamos redirigir al destino final. Si esto no es posible, mantenga bajo el número de redirecciones en la cadena, idealmente no más de 3 y menos de 5. Encadenar redirecciones agrega latencia para los usuarios, y no todos los agentes de usuario y navegadores admiten cadenas de redirección largas.

Pruebe las redirecciones. Puede usar la herramienta de inspección de URL para probar URLs individuales, o herramientas de línea de comandos o scripts para probar grandes números o URLs.

Inicie el traslado del sitio

Decida cómo trasladará su sitio: todo a la vez o en secciones: Sitios pequeños o medianos: Recomendamos mover todas las URLs de su sitio simultáneamente en lugar de mover una sección a la vez. Esto ayuda a los usuarios a interactuar mejor con el sitio en su nueva forma, y ayuda a nuestros algoritmos a detectar el traslado del sitio y actualizar nuestro índice más rápido.

Sitios grandes: Puede optar por mover sitios más grandes una sección a la vez. Esto puede facilitar el monitoreo, la detección y la corrección de problemas más rápidamente.

Actualice sus archivos robots.txt: En el sitio antiguo, elimine todas las directivas robots.txt. Esto permite que Googlebot descubra todas las redirecciones al nuevo sitio y actualice nuestro índice. Tenga en cuenta que los rastreadores no verán el contenido del archivo robots.txt antiguo una vez que haya habilitado las redirecciones.

En el nuevo sitio, asegúrese de que el archivo robots.txt permita todo el rastreo. Esto incluye el rastreo de imágenes, CSS, JavaScript y otros activos de la página, aparte de las URLs que está seguro de que no desea que se rastreen.

Configure el sitio web antiguo para redirigir a los usuarios y a Googlebot al nuevo sitio según el mapeo de URLs.

Envíe un cambio de dirección en Search Console para el sitio antiguo. Si está trasladando su sitio de HTTP a HTTPS, no necesita usar la herramienta de cambio de dirección.

Mantenga las redirecciones durante el mayor tiempo posible, generalmente al menos 1 año. Este período de tiempo permite a Google transferir todas las señales a las nuevas URLs, incluido el rastreo y la reasignación de enlaces en otros sitios que apuntan a sus URLs antiguas. Desde la perspectiva de los usuarios, considere mantener las redirecciones indefinidamente. Sin embargo, las redirecciones son lentas para los usuarios, así que intente actualizar sus propios enlaces y cualquier enlace de alto volumen de otros sitios web para que apunten a las nuevas URLs.

Envíe el nuevo sitemap en Search Console. Esto ayudará a Google a conocer las nuevas URLs. En este punto, puede eliminar su sitemap antiguo, ya que Google utilizará el nuevo sitemap en el futuro.

El tiempo que tardan Googlebot y nuestros sistemas en descubrir y procesar todas las URLs en el traslado del sitio depende de qué tan rápidos sean sus servidores y cuántas URLs estén involucradas. Como regla general, un sitio web de tamaño mediano puede tardar algunas semanas en mover la mayoría de las páginas, y los sitios más grandes tardan más. La velocidad a la que Googlebot y nuestros sistemas descubren y procesan las URLs movidas depende del número de URLs y de la velocidad del servidor. Tenga en cuenta que la visibilidad de su contenido en la búsqueda web puede fluctuar temporalmente durante el traslado. Esto es normal y las clasificaciones de un sitio se estabilizarán con el tiempo.

Actualizar enlaces entrantes

Inmediatamente después de que se inicie el traslado del sitio, intente actualizar tantos enlaces entrantes como sea posible para mejorar la experiencia del usuario y reducir la carga de su servidor. Estos incluyen:

Enlaces externos: Intente comunicarse con los sitios en la lista guardada de sitios que enlazan a su contenido actual, pidiéndoles que actualicen sus enlaces a su nuevo sitio. Considere priorizar sus esfuerzos por el número de visitas entrantes para cada enlace.

Monitorear el tráfico

Una vez que haya iniciado el traslado del sitio, monitoree cómo cambia el tráfico de usuarios y rastreadores en el nuevo sitio y también en el antiguo. Idealmente, el tráfico en el sitio antiguo disminuirá, mientras que en el nuevo sitio el tráfico aumentará. Puede monitorear la actividad de usuarios y rastreadores en los sitios con Search Console y otras herramientas.

Utilice Search Console para monitorear el tráfico

Sitemaps: Envíe los dos sitemaps que guardó anteriormente del mapeo. Inicialmente, el sitemap que contiene las nuevas URLs tendría cero páginas indexadas, mientras que el sitemap de las URLs antiguas tendría muchas páginas indexadas. Con el tiempo, el número de páginas indexadas del sitemap de URLs antiguas caería a cero con un aumento correspondiente de la indexación de las nuevas URLs.

Informe de cobertura de índice: Los gráficos reflejarían el traslado del sitio, mostrando una caída en los recuentos de URLs indexadas en el sitio antiguo y un aumento de la indexación en el nuevo sitio. Verifique regularmente si hay errores de rastreo inesperados.

Consultas de búsqueda: A medida que más páginas del nuevo sitio se indexan y comienzan a clasificarse, los informes de consultas de búsqueda comenzarían a mostrar las URLs en el nuevo sitio obteniendo impresiones y clics de búsqueda.

Utilice otras herramientas para monitorear el tráfico

Esté atento a los registros de acceso y error de su servidor. En particular, verifique el rastreo por parte de Googlebot, cualquier URL que devuelva inesperadamente códigos de estado de error HTTP y el tráfico normal de usuarios.

Si instaló algún software de análisis web en su sitio, o si su CMS proporciona análisis, también se recomienda que revise el tráfico de esta manera para que pueda ver el progreso del tráfico de su sitio antiguo al nuevo. En particular, Google Analytics ofrece informes en tiempo real, y esta es una característica útil para usar durante la fase inicial de traslado del sitio. Debe esperar ver que el tráfico disminuya en el sitio antiguo y aumente en el nuevo sitio.

Solución de problemas de su traslado de sitio

Aquí hay algunos errores comunes al migrar un sitio con cambios de URL (incluido HTTP a HTTPS). Estos errores pueden evitar que su nuevo sitio se indexe por completo.

Minimizar el impacto de las pruebas A/B en Google Search

Esta página cubre cómo garantizar que probar variaciones en el contenido de la página o las URLs de la página tenga un impacto mínimo en su rendimiento en Google Search. No da instrucciones sobre cómo construir o diseñar pruebas, pero puede encontrar más recursos sobre pruebas al final de esta página.

Descripción general de las pruebas

Las pruebas de sitios web son cuando prueba diferentes versiones de su sitio web (o una parte de su sitio web) y recopila datos sobre cómo reaccionan los usuarios a cada versión.

Las pruebas A/B son donde prueba dos (o más) variaciones de un cambio. Por ejemplo, puede probar diferentes fuentes en un botón para ver si puede aumentar los clics en el botón.

Las pruebas multivariantes son donde prueba más de un tipo de cambio a la vez, buscando el impacto de cada cambio, así como posibles sinergias entre los cambios. Por ejemplo, puede probar varias fuentes para un botón, pero también intentar cambiar (y no cambiar) la fuente del resto de la página al mismo tiempo. ¿Es una fuente nueva más fácil de leer y, por lo tanto, debería usarse en todas partes? ¿O es el beneficio que la fuente del botón se ve diferente al resto de la página, ayudando a llamar la atención?

Puede usar software para comparar el comportamiento con diferentes variaciones de sus páginas (partes de una página, páginas completas o flujos completos de varias páginas), y realizar un seguimiento de qué versión es más efectiva con sus usuarios.

Puede ejecutar pruebas creando múltiples versiones de una página, cada una con su propia URL. Cuando los usuarios intentan acceder a la URL original, redirige a algunos de ellos a cada una de las URLs de variación y luego compara el comportamiento de los usuarios para ver qué página es más efectiva.

También puede ejecutar pruebas sin cambiar la URL insertando variaciones dinámicamente en la página. Puede usar JavaScript para decidir qué variación mostrar.

Dependiendo de qué tipos de contenido esté probando, puede que ni siquiera importe mucho si Google rastrea o indexa algunas de sus variaciones de contenido mientras está probando. Los cambios pequeños, como el tamaño, el color o la ubicación de un botón o imagen, o el texto de su “llamada a la acción” (“Agregar al carrito” vs. “¡Comprar ahora!”), pueden tener un impacto sorprendente en las interacciones de los usuarios con su página, pero a menudo tienen poco o ningún impacto en el fragmento de resultados de búsqueda o la clasificación de esa página.

Además, si rastreamos su sitio con la frecuencia suficiente para detectar e indexar su experimento, probablemente indexaremos las actualizaciones eventuales que realice en su sitio bastante rápido después de que haya concluido el experimento.

Mejores prácticas al realizar pruebas

Aquí hay una lista de mejores prácticas para evitar efectos negativos en su comportamiento en Google Search mientras prueba variaciones del sitio:

No encubra sus páginas de prueba

No muestre un conjunto de URLs a Googlebot y un conjunto diferente a los humanos. Esto se llama Cloaking, y va en contra de nuestras políticas de spam, ya sea que esté ejecutando una prueba o no. Recuerde que infringir nuestras políticas de spam puede hacer que su sitio sea degradado o eliminado de los resultados de búsqueda de Google, probablemente no el resultado deseado de su prueba.

El Cloaking cuenta si lo hace mediante lógica de servidor o mediante robots.txt, o cualquier otro método. En su lugar, utilice enlaces o redirecciones como se describe a continuación.

Si utiliza cookies para controlar la prueba, tenga en cuenta que Googlebot generalmente no admite cookies. Esto significa que solo verá la versión de contenido que es accesible para los usuarios con navegadores que no aceptan cookies.

Utilice enlaces rel=”canonical”

Si está ejecutando una prueba con múltiples URLs, puede usar el atributo de enlace rel=”canonical” en todas sus URLs alternativas para indicar que la URL original es la versión preferida. Recomendamos usar rel=”canonical” en lugar de una metaetiqueta noindex porque se ajusta más a su intención en esta situación. Por ejemplo, si está probando variaciones de su página de inicio, no desea que los motores de búsqueda no indexen su página de inicio; solo desea que entiendan que todas las URLs de prueba son duplicados cercanos o variaciones de la URL original y deben agruparse, con la URL original como la canónica. Usar noindex en lugar de rel=”canonical” en tal situación a veces puede tener efectos negativos inesperados.

Utilice redirecciones 302, no redirecciones 301

Si está ejecutando una prueba que redirige a los usuarios de la URL original a una URL de variación, utilice una redirección 302 (temporal), no una redirección 301 (permanente). Esto indica a los motores de búsqueda que esta redirección es temporal (solo estará vigente mientras esté ejecutando el experimento) y que deben mantener la URL original en su índice en lugar de reemplazarla con el destino de la redirección (la página de prueba). Las redirecciones basadas en JavaScript también están bien.

Ejecute el experimento solo el tiempo necesario

La cantidad de tiempo necesaria para una prueba confiable variará según factores como sus tasas de conversión y cuánto tráfico recibe su sitio web; una buena herramienta de prueba le indica cuándo ha recopilado suficientes datos para sacar una conclusión confiable. Una vez que haya concluido la prueba, actualice su sitio con la(s) variación(es) de contenido deseada(s) y elimine todos los elementos de la prueba lo antes posible, como URLs alternativas o scripts y marcado de prueba. Si descubrimos un sitio que ejecuta un experimento durante un tiempo innecesariamente largo, podemos interpretar esto como un intento de engañar a los motores de búsqueda y tomar medidas en consecuencia. Esto es especialmente cierto si está sirviendo una variante de contenido a un gran porcentaje de sus usuarios.

Más información sobre las pruebas

Pausar o deshabilitar temporalmente un sitio web

Si no puede cumplir con los pedidos o muchos de sus productos están agotados, es posible que esté considerando cerrar temporalmente su negocio en línea. Si la situación es temporal, lo que significa que espera poder vender productos en las próximas semanas o meses, le recomendamos que tome medidas que preserven tanto como sea posible la posición de su sitio en la Búsqueda. Esta guía explica cómo puede pausar de forma segura su negocio en línea.

Limite la funcionalidad de su sitio (recomendado)

Si su situación es temporal y planea reabrir su negocio en línea, le recomendamos que mantenga su sitio en línea y limite la funcionalidad. Este es el enfoque recomendado, ya que minimiza cualquier efecto negativo en la presencia de su sitio en la Búsqueda. Las personas aún pueden encontrar sus productos, leer reseñas o agregar listas de deseos para que puedan comprar en un momento posterior. Recomendamos hacer lo siguiente:

Deshabilitar la funcionalidad del carrito: Deshabilitar la funcionalidad del carrito es el enfoque más simple y no cambia nada para la visibilidad de su sitio en la Búsqueda.

Mostrar un banner o ventana emergente: Un banner o ventana emergente div en todas las páginas, incluida la página de destino, aclara rápidamente el estado a los usuarios. Mencione cualquier retraso conocido e inusual, tiempos de envío, opciones de recogida o entrega, para que los usuarios continúen con las expectativas correctas. Para evitar que el contenido del banner o la ventana emergente se muestre en un fragmento en los resultados de búsqueda, utilice el atributo HTML data-nosnippet. Asegúrese de seguir nuestras pautas sobre ventanas emergentes y banners.

Actualice sus datos estructurados: Si su sitio utiliza datos estructurados (por ejemplo, Producto, Libro, Evento), asegúrese de ajustarlos adecuadamente (reflejando la disponibilidad actual del producto o cambiando los eventos a cancelados). Si su empresa tiene una tienda física, actualice los datos estructurados de Negocio Local para reflejar el horario de apertura actual.

Verifique su feed de Merchant Center: Si utiliza Merchant Center, siga las mejores prácticas para el atributo de disponibilidad.

Informe a Google sobre sus actualizaciones: Para pedirle a Google que vuelva a rastrear un número limitado de páginas (por ejemplo, la página de inicio), utilice Search Console. Para un mayor número de páginas (por ejemplo, todas sus páginas de productos), utilice sitemaps.

No recomendado: Deshabilitar todo el sitio web

Advertencia: Los sistemas de Google están diseñados para ser robustos y ayudar a los sitios web a recuperarse de problemas temporales. Sin embargo, eliminar un sitio por completo del índice de Google es un cambio significativo que puede llevar bastante tiempo recuperar. No hay un tiempo fijo para una recuperación de una eliminación completa, y no hay un mecanismo para acelerar eso. Es por eso que recomendamos encarecidamente limitar la funcionalidad en lugar de eliminar el sitio de la Búsqueda.

Puede decidir deshabilitar todo el sitio web. Esta es una medida extrema que solo debe tomarse por un período de tiempo muy corto (unos pocos días como máximo), ya que de lo contrario tendrá efectos significativos en el sitio web en la Búsqueda, incluso cuando se implemente correctamente.

Sus clientes no sabrán qué está pasando con su negocio si no pueden encontrar su negocio en línea en absoluto.

Sus clientes no pueden encontrar ni leer información de primera mano sobre su negocio y, por ejemplo, las reseñas, especificaciones, guías de reparación o manuales no serán localizables. La información de terceros puede no ser tan correcta o completa como lo que usted puede proporcionar. Esto a menudo también afecta las decisiones de compra futuras.

La verificación de Search Console fallará y perderá todo acceso a la información sobre su negocio en la Búsqueda. Los informes agregados en Search Console perderán datos a medida que las páginas se eliminen del índice.

Volver a aumentar después de un período de tiempo prolongado será significativamente más difícil si su sitio web necesita ser reindexado primero. Además, es incierto cuánto tiempo tomaría esto y si el sitio aparecería de manera similar en la Búsqueda después.

Si decide que necesita hacer esto (nuevamente, no recomendado), aquí hay algunas opciones:

Si necesita deshabilitar urgentemente el sitio por 1-2 días, devuelva una página de error informativa con un código de estado de respuesta HTTP 503 en lugar de todo el contenido. Asegúrese de seguir las mejores prácticas para deshabilitar un sitio.

Si necesita deshabilitar el sitio por más tiempo, proporcione una página de inicio indexable como marcador de posición para que los usuarios la encuentren en la Búsqueda utilizando el código de estado HTTP 200.

Si necesita ocultar rápidamente su sitio en la Búsqueda mientras considera las opciones, puede eliminar temporalmente un sitio web de la Búsqueda.

Mejores prácticas para deshabilitar un sitio

Advertencia: Tenga en cuenta que no es posible que los sistemas de Google actualicen títulos, descripciones, metadatos o datos estructurados incluidos en un sitio web si una página devuelve un código de estado de respuesta HTTP 503.

Aunque no recomendamos deshabilitar su sitio, aquí hay algunas mejores prácticas si decide hacer esto:

Continúe permitiendo el rastreo a través del archivo robots.txt. No devuelva un código de estado de respuesta HTTP 503 para el archivo robots.txt porque esto bloquea todo el rastreo.

Confirme un código de estado de respuesta HTTP 503 localmente usando curl o una herramienta similar. Por ejemplo:curl -I -X GET “https://www.example.com/” HTTP/1.1 503 Service Unavailable Mime-Version: 1.0 Content-Type: text/html (…)

Para minimizar la carga del lado del servidor y del lado del cliente de una página de error 503, siga estas mejores prácticas: Utilice el encabezado HTTP retry-after con una fecha o duración de mejor esfuerzo.

Brinde a sus usuarios una guía clara sobre los pasos futuros dentro del contenido de la página de error. Esto podría incluir: Enlaces a más información

La fecha en la que espera que el sitio web vuelva a estar en línea, o cuando se actualizará la información

No prohíba todo el rastreo en el archivo robots.txt. Devolver un archivo robots.txt válido que prohíba todo el rastreo puede eliminar el contenido del sitio web, y potencialmente sus URLs, de Google Search.

No bloquee el sitio web devolviendo códigos de estado HTTP 403, 404, 410, o con una metaetiqueta robots noindex o un encabezado HTTP x-robots-tag. Esto eliminará las URLs del sitio web de Google Search.

No utilice la herramienta de eliminación temporal de sitios web en Search Console para cierres. Hacerlo hará imposible que los usuarios encuentren su sitio web para que puedan conocer su estado. Además, los posibles revendedores o afiliados de los productos de su empresa pueden seguir apareciendo en la Búsqueda.

Preguntas frecuentes

¿Qué pasa si solo cierro el sitio por unas semanas? ¿Qué pasa si quiero excluir todos los productos no esenciales? ¿Puedo pedirle a Google que rastree menos mientras mi sitio está cerrado temporalmente? ¿Cómo consigo que una página se indexe o actualice rápidamente? ¿Qué pasa si bloqueo una región específica para que no acceda a mi sitio?

Servicio relacionado: Agencia de marketing con IA