Caso de estudio de renovación de sitio web: Douzu Carry Service, empresa de transporte de Miyazaki — qué conservamos del sitio antiguo y cómo

Lo que más se teme en una renovación de sitio web es que, a cambio de una apariencia renovada, el posicionamiento en buscadores y los canales de contacto se rompan en silencio. En este artículo tomamos como ejemplo el proyecto de renovación de «Douzu Carry Service», una empresa de transporte de Miyazaki, y repasamos qué decidimos fijar antes que el diseño.

Cuando se habla de renovar un sitio web, la conversación suele empezar por la propuesta de diseño o el aspecto de la página de inicio. Sin embargo, cuando el sitio antiguo ya tiene cierto volumen de tráfico de búsqueda y enlaces entrantes, hay decisiones que conviene fijar antes que el diseño, porque después es difícil dar marcha atrás. Se trata del diseño de las URL y de cómo se traspasa la información del sitio antiguo.

Este artículo toma como ejemplo la renovación del sitio web de «Douzu Carry Service», una empresa de transporte de Miyazaki dedicada a mudanzas individuales, transporte de larga distancia y reparto en frío/congelado, y resume los pasos concretos que seguimos. Hay un resumen breve en Caso de estudio: cómo organizamos la estructura de Douzu Carry Service, pero en este artículo profundizamos algo más en el contenido.

Cabe aclarar que este artículo no incluye cifras de medición de resultados, como cambios en el número de visitas o de consultas. Lo que hemos podido organizar aquí son únicamente los hechos de «qué hicimos y con qué procedimiento», ya que las cifras de resultados no forman parte de las fuentes de este artículo.

Lo que puede llevarse de este artículo es una plantilla de procedimiento que se puede aplicar directamente a la renovación de su propio sitio. En concreto, son cuatro elementos: la estructura de columnas de la tabla de inventario de URL y la tabla de correspondencia (capítulo 2), el método de implementación de las redirecciones 301 y sus ejemplos de configuración (capítulo 3), cómo elaborar la lista de verificación de retención de contenido (capítulo 4), y los comandos de verificación y los puntos a comprobar antes y después del lanzamiento (capítulo 8). La lectura está pensada desde la perspectiva de «si quisiera hacer lo mismo en mi propio sitio, qué tendría que crear y qué tendría que comprobar».

1. Resumen del proyecto — Antes / Después

Empecemos por el panorama general.

Las páginas estáticas principales (inicio, lista de servicios, mudanzas, reparto en frío/congelado, entrega el mismo día, mudanzas para ingreso a residencias, precios, información de la empresa, preguntas frecuentes y contacto) y las nueve páginas de área —Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima y Ebino— mantienen la misma URL después de la renovación. Lo que cambió principalmente fue el tratamiento de las URL sin sentido del blog antiguo y del script residual que no se utilizaba.

Cabe mencionar que el diseño del sitio nuevo se construyó sobre la base del sistema de diseño publicado por la Agencia Digital de Japón. Al omitir el proceso de crear el diseño desde cero, pudimos dedicar ese tiempo al diseño de URL y a la migración de contenido que trata este artículo. La lógica de este enfoque está resumida en Por qué KomuraSoft crea sitios web con el sistema de diseño de la Agencia Digital.

Si tuviéramos que resumir el punto clave de este caso en una frase, sería: «antes de cambiar la apariencia, terminamos el inventario de URL y contenido, y solo entonces empezamos». En los siguientes capítulos explicamos ese procedimiento paso a paso.

2. Lo primero no fue el diseño, sino el inventario de URL

Lo primero que elaboramos al iniciar la renovación no fue un boceto de diseño, sino una tabla de inventario que enumeraba todas las URL del sitio antiguo.

En concreto, hicimos un relevamiento exhaustivo por las siguientes categorías.

• Páginas estáticas (inicio, lista de servicios, mudanzas, reparto en frío/congelado, entrega el mismo día, mudanzas para ingreso a residencias, información de la empresa, política de privacidad, preguntas frecuentes, precios, blog, contacto)
• Las nueve páginas de área (Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima, Ebino)
• Las entradas individuales del blog antiguo (más de 100, desde columnas de proximidad regional hasta artículos con consejos sobre mudanzas individuales y de larga distancia)
• «Archivos que no son páginas pero siguen siendo públicamente accesibles», como robots.txt, sitemap.xml, el archivo de verificación de propiedad de Search Console y el script de envío de formularios antiguo (php/submit.php)

