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 más temible de una renovación de sitio web es que, mientras el aspecto se renueva, el posicionamiento en buscadores y el flujo de contacto se rompan silenciosamente. Esta vez tomamos como ejemplo el proyecto de renovación de «Douzu Carry Service», una empresa de transporte de Miyazaki, para repasar qué dejamos definido antes de tocar el diseño.

Cuando se habla de una renovación de sitio web, la conversación suele empezar por las propuestas de diseño o el aspecto de la página de inicio. Pero cuando el sitio antiguo ya tiene un tráfico de búsqueda o enlaces entrantes significativos, hay cosas que deben decidirse antes que el diseño, porque luego resulta difícil dar marcha atrás. Son el diseño de las URL y la manera de conservar la información del sitio antiguo.

Este artículo toma como ejemplo la renovación de «Douzu Carry Service», una empresa de transporte de Miyazaki dedicada a las mudanzas individuales, el reparto de larga distancia y el transporte refrigerado/congelado, y resume los pasos concretos que seguimos. Hay un resumen breve en el caso que recoge la estructura de Douzu Carry Service, pero este artículo profundiza algo más en los detalles.

Cabe señalar que este artículo no incluye cifras de impacto, como variaciones en el número de visitas o consultas. Lo que podemos exponer aquí se limita a los hechos —qué se hizo y en qué pasos—, ya que las cifras de resultados no forman parte de las fuentes de este artículo.

1. Resumen del proyecto — Antes / Después

Primero, el panorama general.

Las principales páginas estáticas —inicio, listado de servicios, mudanzas, transporte refrigerado/congelado, entrega el mismo día, mudanzas a residencias para mayores, precios, información de la empresa, FAQ y contacto—, junto con las nueve páginas de área para Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima y Ebino, mantuvieron todas su URL sin cambios durante la renovación. Lo que cambió principalmente fue el tratamiento de las URL sin sentido del blog antiguo y de un script residual sin uso.

Además, el diseño del nuevo sitio se construyó sobre el sistema de diseño publicado por la Agencia Digital de Japón (Digital Agency). Saltarse el paso de crear un diseño desde cero nos permitió destinar ese esfuerzo ahorrado al trabajo de diseño de URL y migración de contenido que se trata en este artículo. La lógica de este enfoque se detalla en «Por qué KomuraSoft construye sitios web sobre el sistema de diseño de la Digital Agency — el bajo coste y la alta calidad pueden coexistir».

Si hubiera que resumir este caso en un solo punto, sería este: terminamos el inventario de URL y contenido antes de tocar el diseño visual, y solo entonces empezamos. Los capítulos siguientes recorren ese proceso paso a paso.

2. El primer paso no fue el diseño, sino un inventario de URL

Lo primero que produjimos 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, catalogamos de forma exhaustiva lo siguiente.

