Migrar WordPress a PHP y Supabase: así migramos sieteymedia.cl

Teníamos un sitio que posicionaba bien en Google y decidimos desarmarlo igual. sieteymedia.cl funcionó años sobre WordPress, con BeTheme, Elementor y NitroPack, y nos trajo clientes. Esta semana lo reemplazamos por un sitio en PHP a medida con Supabase. La primera medición en PageSpeed Insights pasó de 62 a 98 en móvil y de 83 a 100 en escritorio. Aquí contamos por qué decidimos migrar WordPress a PHP, cómo lo hicimos sin improvisar con el SEO y qué cambió en nuestra forma de trabajar.

Por qué decidimos migrar WordPress a PHP

WordPress no nos falló. Nos permitió publicar cientos de entradas, armar páginas de servicio con Elementor y competir en búsquedas difíciles. NitroPack, en particular, hizo un trabajo notable: sin ese plugin, el sitio habría sido bastante más lento.

El problema era justamente ese. Para que el sitio rindiera bien necesitábamos un tema, un constructor visual y un plugin de optimización trabajando sobre el mismo código, cada uno con sus actualizaciones y sus licencias. Tres razones terminaron de inclinar la balanza:

• Rendimiento prestado: la velocidad dependía de una capa de optimización encima de un código que cargaba más de lo que usaba.
• Seguridad: cada plugin y el propio tema eran código de terceros corriendo en nuestro servidor, y eso nos preocupaba.
• Velocidad de trabajo: crear una landing o publicar una noticia pasaba por el editor visual, página por página.

Es la misma conversación que tenemos con clientes que evalúan plantilla WordPress o diseño web corporativo a medida. Esta vez el cliente éramos nosotros.

Qué construimos en reemplazo

Migrar WordPress a PHP no significa volver a escribir HTML a mano en cada página. Significa reemplazar un sistema genérico por uno hecho para lo que el sitio realmente necesita: páginas de servicio, blog, portafolio y formularios, todo alimentado desde una base de datos.

El sitio nuevo está escrito en PHP, con plantillas compartidas para encabezado, pie y metadatos, y sin tema ni constructor visual. Es el mismo enfoque que aplicamos en nuestros proyectos de diseño de páginas web en Chile cuando el sitio necesita rendimiento y control.

El contenido vive en Supabase y se administra desde el CRM que ya usábamos para la agencia. Desde ahí gestionamos:

• Entradas del blog, con su categoría, título SEO, meta descripción y keyword foco.
• Portafolio de proyectos y clientes.
• Redirecciones 301 y monitoreo de errores 404.

Lo programamos con Claude Code. Nosotros definimos la arquitectura, el modelo de datos y las reglas, y revisamos cada entrega, como explicamos en diseño web con inteligencia artificial: lo que no delegamos. El detalle del stack y del proceso está en nuestra guía de página web a medida.

Paso 1: inventario de URLs

Antes de escribir una línea de código hicimos lo que recomendamos a cualquier cliente: un inventario completo de lo que existía. Exportamos todas las entradas publicadas desde la API de WordPress, las páginas de servicio y las URLs que Search Console mostraba con impresiones.

Ese cruce reveló cosas que no se ven desde el panel de WordPress. Había 39 URLs en inglés indexadas, restos de un plugin de traducción que ya no usábamos; URLs con parámetros extraños; direcciones mal escritas que recibían impresiones por enlaces rotos, y decenas de páginas de categorías y paginación compitiendo en Google. Ninguna de esas URLs se podía ignorar en la migración.

También revisamos qué páginas traían clics y en qué búsquedas aparecían. La página de diseño web en Chile, por ejemplo, era una de las que más clics generaba en todo el sitio, así que su URL y su contenido se trataron como intocables durante la migración. Saber qué protege el tráfico actual evita romper justo lo que funciona.

Con el inventario armado, cada URL recibió una decisión: se mantiene, se reescribe, se fusiona con otra o se elimina con redirección. Esa tabla, y no el diseño, fue el documento central del proyecto.

Paso 2: redirecciones 301

Una migración pierde posicionamiento cuando una URL que Google conoce empieza a devolver error. Por eso cada URL que cambió o desapareció tiene su redirección 301 hacia la página equivalente, siguiendo la guía de Google para mover un sitio con cambios de URL.

• Las entradas que se mantienen conservan exactamente su URL.
• Las entradas fusionadas redirigen a la que concentra el tema.
• Las URLs en inglés redirigen a su versión en español con una regla general.
• Las páginas de servicio duplicadas redirigen a la principal de su cluster.

Las redirecciones ahora se administran desde el CRM, igual que el contenido, y el sitio registra los 404 que aparezcan para corregirlos rápido. Si te interesa el caso de las versiones en inglés, lo explicamos en página web bilingüe: cómo hacerla sin perder SEO.

Paso 3: clusters y páginas de servicio