La estructura de columnas de la tabla de inventario basta con la siguiente forma. Si va a replicarla, empiece por estas columnas.

Solo una vez terminada esta tabla de inventario se puede construir la tabla de correspondencia (mapeo de URL), que decide URL por URL «qué hacer con esta URL en el sitio nuevo». Con tres columnas basta para la tabla de correspondencia: URL antigua, decisión y destino. Si el motivo de la decisión se deja en las notas de la tabla de inventario, la tabla de correspondencia se puede convertir de forma mecánica en la implementación (la definición de las redirecciones).

En la tabla de correspondencia de este proyecto, dividimos la decisión en dos grandes categorías.

Las páginas estáticas, las páginas de área y las URL de entradas de blog vigentes con sentido son todas keep, es decir, no se les aplica ningún cambio. Por otro lado, diseñamos las URL con cadenas aleatorias sin sentido numeradas automáticamente por el sistema (como /blog/5lmln1lx0x/) y las URL con nombre de archivo por fecha como post20210721.html para que redirigieran con 301 a la nueva URL del artículo, que sí tiene un slug significativo.

Otro elemento sujeto a esta decisión fue el script de destino php/submit.php que quedaba en el sitio antiguo. Ningún formulario del conjunto de HTML publicado lo referenciaba, y pudimos confirmar que los únicos canales de contacto realmente funcionales eran tres: teléfono, correo electrónico y presupuesto por LINE. Con esa base, lo clasificamos como «script de destino residual» y decidimos redirigirlo con 301 a /contact/ (los detalles de esta decisión se explican en el capítulo 6).

En el diseño de las redirecciones, aplicamos sin excepción las siguientes dos reglas.

• Que cada redirección se resuelva en un solo salto (no crear cadenas de redirecciones)
• Incorporar un mecanismo que, durante la compilación, verifique que la URL de destino existe realmente (para evitar el accidente de un 301 hacia una URL inexistente)

Fijar este inventario y esta tabla de correspondencia antes de estudiar el diseño permite que la implementación posterior y la creación de contenido avancen sobre la base de «qué se coloca en cada URL», lo que reduce el retrabajo. Esta idea no es exclusiva de este proyecto: es un procedimiento básico que se aplica igual a cualquier renovación de un sitio antiguo que ya tenga enlaces entrantes o tráfico de búsqueda.

3. Cómo implementamos las redirecciones 301

Aunque exista la tabla de correspondencia, no sirve de nada si no se traduce en respuestas 301 reales. Esta es la parte que más se suele omitir en los artículos, pero la que más complica las cosas a la hora de replicarla, así que la describimos en detalle.

El sitio nuevo tiene una arquitectura de generación de sitio estático + Cloudflare Pages. En esta arquitectura, el lugar donde se emiten las redirecciones se divide en dos.

Si no se entiende esta división de responsabilidades desde el principio, se acaba perdiendo tiempo con algo como «escribí una línea para www en _redirects y no funciona». _redirects actúa sobre las rutas dentro del sitio y no puede enrutar según el nombre de host con el que llega la solicitud.

3.1 Rutas dentro del mismo host — el archivo _redirects

Cloudflare Pages ofrece un mecanismo que, si se coloca en la raíz del resultado de la compilación un archivo de texto llamado _redirects, devuelve redirecciones según su contenido. El formato consiste simplemente en escribir en cada línea, separados por espacios, «la ruta de origen», «el destino» y «el código de estado».

/blog/5lmln1lx0x/          /blog/oneroom-mansion-hikkoshi/   301
/blog/post20210721.html    /blog/oneroom-mansion-hikkoshi/   301
/php/submit.php            /contact/                         301

Aquí, asegúrese siempre de indicar explícitamente 301 al final. Si se omite el código de estado, se trata como un 302 (traslado temporal) y deja de ser el traslado permanente pensado para transferir la evaluación de búsqueda. El límite de las redirecciones estáticas es de 2000, y si la cantidad lo supera, hay que trasladarlas a Bulk Redirects.

En este proyecto no escribimos _redirects a mano, sino que configuramos que el script de compilación lo genere a partir de la tabla de correspondencia. El script de compilación guarda las definiciones de redirección como un arreglo y las escribe línea por línea al generar la salida. A modo de ejemplo, la idea es algo así.

