Por qué construimos en código y no en WordPress

Durante años hicimos sitios en WordPress: el corporativo de una cadena de supermercados, la plataforma de un agromercado, una escuela de idiomas con un plugin LMS y el sitio de una oficina de arquitectura armado con Elementor. Lo conocemos desde dentro, con sus ventajas y sus límites. Hoy, cuando alguien nos pide un sitio nuevo, lo construimos en código con Next.js y React. Aquí explicamos por qué, y también cuándo te recomendaríamos quedarte en WordPress.

WordPress

solicitud

tema

page builder

pluginsactualizar

formulariosSEOcachéseguridadslider

slider · desactualizado

consultas a la base de datos

navegador

Cada capa es una actualización pendiente y un punto que puede fallar.

Next.js

solicitud

página ya generada en el edge

navegador

Sin plugins en el camino: la página ya estaba lista.

Qué pasa cuando alguien visita una página en WordPress

Un sitio típico en WordPress tiene tres capas encima del contenido: un tema que define el diseño, un page builder como Elementor para armar las páginas y una lista de plugins para todo lo demás, desde formularios y SEO hasta caché, seguridad y sliders.

Cuando llega una visita, el servidor ejecuta PHP, carga el tema, el page builder y cada plugin activo, y consulta la base de datos para armar la página. Solo después el navegador recibe el HTML. Un plugin de caché puede guardar el resultado y saltarse parte de ese trabajo, pero es otra capa que configurar y mantener, y un cambio en cualquiera de las demás puede invalidarla.

Cada pieza la escribe un equipo distinto y se actualiza a su ritmo. Cuando un plugin queda desactualizado o choca con otro después de una actualización, el sitio se rompe, se ve distinto o queda expuesto a una vulnerabilidad ya publicada.

Qué pasa con una página pre-renderizada en Next.js

En Next.js las páginas de contenido se generan una vez, cuando publicamos el sitio, y no cada vez que alguien las pide. El resultado es HTML listo que se sirve desde servidores cercanos al visitante, lo que se conoce como el edge. Cuando llega la solicitud no hay plugins que cargar ni consultas que hacer, porque la página ya estaba lista.

Si el contenido cambia, esa página se vuelve a generar. Con un CMS como Sanity, el equipo edita textos e imágenes en un panel y el sitio actualiza solo lo que cambió. Las partes que sí necesitan un servidor, como el envío de un formulario de contacto, se resuelven con funciones hechas para esa tarea y nada más.

Mantenimiento, seguridad y propiedad del código

En WordPress, mantener un sitio es actualizar el núcleo, el tema y cada plugin, y después revisar que nada se rompió. Un sitio en código también tiene dependencias que actualizar, pero sus versiones quedan fijadas en el repositorio y cada cambio se prueba antes de publicarse. Nada se actualiza solo en producción.

La seguridad sigue la misma lógica. Cada plugin agrega código de un tercero que corre en tu servidor con acceso a tu base de datos, y si ese tercero tarda en publicar un parche, tu sitio espera con él. Una página ya generada no tiene un panel de administración ni una base de datos detrás de cada visita, así que hay mucho menos que atacar.

Con WordPress, buena parte del sitio suele depender de licencias premium del tema, del page builder o de algunos plugins, que se renuevan cada año. En nuestros proyectos en código el repositorio es del cliente, queda versionado en Git con todo su historial y se despliega con Docker en un VPS o en la nube que prefieras. Si mañana trabajas con otro equipo, le entregas el repositorio y sigue desde ahí.

Cómo migramos sin perder posicionamiento

La pregunta que más nos hacen es si al dejar WordPress se pierde lo ganado en Google. El objetivo es no perderlo, y para eso seguimos cuatro pasos:

1. Auditamos el sitio actual: páginas, plugins, el tráfico que ya recibe y qué URLs lo traen.
2. Armamos un mapa de URLs donde cada dirección antigua apunta a su equivalente nueva. Cuando se puede, conservamos la misma.
3. Migramos el contenido con el SEO técnico listo desde el primer día: metadatos, datos estructurados, sitemap y versiones por idioma con hreflang.
4. Publicamos con las redirecciones 301 activas y revisamos Search Console en las semanas siguientes.

Nadie puede garantizar posiciones exactas en Google. Lo que sí baja el riesgo es que ninguna URL que hoy recibe visitas termine en un error 404.

Cuándo WordPress sigue siendo la mejor opción

No recomendamos código para todo. WordPress sigue siendo una buena elección, y te lo vamos a decir, si:

• Tu equipo necesita instalar funciones por su cuenta, sin pasar por un desarrollador.
• El presupuesto inicial es muy ajustado y una plantilla resuelve lo que necesitas.
• El negocio depende de un plugin concreto. Una tienda pequeña en WooCommerce, como la que hicimos para Life Kombucha, puede estar mejor donde está.

El código también tiene un costo: los cambios de estructura, como una sección nueva o un tipo de página distinto, pasan por un desarrollador. Con un panel de edición tu equipo cambia textos, imágenes y entradas sin tocar código, pero no rediseña páginas arrastrando bloques como en Elementor.

Por dónde empezar

En desarrollo web explicamos el proceso completo de un sitio en código. El caso de Cube Media muestra uno real: una productora audiovisual que edita su portafolio desde Sanity CMS, en español e inglés, sin plugins. Si ya tienes un sitio en WordPress y no sabes si conviene migrarlo, cuéntanos cómo funciona hoy y te decimos si vale la pena.