Con los años, el sitio había acumulado páginas que competían entre sí por las mismas búsquedas. Aprovechamos la migración para ordenar el contenido en clusters: software a medida y apps, diseño y desarrollo web, SEO, Google Ads, marketing B2B, redes sociales y recursos humanos.

Cada cluster tiene una página de servicio principal y un conjunto de entradas que la apoyan y enlazan hacia ella. Así, cuando alguien busca diseño web en Chile, Google encuentra una sola página fuerte respaldada por artículos relacionados, en vez de tres páginas débiles que se reparten las señales.

Paso 4: limpiar y actualizar contenido

Una migración uno a uno habría trasladado todos los problemas al sitio nuevo. Preferimos revisar el contenido entrada por entrada:

• Eliminamos textos de relleno que no respondían ninguna búsqueda real, con su redirección correspondiente.
• Actualizamos entradas que describían herramientas o enfoques que ya no usamos.
• Corregimos títulos con años vencidos o signos de exclamación.
• Reescribimos entradas que competían con una página de servicio.
• Reasignamos categorías, que se habían multiplicado sin criterio.

Fue la parte más lenta y la más rentable. Un sitio más chico y coherente le dice a Google con más claridad de qué trata, y le dice lo mismo a un cliente que llega por primera vez.

Paso 5: clientes y portafolio

En WordPress, el portafolio era una serie de páginas armadas a mano y difíciles de mantener al día. Ahora cada proyecto es un registro en la base de datos, con su cliente, tipo de trabajo, imágenes y datos SEO, y el sitio genera su ficha automáticamente. Aprovechamos para subir trabajos que nunca habían llegado al sitio. Puedes verlos en nuestro portafolio de trabajos.

Los resultados que ya podemos medir

La mejora más visible es la velocidad. Según la medición de PageSpeed Insights antes y después del cambio:

• Móvil: de 62 con WordPress a 98 con PHP y Supabase.
• Escritorio: de 83 a 100.

Lo notable no es solo el número, sino cómo se logra. Antes, el 62 en móvil ya incluía el trabajo de NitroPack. Ahora no hay ninguna capa de optimización: el sitio es rápido porque carga solo lo que usa. El puntaje de PageSpeed es una prueba de laboratorio y puede variar un poco entre mediciones, por eso también vamos a seguir los datos de usuarios reales en las Core Web Vitals.

Lo que todavía no podemos medir es el impacto en posicionamiento. Una semana es poco para eso, y cualquier migración produce movimientos mientras Google rastrea las URLs nuevas y procesa las redirecciones. Durante las próximas semanas vamos a revisar en Search Console los errores de rastreo, la indexación de las páginas principales y las posiciones de las búsquedas que ya traían clientes, como explicamos en rediseño web sin perder posicionamiento en Google.

Lo que cambió en nuestra forma de trabajar

El beneficio que más vamos a notar en el día a día no aparece en PageSpeed. Con el contenido en Supabase, publicar ya no depende de un editor visual:

• Publicamos noticias en lote con una sola instrucción SQL, con sus metadatos, preguntas frecuentes e imagen.
• Creamos landings nuevas a partir de componentes propios, sin pelear con estilos de un tema.
• Agregamos proyectos al portafolio desde el CRM en minutos.
• Gestionamos redirecciones sin instalar un plugin más.

También dormimos más tranquilos: menos código de terceros en el servidor significa menos piezas que vigilar. No es una garantía de seguridad absoluta, pero sí una superficie mucho más chica y un código que conocemos línea por línea.

Lo que aprendimos y aplicamos con clientes

Migrar WordPress a PHP en nuestro propio sitio fue la mejor prueba de lo que recomendamos. Las lecciones que nos llevamos:

1. El inventario de URLs vale más que el diseño: sin él, la migración es una apuesta.
2. Cada URL necesita una decisión explícita, aunque sea eliminarla.
3. Migrar es la mejor oportunidad para limpiar contenido; trasladarlo tal cual desperdicia el esfuerzo.
4. La velocidad que se gana con un plugin no se compara con la que viene de un código liviano.
5. Administrar el contenido desde una base de datos propia acelera todo lo que viene después.

No es la primera vez que recorremos este camino. En el caso de audaxitaliano.app la migración a PHP y Supabase convirtió a Google en el principal canal de visitas del sitio.

Si tu empresa tiene un WordPress que funciona pero depende de demasiados plugins, en nuestra agencia de desarrollo web partimos por el mismo inventario que hicimos con nuestro sitio: qué URLs tienes, cuáles posicionan y qué conviene conservar, antes de hablar de tecnología.

Dejamos un WordPress que funcionaba por un sitio en PHP y Supabase que carga más rápido, depende menos de terceros y nos deja publicar en minutos. El trabajo de fondo no fue programar, sino decidir qué hacer con cada URL y cada texto. ¿Cuántas de las páginas de tu sitio podrías justificar hoy si tuvieras que migrarlas una por una?