// Mantiene la tabla de correspondencia (URL antigua → URL nueva) en un solo lugar
const redirects = [
  ["/blog/5lmln1lx0x/", "/blog/oneroom-mansion-hikkoshi/"],
  ["/blog/post20210721.html", "/blog/oneroom-mansion-hikkoshi/"],
  ["/php/submit.php", "/contact/"],
];

// Escribe en dist/_redirects con el formato "ruta de origen destino 301"
const body = redirects.map(([from, to]) => `${from} ${to} 301`).join("\n");
await fs.writeFile("dist/_redirects", `${body}\n`);

Hacerlo así tiene dos ventajas. La primera es que las reglas fijadas en el capítulo 2 —«resolverlo en un solo salto» y «verificar que la URL de destino existe»— se pueden garantizar como pruebas automáticas en tiempo de compilación. En este proyecto preparamos una prueba que verifica que el contenido del _redirects generado tiene el número y el contenido esperados, y confirmamos que todas las redirecciones son 301 de un solo salto. La segunda es que, cuando se cambia la URL de un artículo, basta con corregir la tabla de correspondencia para que _redirects la siga automáticamente, evitando el accidente de corregir solo un lado y romper el otro.

3.2 Cuando cambia el nombre de host — Redirect Rules de Cloudflare

Las redirecciones en las que cambia el nombre de host, como el 301 de www.douzucarry.com al apex (douzucarry.com), se configuran desde el panel de Cloudflare. Los pasos son los siguientes.

1. En la zona correspondiente, confirmar que existe el registro DNS de www y que el proxy está activado (Proxied). Sin un registro DNS, la solicitud ni siquiera llega a Cloudflare.
2. Abrir Rules > Redirect Rules > Create rule.
3. Especificar en la condición (When) «Hostname equals www.douzucarry.com».
4. En la acción (Then), elegir Dynamic redirect y usar como expresión de destino concat("https://douzucarry.com", http.request.uri.path). El estado debe ser 301 y Preserve query string debe estar en ON.

Usamos una expresión que conserva la ruta tal cual porque cada página del lado www se envía uno a uno a la misma ruta en el apex. En cambio, en un caso como el del dominio de landing page antiguo que se trata en el capítulo 7, donde el contenido está consolidado en una sola página del sitio nuevo, no hay que conservar la ruta; es justo lo contrario. Si se añade al destino la parte capturada con un comodín, se acaba redirigiendo con 301 a una URL inexistente como /refrigerated/foo, lo que aumenta los errores 404 y rompe la consolidación de la evaluación. En este caso, el destino debe fijarse en una única URL fija.

3.3 Por qué evitamos otras alternativas

Si el sitio antiguo funcionaba con PHP o Apache, también existe la opción de escribir RewriteRule ... [R=301,L] en .htaccess. Es una alternativa realista si se parte de la base de mantener el entorno antiguo durante un tiempo. Por otro lado, el traslado mediante <meta http-equiv="refresh"> en HTML mantiene el código de estado HTTP en 200, así que no debe elegirse cuando lo que se busca es que se trate como un 301. Lo mismo ocurre con la reescritura de location.href en JavaScript. Para comunicarle al motor de búsqueda que «nos hemos mudado», el servidor tiene que devolver un 301.

4. Una lista de verificación para no «perder» contenido

En paralelo al diseño de las URL, elaboramos una lista de verificación de retención de contenido para confirmar que la información que aparecía en el sitio antiguo también se mostrara sin faltantes en el sitio nuevo.

En una renovación, durante el proceso de renovar el diseño, pueden desaparecer sin que nadie lo note textos de venta o cifras concretas. En particular, si se pierde información que influye directamente en la decisión de contactar —como precios, horarios de atención, datos de contacto o puntos fuertes—, puede darse el accidente de que, aun con una apariencia mejorada, bajen las consultas.

Por eso, anotamos la información imprescindible del sitio antiguo para cada página principal. Como muestra, el contenido es el siguiente.

Una vez elaborada esta lista de verificación, antes del lanzamiento del sitio nuevo cotejamos las páginas antiguas y nuevas una por una para confirmar que no faltara ningún elemento. El punto clave es que garantizamos con una lista, y no confiando en la intuición o la memoria, que los «elementos de decisión» —precios, horarios de atención, puntos fuertes— se traspasaran tal cual aunque cambiara el diseño.