• Páginas estáticas (inicio, listado de servicios, mudanzas, transporte refrigerado/congelado, entrega el mismo día, mudanzas a residencias para mayores, información de la empresa, política de privacidad, FAQ, precios, blog, contacto)
• Las nueve páginas de área (Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima, Ebino)
• Entradas individuales del blog antiguo (más de 100, desde columnas centradas en el área hasta artículos de conocimiento práctico 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 antiguo script de envío de formulario (php/submit.php)

Solo una vez elaborado este inventario pudimos construir una tabla de correspondencia que decidiera, URL por URL, qué debía ocurrir con ella en el sitio nuevo. 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 actualmente significativas se marcaron todas como keep (sin cambios). Por otro lado, las URL con cadenas aleatorias sin sentido numeradas automáticamente por el sistema (del tipo /blog/5lmln1lx0x/) y los nombres de archivo con fecha como post20210721.html se diseñaron para redirigir con 301 a nuevas URL de artículo con un slug significativo.

Otro elemento que entró en este proceso de decisión fue php/submit.php, un script de destino de envío que había quedado en el sitio antiguo. Confirmamos que ningún formulario del HTML publicado lo referenciaba, y que los canales de contacto realmente funcionales eran solo los tres sistemas de teléfono, correo electrónico y presupuesto por LINE, así que lo clasificamos como «script residual abandonado» y lo configuramos para redirigir con 301 a /contact/ (tratamos el contexto de esta decisión con más detalle en el próximo capítulo y en el capítulo 5).

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

• Resolver cada redirección en un solo salto (nunca crear una cadena de redirecciones)
• Incorporar en la compilación una verificación que confirme 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 incluso de considerar el diseño significa que las fases posteriores de implementación y creación de contenido pueden avanzar sobre la base sólida de «qué va en cada URL», lo que reduce el retrabajo. Esto no es exclusivo de este proyecto: es un procedimiento básico que se aplica igual de directamente a cualquier renovación de un sitio antiguo que ya tenga enlaces entrantes o tráfico de búsqueda.

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

En paralelo al trabajo de diseño de URL, elaboramos una lista de verificación de retención de contenido para confirmar que toda la información escrita en el sitio antiguo pudiera reproducirse sin excepción en el nuevo.

En una renovación, pequeños textos comerciales y cifras pueden desaparecer silenciosamente en el proceso de renovar el diseño. Si lo que desaparece es información que influye directamente en la decisión de contactar —precios, horarios de atención, datos de contacto, puntos fuertes—, eso puede llevar precisamente al resultado de que el sitio luzca mejor pero las consultas bajen.

Así que anotamos, para cada página principal, la información imprescindible del sitio antiguo. Esto es parte de lo que incluía.

Con esta lista de verificación en mano, cotejamos las páginas antiguas y nuevas una por una antes de lanzar el sitio nuevo, confirmando que no se hubiera perdido ningún elemento. El punto clave es que garantizamos, mediante una lista y no por intuición o memoria, que el «material de decisión» —precios, horarios, puntos fuertes— se conservara intacto pese al cambio de diseño.

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

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

Estas páginas de área existen como punto de aterrizaje para las búsquedas que incluyen un topónimo, del tipo «[nombre del lugar] + mudanza» o «[nombre del lugar] + reparto». Para un servicio como el transporte o las mudanzas, donde el área de influencia está ligada a regiones concretas, cumplen la función de captar la demanda de búsqueda con topónimo que la página de inicio o la de precios por sí solas no pueden captar del todo.

Si se observa la tabla de correspondencia de URL, las nueve páginas de /area/miyazaki/ a /area/ebino/ se clasificaron todas como keep (sin cambio de URL), y la renovación no tocó esta estructura en sí. Junto a ellas, también hay numerosas entradas de blog vinculadas a cada área que tratan topónimos locales concretos —los distritos dentro de la ciudad de Miyazaki o de Miyakonojo, por ejemplo—, formando una estructura en la que las páginas de área y las entradas de blog se complementan entre sí.

Páginas como estas páginas de área —el tipo que se produce en masa variando solo el topónimo dentro de un formato por lo demás idéntico— corren el riesgo, si el contenido es escaso, de parecer copias reutilizadas de la misma página tanto a los buscadores como a los lectores. En este caso, el reparto de funciones se heredó del sitio antiguo: las propias páginas de área cubren el nivel de área, mientras que las entradas de blog cubren individualmente el detalle a nivel de distrito dentro de cada área. Esa estructura ya evitaba la «delgadez» típica de las páginas producidas en masa. La renovación dejó esta estructura intacta y mantuvo las URL sin cambios.

5. Consolidación de canales de contacto dispersos

El tratamiento de php/submit.php, mencionado en el capítulo 3, fue también una decisión importante desde el punto de vista de organizar el flujo de contacto.

Al examinar el sitio antiguo, confirmamos que solo los siguientes tres sistemas funcionaban realmente como canales de contacto disponibles públicamente.

• 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 de envío php/submit.php seguía en el código, pero ningún formulario del HTML publicado lo referenciaba. Es decir, era un «script residual» que en realidad ya no se usaba. Con base en esto, el sitio nuevo consolida los tres canales —teléfono, correo electrónico y presupuesto por LINE— en la página /contact/, y cualquier acceso a php/submit.php está diseñado para redirigir con 301 a /contact/.

Cuando los canales de contacto están dispersos en varias páginas y scripts, es fácil perder de vista, justo en el momento de la renovación, cuáles se usan realmente. Este enfoque —identificar primero qué canales funcionan realmente y luego consolidarlos, como hicimos aquí— también se sostiene como principio general para revisar el flujo entre una página de inicio, páginas de servicio y una página de contacto. También tratamos esta idea en un artículo anterior, «Los tres lugares que hay que corregir primero en un sitio que no recibe consultas», que también merece la pena consultar.

6. Limpieza de dominios antiguos — tratamiento de un dominio de landing page abandonado

Empresas como las de transporte, que han creado landing pages separadas para cada servicio, a veces terminan, casi sin darse cuenta, con sus dominios dispersos en varios sitios. También en este caso hubo que ordenar los siguientes dominios.

El tercer caso en particular es una lección importante. El contenido de la antigua landing page de transporte refrigerado/congelado —sus argumentos sobre vehículos equipados con unidades de refrigeración a −20 °C, disponibilidad 24/7/365 y entregas programadas y por ruta— ya se migró a /refrigerated/ en el sitio nuevo. Pero como el propio dominio antiguo ya no se puede resolver, probablemente por un registro DNS caducado, no hay forma de configurar allí una redirección 301. La lección es que, si se deja un dominio sin mantenimiento ni renovación, se corre el riesgo de perder de golpe, un día cualquiera, la autoridad de enlaces entrantes y el tráfico de búsqueda de marca acumulados en él.

Si su empresa opera landing pages de servicio en dominios separados y está considerando una renovación, recomendamos no limitarse a decidir dónde consolidar el contenido, sino comprobar al mismo tiempo el estado contractual del dominio antiguo —si la renovación sigue activa y si su DNS sigue vivo—. Poder configurar todavía la redirección 301 mientras la recuperación es posible marca una diferencia real en lo fácil que resultará después trasladar la autoridad acumulada.

7. Verificación previa al lanzamiento y tareas posteriores

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

• Cotejo con la lista de verificación de retención de contenido elaborada en los capítulos 2 y 3 (si las páginas antiguas y nuevas tienen elementos correspondientes)
• Verificación en vivo de las redirecciones 301 (enviar solicitudes reales y confirmar que devuelven los códigos de estado y destinos esperados)
• Confirmación de que el archivo de verificación de propiedad de Search Console devuelve correctamente un 200
• Confirmación de que los archivos necesarios para el lanzamiento, como robots.txt, sitemap.xml y _headers, están realmente publicados

También hay tareas que atender después del lanzamiento.

• Reenviar sitemap.xml a Search Console
• Usar la herramienta de inspección de URL para confirmar individualmente que las URL con ID del blog antiguo y los nombres de archivo .html con fecha redirigen con 301 como se esperaba
• A lo largo de varias semanas, comprobar en el informe de cobertura si las URL antiguas, que antes daban 404 o estaban excluidas del índice, llegan a reconocerse como «Redirección»

Un proyecto de renovación no termina con el lanzamiento: conviene planificarlo partiendo de la premisa de que solo está verdaderamente completo una vez que se han monitorizado las redirecciones y se ha confirmado que el buscador las ha reconocido correctamente después del lanzamiento.

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

Al destilar el razonamiento de este caso de Douzu Carry Service en ideas que también se aplican a otros proyectos de renovación, se obtiene lo siguiente.

• El diseño de URL va primero, el diseño visual va después. Para un sitio antiguo con tráfico de búsqueda o enlaces entrantes ya existentes, finalice el inventario completo de URL y la tabla de correspondencia hacia las nuevas URL (mapeo 301) antes incluso de considerar el diseño visual.
• No lance sin un inventario de contenido. Confirme el «material de decisión», como precios, horarios de atención, datos de contacto y puntos fuertes, con una lista de verificación que coteje las páginas antiguas y nuevas una por una, antes del lanzamiento.
• Conserve solo los canales realmente en uso. Si encuentra un formulario o script de envío sin uso, verifique qué está pasando realmente y luego consolídelo en el canal que sigue activo.
• Combine cada redirección con un único salto y la verificación de la existencia del destino. No cree nunca cadenas, y disponga de un mecanismo que nunca envíe a una URL inexistente.
• Ordene los dominios mientras aún estén activos. Si deja un dominio separado para una landing page de servicio sin mantenimiento, un registro DNS caducado puede volverlo irrecuperable, costándole precisamente la oportunidad de trasladar la autoridad acumulada.

Una renovación de sitio web no es simplemente el trabajo de refrescar el diseño: es también, en sí misma, una tarea de diseño consistente en decidir cómo trasladar la autoridad de búsqueda y el flujo de contacto acumulados con el tiempo. Un resumen conciso de este caso se recoge en «el caso que recoge la estructura de Douzu Carry Service», que también merece la pena consultar.

Si tiene inquietudes similares sobre el diseño de URL o el traslado de contenido existente, podemos avanzar juntos con el inventario del sitio antiguo dentro de una consulta de desarrollo web.

Artículos relacionados

• El caso que recoge la estructura de Douzu Carry Service
• Por qué KomuraSoft construye sitios web sobre el sistema de diseño de la Digital Agency — el bajo coste y la alta calidad pueden coexistir
• Los tres lugares que hay que corregir primero en un sitio que no recibe consultas
• Desarrollo 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 sea 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.