5. SEO local — el diseño de las nueve páginas de área

Entre las páginas heredadas del sitio antiguo hay páginas individuales para cada una de las nueve áreas: Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima y Ebino.

Estas páginas de área están pensadas para captar consultas de búsqueda que incluyen el nombre de una localidad, como «nombre de lugar + mudanza» o «nombre de lugar + reparto». En servicios como el transporte o las mudanzas, donde el área comercial está ligada a la región, cumplen la función de atender necesidades de búsqueda con nombre de lugar que ni la página de inicio ni la página de precios por sí solas pueden captar.

Si se observa la tabla de correspondencia de URL, las nueve páginas desde /area/miyazaki/ hasta /area/ebino/ están todas marcadas como keep (sin cambio de URL), y la renovación no modificó esta estructura en sí. Además, ligadas a cada área, hay numerosas entradas de blog que tratan nombres de lugar concretos de la región (por ejemplo, distintos barrios dentro de la ciudad de Miyazaki o de la ciudad de Miyakonojo), de modo que las páginas de área y las entradas de blog se complementan entre sí.

Las páginas de área, del tipo que «reproduce el mismo formato cambiando solo el nombre de lugar», corren el riesgo de que, si el contenido es escaso, tanto el motor de búsqueda como el lector las perciban como «la misma página reutilizada». En este caso, además de la propia página de área, heredamos del sitio antiguo la división de funciones en la que los detalles a nivel de barrio dentro de cada área se redactaban individualmente en las entradas de blog, con lo que ya existía una estructura que evitaba la «escasez» propia de las páginas producidas en serie. La renovación no rompió esta estructura y mantuvo las URL tal cual.

6. Consolidación de los canales de contacto dispersos

El tratamiento de php/submit.php que mencionamos en el capítulo 2 fue también una decisión importante a la hora de ordenar los canales de contacto.

Al examinar el sitio antiguo, pudimos confirmar que, de los canales de contacto publicados, los únicos que realmente funcionaban eran estos tres.

• Teléfono (0120-931-677, horario de atención de 8:00 a 20:00)
• Correo electrónico
• Presupuesto por LINE

Por otro lado, el propio script de destino php/submit.php seguía presente en el código, pero ningún formulario del HTML publicado lo referenciaba. Es decir, era en la práctica un «script residual» que no se usaba. Con esto en cuenta, en el sitio nuevo consolidamos los tres canales —teléfono, correo electrónico y presupuesto por LINE— en la página /contact/, y diseñamos que el acceso a php/submit.php se redirigiera con 301 a /contact/.

Cuando los canales de contacto están dispersos en varias páginas y scripts, en el momento de la renovación suele perderse de vista cuáles se usan realmente. El enfoque de este caso —relevar primero «cuáles son los canales que realmente funcionan» y consolidar después— también se aplica como principio general al revisar los canales de la página de inicio, las páginas de servicio y la página de contacto. Tratamos esta idea también en un artículo anterior, Los tres primeros lugares que corregir en un sitio que no recibe consultas, que puede consultar como referencia adicional.

7. Orden en los dominios antiguos — qué hacer con un dominio de landing page abandonado

En empresas de transporte que han ido creando landing pages independientes para cada servicio, es fácil que los dominios acaben dispersos en varios sin que nadie lo note. También en este caso fue necesario ordenar los siguientes dominios.

Solo el tercer caso queda sin resolver. Esta diferencia se confirmó como resultado de la verificación previa al lanzamiento que se trata en el próximo capítulo 8: no nos basamos en «creer que lo habíamos configurado», sino en comprobar que el 301 realmente se devolvía.

El tercer caso, en particular, es importante como lección. El contenido de la antigua landing page de reparto en frío/congelado (vehículos con equipo de refrigeración apto para −20 °C, atención las 24 horas los 365 días del año, servicio regular y reparto por ruta) ya se migró a /refrigerated/ en el sitio nuevo, pero como el propio dominio antiguo dejó de resolverse por la sospecha de que su DNS había caducado, no se puede configurar una redirección 301 desde ese dominio antiguo. Esto significa que, si se deja un dominio sin mantenimiento ni renovación, se puede perder de golpe, un día cualquiera, la autoridad de enlaces entrantes y el tráfico de búsqueda de marca que se habían acumulado en él.

Si una empresa que opera landing pages de servicio en un dominio separado está considerando una renovación, recomendamos que, además de decidir a dónde se integrará el contenido, verifique al mismo tiempo la situación contractual del dominio antiguo (si sigue renovándose, si su DNS sigue activo). El poder configurar el 301 mientras la recuperación todavía es posible marca una gran diferencia en la facilidad con la que se traspasa la evaluación acumulada.

8. Verificación antes del lanzamiento y tareas posteriores

Antes de publicar el sitio nuevo, realizamos las siguientes comprobaciones.

• Cotejo con la lista de verificación de retención de contenido elaborada en el capítulo 4 (si las páginas antiguas y nuevas tienen los mismos elementos)
• Comprobación con medición real de las redirecciones 301 (enviar solicitudes reales y verificar que devuelven el código de estado y el destino previstos)
• Que el archivo de verificación de propiedad de Search Console devuelva correctamente un 200
• Que archivos necesarios para la publicación como robots.txt, sitemap.xml y _headers estén realmente publicados (_headers es un archivo propio de Cloudflare Pages que, igual que _redirects, si se coloca en la raíz del resultado de la compilación permite añadir encabezados de respuesta por ruta; ahí se especifican en conjunto los encabezados relacionados con la seguridad y el control de caché)

Realice la comprobación con medición real de los 301 mediante un comando, no con el navegador. El navegador sigue las redirecciones automáticamente, así que aunque haya un 302 intercalado en el camino, terminará mostrando la página final y no se dará cuenta. Con curl -I (obtiene solo los encabezados, no sigue redirecciones) puede comprobar directamente el código de estado devuelto y el encabezado Location.

# Comprobar si la URL con ID del blog antiguo devuelve 301 hacia la URL con el slug nuevo
curl -I https://douzucarry.com/blog/5lmln1lx0x/

# Comprobar de la misma forma la URL .html con nombre de archivo por fecha
curl -I https://douzucarry.com/blog/post20210721.html

# Comprobar si la solicitud que llega por www devuelve 301 hacia el apex (y observar también si se conserva la ruta)
curl -I https://www.douzucarry.com/price/

Lo que hay que observar son dos puntos: que la línea de estado, la primera línea, sea 301, y que el valor de Location: coincida con el «destino» de la tabla de correspondencia. Si aquí se devuelve 302, se puede diagnosticar que se olvidó escribir el código de estado en _redirects; si el destino de Location se redirige a su vez a otra URL, se puede diagnosticar que se ha formado una cadena. Todas las líneas redirect de la tabla de correspondencia se verifican una por una con este método.

También hay tareas pendientes después de la publicación.

• Reenviar sitemap.xml a Search Console
• Verificar individualmente con la herramienta de inspección de URL si las URL con ID del blog antiguo y las URL .html con nombre de archivo por fecha devuelven 301 como se esperaba
• Comprobar durante varias semanas, en el informe de cobertura, si las URL antiguas que antes eran 404 o quedaban fuera del índice pasan a reconocerse como «redirección»

Conviene planificar el trabajo de renovación partiendo de la base de que no termina con la publicación, sino que solo se completa cuando se ha monitoreado, después del lanzamiento, hasta confirmar que el motor de búsqueda reconoce correctamente las redirecciones.

9. Resumen — reglas generales para no fracasar en una renovación

Si organizamos, a partir de este caso de Douzu Carry Service, las ideas que también se aplican en común a otros proyectos de renovación, quedan de la siguiente manera.

• Primero el diseño de las URL, después el diseño visual. En un sitio antiguo con tráfico de búsqueda o enlaces entrantes existentes, antes de estudiar la apariencia, se debe fijar el inventario de todas las URL y la tabla de correspondencia (mapeo 301) hacia las URL nuevas.
• No publicar sin haber hecho el inventario del contenido antiguo. Los «elementos de decisión» —precios, horarios de atención, datos de contacto, puntos fuertes— se confirman con una lista que coteja las páginas antiguas y nuevas una por una, antes de publicar.
• Conservar solo los canales que realmente se usan. Si se encuentra un formulario o un script de destino sin usar, hay que verificar la situación real y consolidarlo en el canal que sigue vivo.
• Que la redirección sea de un solo salto, junto con la verificación de que el destino existe. No crear cadenas y contar con un mecanismo que evite enviar a URL inexistentes.
• El lugar donde se emite el 301 se divide en dos. Las rutas dentro del mismo host se configuran en el archivo de configuración del resultado de la compilación (en Cloudflare Pages, _redirects); las que cambian de nombre de host, en las reglas del lado del CDN o del DNS. En ambos casos hay que indicar explícitamente el código de estado y medir cada una con curl -I antes de la publicación.
• Ordenar los dominios mientras siguen activos. Si se deja abandonado un dominio separado para una landing page de servicio, la caducidad del DNS lo vuelve irrecuperable y se pierde la propia oportunidad de traspasar la evaluación acumulada.

Renovar un sitio web no es simplemente el trabajo de renovar el diseño: es también un trabajo de diseño sobre cómo traspasar la evaluación de búsqueda y los canales de contacto acumulados hasta ese momento. El resumen breve de este caso está recogido en Caso de estudio: cómo organizamos la estructura de Douzu Carry Service, que también puede consultar.

Si de la misma manera tiene inquietudes sobre el diseño de URL o el traspaso de contenido existente, en una consulta de Desarrollo de sitios web podemos avanzar juntos desde el inventario del sitio antiguo.

Artículos relacionados

• Caso de estudio: cómo organizamos la estructura de Douzu Carry Service
• Por qué KomuraSoft crea sitios web con el sistema de diseño de la Agencia Digital — se puede compaginar el bajo costo con la calidad
• Los tres primeros lugares que corregir en un sitio que no recibe consultas
• Desarrollo de sitios web
• Contacto

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Con qué debería empezar una renovación de sitio web?

No con una propuesta de diseño, sino con una tabla de inventario que enumere todas las URL del sitio antiguo. Esto significa catalogar de forma exhaustiva las páginas estáticas, las páginas de área y las entradas del blog, además de los «archivos que no son páginas pero siguen siendo públicamente accesibles», como robots.txt, el archivo de verificación de propiedad de Search Console y los scripts de envío de formularios. A partir de ahí se construye una tabla de correspondencia que decide, URL por URL, si debe mantenerse igual o redirigirse (301). Fijar primero esta base reduce el retrabajo posterior en la implementación y la creación de contenido.

¿Cuáles son los puntos clave del diseño de redirecciones para evitar una caída en el posicionamiento en buscadores durante una renovación?

Mantén sin cambios las URL significativas —páginas estáticas, páginas de área, etc.— y redirige con 301 únicamente las URL sin sentido, numeradas automáticamente por el sistema, hacia nuevas URL con un slug significativo. Como reglas de diseño, aplicamos sin excepción dos cosas: cada redirección se resuelve en un solo salto, sin crear cadenas, y el proceso de compilación incluye una verificación que confirma que la URL de destino existe realmente, para evitar el accidente de un 301 hacia una URL inexistente. Después del lanzamiento, monitoreamos Search Console durante varias semanas hasta que reconoce las redirecciones.

¿Por qué a veces una renovación termina provocando que bajen las consultas?

Porque, en el proceso de renovar el diseño, la información que influye directamente en la decisión de contactar —precios, horarios de atención, datos de contacto, puntos fuertes clave— puede desaparecer silenciosamente sin que nadie lo note. Como contramedida, elaboramos una lista de verificación de retención de contenido que anota, para cada página principal, la información imprescindible del sitio antiguo (planes de precios, horarios de atención, servicios ofrecidos, etc.), y luego cotejamos las páginas antiguas y nuevas una por una antes del lanzamiento. La clave está en garantizarlo con una lista, no con la memoria o la intuición.

¿Es aceptable dejar abandonada una landing page sin usar en un dominio separado?

Dejarla abandonada es arriesgado. En este caso, el dominio de la antigua landing page de reparto en frío/congelado había dejado de resolverse, probablemente porque su DNS había caducado, y aunque el contenido ya se había migrado al nuevo sitio, no quedaba forma de configurar una redirección 301 desde el dominio antiguo. Si dejas un dominio sin mantenimiento ni renovación, puedes perder de golpe, un día cualquiera, la autoridad de enlaces entrantes y el tráfico de búsqueda de marca acumulados en él. Al plantear una renovación, conviene comprobar tanto el estado contractual del dominio antiguo como si su DNS sigue activo, y configurar la redirección 301 mientras la recuperación todavía es posible.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.