Si estás pensando en hacer o rehacer tu web, antes o después alguien te va a soltar la frase "WordPress está muerto, tienes que irte a Next.js". Y al revés: "Next.js es para programadores, tú necesitas WordPress". Ambas afirmaciones son mentira cuando se sueltan sin contexto.
WordPress y Next.js son dos herramientas muy potentes que resuelven problemas distintos. Elegir mal no te va a arruinar el negocio, pero te va a costar dinero, tiempo y oportunidades de crecimiento. En esta guía te explico, sin fanatismos, cuándo conviene cada una, qué ventajas reales tienen y cómo lo planteamos nosotros cuando un cliente en Tenerife nos pregunta qué hacer.
Qué es WordPress y qué lo hace fuerte
WordPress es un gestor de contenidos (CMS) que existe desde 2003. A día de hoy mueve aproximadamente el 40% de las webs del mundo. Usa PHP en el servidor, base de datos MySQL y un frontend tradicional que se renderiza en el servidor. Se instala sobre un hosting (que puede ser compartido, VPS o gestionado) y se administra por un panel web.
Ventajas reales de WordPress
Ecosistema enorme. Hay plugins para casi todo: formularios, SEO, caché, tiendas online, reservas, multi-idioma, membresías. Lo que no existe se puede programar. La comunidad es gigante y encuentras solución rápida a casi cualquier problema.
Edición de contenido accesible. Cualquier persona con alfabetización digital básica puede actualizar textos, añadir páginas y subir fotos sin depender de un desarrollador. Para negocios que generan contenido (noticias, blog, catálogo) esto es oro.
Coste inicial contenido. Un WordPress bien construido sobre plantilla premium y bloques tipo Gutenberg o constructores serios (Bricks, Breakdance) puede lanzarse en 3-4 semanas a un coste ajustado.
WooCommerce. Para tiendas online de complejidad media, WooCommerce es una opción muy sólida, ampliable y con integraciones serias con facturación, ERPs y pasarelas.
Mercado de mano de obra. Encontrar desarrolladores WordPress en Tenerife y Canarias es fácil. Si necesitas cambiar de proveedor, no te quedas atrapado.
Desventajas que conviene mirar de frente
Seguridad. WordPress es el CMS más atacado del mundo precisamente por ser el más usado. Un WordPress mal mantenido es una puerta abierta. Requiere actualizaciones constantes, WAF, backups, monitorización y buenas prácticas.
Velocidad por defecto. Sin optimización, un WordPress con plantillas y plugins tiende a ser pesado. Lograr Core Web Vitals sólidos requiere trabajo técnico real: caché, minificación, imágenes optimizadas, hosting potente y plantillas limpias.
Deuda técnica. Cuando se acumulan plugins mal programados, modificaciones directas en el tema o soluciones temporales, el mantenimiento se vuelve cada año más costoso.
Actualizaciones que rompen. Un plugin desactualizado puede romper una funcionalidad crítica. Un tema mal hecho puede no ser compatible con la siguiente versión de PHP.
Qué es Next.js y por qué está ganando espacio
Next.js es un framework de desarrollo web basado en React. No es un CMS: es una base sobre la que se construyen aplicaciones web modernas. Se aloja típicamente en Vercel, Netlify o servidores Node.js bien configurados. El contenido puede venir de un headless CMS (Sanity, Payload, Strapi, Contentful) o ser estático.
Ventajas reales de Next.js
Velocidad nativa. Next.js permite renderizado estático, incremental o server-side según convenga. Combinado con CDNs globales, los sitios cargan en milisegundos desde cualquier punto del mundo. Core Web Vitals excelentes sin hacer malabares.
SEO técnico sólido. Control absoluto sobre metadatos, datos estructurados, URLs, headers, sitemap y rendimiento. Para proyectos donde el SEO es crítico, es una plataforma más limpia que WordPress.
Seguridad. Sin base de datos expuesta, sin plugins de terceros y con superficie de ataque mucho más reducida, un sitio Next.js bien desplegado es mucho menos vulnerable.
Escalabilidad. Aguanta picos de tráfico sin caerse. Si tu web puede aparecer en televisión, en un podcast o en un medio grande, Next.js escala sin sudar.
Ecosistema de componentes moderno. React, Tailwind CSS, bibliotecas de animación (Framer Motion), integraciones con APIs externas. Todo lo que ves en webs "tipo Stripe" o "tipo Linear" se construye con este stack.
Desventajas que debes conocer
Curva de aprendizaje. No lo instalas tú en una tarde. Requiere desarrolladores que sepan React, TypeScript y despliegue moderno. Editar contenido sin CMS asociado significa tocar código.
Coste inicial mayor. Un Next.js bien hecho cuesta más a corto plazo que un WordPress equivalente. El retorno viene por rendimiento, SEO y baja fricción de mantenimiento.
Necesita un CMS headless para autogestión. Si quieres que alguien no técnico edite páginas, necesitas Sanity, Payload o similar. Esto añade una capa y un coste extra.
Mercado de proveedores más reducido. En Tenerife hay menos equipos con experiencia real en Next.js que en WordPress. Al elegir, asegúrate de que quien te lo implanta sabe lo que hace.
Tabla comparativa rápida
| Criterio | WordPress | Next.js |
|---|---|---|
| Velocidad por defecto | Media (mejora con trabajo técnico) | Muy alta |
| SEO técnico | Bueno con plugins | Excelente nativo |
| Coste inicial | Bajo-medio | Medio-alto |
| Mantenimiento | Alto si se descuida | Bajo |
| Escalabilidad | Media | Alta |
| Facilidad para editar contenido | Alta | Media (requiere CMS headless) |
| Seguridad | Requiere vigilancia constante | Alta por diseño |
| Ecosistema de plugins/integraciones | Enorme | Moderno y creciente |
| Hosting | Barato a muy caro | Moderno (Vercel, Netlify, Node.js) |
| Mercado de mano de obra local | Grande | Más reducido |
Cuándo elegir WordPress
Hay escenarios donde WordPress sigue siendo la elección más inteligente y honesta.
Tienes un equipo que va a editar contenido a menudo. Blog activo, publicación de noticias, catálogo que cambia, novedades semanales. WordPress con Gutenberg es imbatible en productividad editorial.
Tienda online WooCommerce de catálogo amplio y moderadamente compleja. Para un e-commerce de 100-3.000 productos, con variaciones, envíos a distintas zonas y facturación integrada, WooCommerce tiene madurez probada.
Presupuesto ajustado con necesidades estándar. Una web corporativa clásica, con servicios, blog, contacto y buena ficha de Google, se puede hacer en WordPress por menos dinero y con resultados perfectamente dignos.
Equipos de marketing interno que necesitan autonomía. Si tu equipo de marketing quiere crear landings, campañas o publicar sin pasar por desarrollo, WordPress con constructor serio les da esa autonomía.
Portales con muchos autores, roles y flujos editoriales. WordPress maneja con solvencia usuarios con permisos distintos, aprobaciones y múltiples redactores.
Cuándo elegir Next.js
Next.js brilla en otros escenarios.
Landing pages y sitios corporativos donde el rendimiento es crítico. Si quieres un 90-100 en PageSpeed sin discusión, Next.js lo entrega casi de serie.
Proyectos con SEO técnico exigente. Portales con miles de páginas generadas dinámicamente, URLs multilingües complejas, datos estructurados avanzados. Ahí Next.js es superior.
Aplicaciones web con funcionalidades específicas. Paneles, dashboards, portales de clientes, configuradores de producto, simuladores. Lo que en WordPress sería una batalla de plugins, en Next.js es código limpio.
Proyectos que van a escalar a mucho tráfico. Si el plan de negocio contempla picos fuertes (medios, campañas virales, estacionalidad extrema), Next.js aguanta mejor.
Proyectos donde el diseño importa mucho. Animaciones suaves, interacciones de calidad, tipografía fina, experiencia cuidada. El frontend moderno de React te da libertad que WordPress penaliza.
Arquitecturas multi-frontend. Un mismo CMS alimentando web pública, app móvil y panel interno. Next.js encaja de forma natural.
Cómo trabajamos en YAG: ambos stacks según caso
Nosotros no somos fanáticos de ningún stack. Usamos el que tenga sentido.
WordPress: Lo usamos sobre todo para clientes que necesitan autonomía editorial, WooCommerce y mantenimiento accesible a futuro. Lo construimos limpio: temas light o a medida, pocos plugins bien elegidos, caché y CDN de serie, hosting optimizado y monitorización mensual.
Next.js: Lo usamos para nuestros propios sitios (yagcomunicacion.com, jurisranking, DameUnAbogado) y para clientes con proyectos donde rendimiento, SEO técnico o complejidad funcional lo requieren. Combinamos Next.js con Sanity o Payload cuando el cliente necesita editar contenido sin tocar código.
Con 14+ años en el mercado, 890+ proyectos entregados y 300+ dominios gestionados, hemos visto suficientes escenarios como para no casarnos con una tecnología. La elección es parte del diagnóstico.
Puedes ver el alcance de nuestros servicios en diseño web y tienda online.
Astro: la tercera opción que nadie menciona
Cuando la gente se sienta a decidir el stack de su web en Tenerife, el debate casi siempre se reduce a WordPress o Next.js. Pero hay una tercera opción que lleva dos años subiendo con fuerza y que en muchos escenarios es la elección más sensata: Astro. No lo menciono por modernidad: lo menciono porque en algunos proyectos es objetivamente la mejor herramienta y, sin embargo, casi nadie en Canarias lo está utilizando todavía.
Qué es Astro
Astro es un framework de desarrollo web moderno, nacido en 2021, orientado específicamente a sitios web centrados en contenido. Su propuesta es clara: enviar cero JavaScript al navegador por defecto. En lugar de hidratar toda la página con React (como hace Next.js por defecto en sus versiones tradicionales), Astro genera HTML puro y solo "despierta" interactividad en los componentes que tú marques explícitamente. Esa técnica se llama islands architecture (arquitectura de islas).
¿Qué significa esto en la práctica? Que una landing compleja con varias secciones, carrusel, formulario y mapa puede servirse como HTML casi estático, y solo esos tres o cuatro componentes concretos llevan JavaScript. El resto no pesa nada. La diferencia de rendimiento frente a un Next.js sin optimizar puede ser de 2-3x en métricas reales.
Cuándo tiene sentido Astro
Astro brilla en un escenario muy concreto: sitios centrados en contenido con poca interactividad compleja. Blogs profesionales, sitios de documentación, landings de marketing, webs corporativas pequeñas y medianas, portfolios, portales de medios de comunicación, sitios de SEO puro donde lo importante es publicar mucho y rápido.
Si tu web es básicamente páginas que el usuario lee y navega, con algún formulario y alguna interacción puntual, Astro es probablemente más adecuado que Next.js. Nuestros propios blogs técnicos y algún sitio de cliente enfocado a contenido los estamos evaluando en esta línea.
Ventajas sobre Next.js
Aún más rápido en sitios de contenido. Para una web tipo blog o corporativa, Astro es más rápido que Next.js porque no envía JavaScript de React al navegador. Esto se traduce en LCP (Largest Contentful Paint) más bajo, mejor TTFB y puntuaciones de PageSpeed cercanas a 100 casi sin tocar nada.
DX más simple. La curva de aprendizaje es más suave que Next.js. Los componentes se parecen a HTML puro con algo de magia, y no tienes que pelearte con server components, client components, directivas "use client" ni fronteras raras. Si tu desarrollador viene de HTML/CSS clásico, la transición es mucho más natural.
Menor coste de hosting. Al generar archivos estáticos por defecto, puedes desplegarlo en Cloudflare Pages, Netlify, Vercel o incluso en un hosting barato con S3+CDN por céntimos al mes. Next.js, cuando se configura con SSR, puede acabar costando más en infraestructura.
Integra lo que quieras. Astro permite usar React, Vue, Svelte o Solid dentro del mismo proyecto. Tienes libertad total sin atarte a un framework.
Ventajas sobre WordPress
Frente a WordPress las ventajas son las mismas que tiene Next.js, pero aún más marcadas en ciertos aspectos: seguridad casi total (no hay PHP, no hay base de datos expuesta, no hay panel de administración atacable), velocidad absoluta y tooling moderno (Git, CI/CD, previews por rama, control de versiones real del contenido cuando se usa con un CMS headless o Markdown en repo).
Desventajas reales
Ecosistema más joven. No hay "plugins" al estilo WordPress. Si necesitas una funcionalidad concreta, probablemente la tengas que programar o integrar a mano. El marketplace es mínimo comparado con los 60.000+ plugins de WordPress.
Menos integraciones listas. CRMs, pasarelas de pago, sistemas de reservas, herramientas de marketing: en WordPress hay un plugin para casi todo. En Astro tienes que integrar por API.
Sin economía de temas comerciales. El mercado de temas de Astro es una fracción del de WordPress. Si buscas "tema para clínica dental" en Astro, puede que no lo encuentres.
Mano de obra local escasa. En Tenerife hay poca gente con experiencia real en Astro. Si quieres ir por este camino, asegúrate de tener proveedor que sepa lo que hace.
Cuándo NO usar Astro
No uses Astro si tu proyecto tiene:
- Interactividad compleja (dashboards, herramientas en tiempo real, editores visuales, aplicaciones de gestión).
- Autenticación con sesiones complejas, roles, permisos granulares.
- Funcionalidad en tiempo real (chat, notificaciones push, datos live).
- E-commerce complejo con carrito, checkout y gestión de pedidos a escala.
- Lógica de backend intensiva integrada en el propio framework.
En esos casos, Next.js es mejor herramienta.
Dónde encaja Astro en el mercado de Tenerife
En Canarias, Astro es terreno casi virgen. Eso es a la vez oportunidad y riesgo. Oportunidad porque un sitio bien hecho en Astro tendrá una ventaja competitiva clara en velocidad y SEO técnico sobre competidores en WordPress. Riesgo porque el soporte local es escaso y si tu proveedor desaparece, puedes tener problemas para encontrar relevo. En YAG lo estamos evaluando para proyectos de contenido de clientes que quieren jugar en las primeras posiciones orgánicas sin el peso de WordPress y sin la complejidad de Next.js.
El impacto real en SEO: por qué la plataforma importa más de lo que crees
Hay un mito extendido de que el SEO "es SEO" y que la plataforma no importa tanto. Eso era verdad hasta 2020. Hoy, con Core Web Vitals como factor de ranking confirmado por Google y con la competencia cada vez más afinada, la plataforma sí pesa. Mucho.
Core Web Vitals: ya no es opcional
Google lleva desde 2021 empujando los Core Web Vitals (LCP, CLS, INP) como factor de ranking. En 2024 lo confirmó oficialmente como señal de "page experience" dentro del sistema de clasificación. No es el factor más importante, pero es un desempate cuando compites con otros resultados de calidad similar en contenido y autoridad.
Los datos concretos son contundentes. Estudios de Portent, Cloudflare y del propio equipo de Chrome demuestran lo siguiente: una mejora de LCP de 4 segundos a 1.5 segundos reduce la tasa de rebote entre un 25% y un 35%, y puede aumentar las conversiones entre un 15% y un 25% en sitios de e-commerce y generación de leads. En sitios de contenido, el tiempo medio en página sube un 20-30% cuando el LCP baja de 3s a 1s.
Traducción simple: si tu competencia carga en 1.5 segundos y tú en 4, pierdes tráfico, pierdes conversión y pierdes ranking. No es teórico.
WordPress: puede alcanzar buenos CWV, pero cuesta
WordPress puede llegar a Core Web Vitals decentes, sí. Lo he visto muchas veces. Pero requiere una lucha constante contra el peso de la plataforma: plugins que meten scripts que no usas, temas mal optimizados, imágenes mal servidas, PHP que tarda más de la cuenta, caché que falla en la página que menos quieres.
La receta conocida funciona: hosting potente tipo Kinsta o WP Engine, caché de objeto (Redis o Memcached), plugin de caché serio (WP Rocket, LiteSpeed Cache), CDN (Cloudflare), plantilla ligera (GeneratePress, Blocksy), compresión de imágenes, lazy loading, minificación, tree-shaking del CSS crítico. Pero cada actualización de plugin puede romper algo. Cada nuevo plugin que se instala puede tirar tus métricas. Es un mantenimiento activo, no se soluciona una vez.
Next.js: CWV excelentes casi de serie
Next.js con ISR (Incremental Static Regeneration) desplegado en Vercel o Cloudflare entrega Core Web Vitals excelentes sin hacer nada especial. LCP por debajo de 1.5s, CLS cercano a cero, INP óptimo. Componentes como <Image> optimizan imágenes automáticamente, el CSS se divide por ruta, el JavaScript se trocea y solo se carga lo necesario.
¿Significa que Next.js es infalible? No. Un mal desarrollador puede tirar cualquier stack. Pero el punto de partida es mucho mejor y el coste de mantener las métricas verdes es mucho menor.
Capacidades SEO específicas por plataforma
WordPress. Yoast y RankMath son buenos plugins para gestionar metadatos básicos, sitemaps, Open Graph y schemas simples. Pero cuando necesitas schemas complejos personalizados (FAQ anidado dentro de Article con Author y Organization relacionados, datos estructurados de producto con múltiples variantes, eventos locales con horarios), empiezan a limitar. La gestión fina de URLs, redirecciones masivas, reglas de .htaccess, canonicals condicionales y robots dinámicos suele requerir meterse en el código o pagar plugins adicionales.
Next.js. Control total. JSON-LD lo inyectas donde quieras, como quieras y con la estructura que tú decidas. Generas imágenes Open Graph dinámicas por ruta con código. Tienes control absoluto sobre robots.txt, sitemap.xml, cabeceras HTTP, canonicals, hreflang y redirecciones 301. No hay caja negra. Si algo no funciona, lo arreglas; no dependes de que el plugin lo soporte.
Velocidad de indexación
Las páginas estáticas de Next.js se indexan más rápido. Google rastrea HTML limpio y ligero mucho más eficientemente que páginas WordPress con decenas de scripts, CSS y requests. En proyectos grandes con 10.000+ URLs, la diferencia en crawl budget es notable: Googlebot cubre más páginas por sesión.
Enlazado interno
Ambas plataformas pueden hacer buen enlazado interno. La diferencia es el control programático. En Next.js puedes escribir lógica que enlace automáticamente páginas relacionadas según datos, taxonomías o similitud semántica. En WordPress es posible pero típicamente más manual o dependiente de plugins.
Para negocios de Tenerife a nivel local
Seamos claros. Para competir por "abogado laboralista tenerife", "reformas integrales la laguna" o "dentista santa cruz", la plataforma no es el factor limitante. Con WordPress bien optimizado llegas al top 3 si tienes buen contenido, reseñas, Google Business Profile trabajado y algún backlink local. Aquí pesa más el SEO local y la autoridad de dominio que los Core Web Vitals.
Pero a escala competitiva cambia. Si tu negocio quiere posicionar a nivel nacional, crear cientos de páginas programáticas (una por localidad + servicio), competir en sectores saturados como viajes, hoteles, seguros o derecho a gran escala, o aguantar competencia de medios y marketplaces, Next.js te da una ventaja técnica real y medible. No es garantía de éxito, pero elimina un cuello de botella que en WordPress siempre va a estar presente.
Análisis de costes real a 3 años: la cuenta que nadie hace
Cuando un cliente pide presupuesto, casi siempre pregunta: "¿Cuánto cuesta hacer la web?". La pregunta correcta es: "¿Cuánto me cuesta tener la web funcionando bien durante 3 años?". La diferencia entre una pregunta y otra puede ser de miles de euros y de decisiones completamente distintas.
Vamos a hacer esa cuenta con números reales. Proyecto medio: web corporativa de servicios, blog activo, 30-50 páginas, tráfico mensual creciente, mantenimiento profesional.
WordPress — coste total 3 años
| Concepto | Coste |
|---|---|
| Desarrollo inicial (web bien hecha, no plantilla plana) | 2.500 EUR |
| Hosting gestionado (Kinsta Starter o similar) | 35 EUR/mes x 36 = 1.260 EUR |
| Renovación anual de plugins premium (SEO, seguridad, formularios, caché, backups) | 300 EUR/año x 3 = 900 EUR |
| Servicio de mantenimiento mensual (actualizaciones, monitorización, soporte) | 80 EUR/mes x 36 = 2.880 EUR |
| Incidente de seguridad (promedio 1 cada 2 años en WP bien mantenido) | 300 EUR |
| TOTAL 3 AÑOS | ~7.840 EUR |
Si el WordPress está mal mantenido, los incidentes de seguridad pueden disparar el coste fácilmente en 1.000-3.000 EUR más por hackeos, limpiezas o caídas. Si se descuidan las actualizaciones, la deuda técnica acaba obligando a una reconstrucción al año 3 o 4.
Next.js — coste total 3 años
| Concepto | Coste |
|---|---|
| Desarrollo inicial (más upfront por complejidad del stack) | 4.500 EUR |
| Hosting (Vercel Pro o VPS Hetzner con Node.js) | 20 EUR/mes x 36 = 720 EUR |
| CMS headless (Sanity free tier o Payload self-hosted) | 0-30 EUR/mes x 36 = 0-1.080 EUR |
| Servicio de mantenimiento (menos piezas móviles, menos superficie) | 60 EUR/mes x 36 = 2.160 EUR |
| Incidentes de seguridad | ~0 EUR |
| TOTAL 3 AÑOS | ~7.380-8.460 EUR |
La conclusión que poca gente cuenta
El coste total de propiedad (TCO) a 3 años es prácticamente idéntico. WordPress parece más barato al principio (2.500 EUR vs 4.500 EUR de desarrollo) pero el coste recurrente acaba igualando la cuenta. Next.js es más caro upfront pero cada mes que pasa la diferencia se diluye porque el mantenimiento, el hosting y los incidentes de seguridad pesan mucho menos.
Dónde cambia la ecuación
WordPress se vuelve más caro si:
- Tu equipo no es experto en plugins y caché, y pagas a alguien para que lo mantenga bien.
- Sufres un incidente de seguridad serio (defacement, malware, fuga de datos).
- Necesitas funcionalidad custom que requiere desarrollar plugins propios.
- El crecimiento de tráfico obliga a subir de hosting varias veces.
Next.js se vuelve más caro si:
- Necesitas añadir funcionalidad muy custom que no existe out-of-the-box.
- Cambias de desarrollador y el nuevo es menos eficiente con el stack.
- Escalas a volúmenes donde Vercel empieza a cobrar por uso agresivo (eso pasa con cientos de miles de visitas/mes).
La lectura honesta
Nadie que te diga "Next.js es más caro" o "WordPress es más barato" está haciendo la cuenta completa. A 3 años están empatados, y lo que decide el coste total es el perfil de uso, la calidad del mantenimiento y la previsión de crecimiento, no la tecnología en sí.
Si tu prioridad es minimizar el desembolso inicial, WordPress gana. Si tu prioridad es minimizar la fricción de mantenimiento, los dolores de cabeza y el riesgo de seguridad, Next.js gana. Si optimizas por TCO a 3 años, están empatados y la decisión se toma por otros criterios: equipo, contenido, crecimiento esperado.
Por sectores: qué usan los negocios de Tenerife y por qué
Viendo 890+ proyectos, 300+ dominios gestionados y conversaciones con decenas de negocios locales, hay patrones claros por sector en Tenerife. Esta no es teoría: es lo que vemos funcionando (o no funcionando) en el mercado canario.
Hoteles y alojamientos turísticos
Hoteles pequeños y casas rurales (5-30 habitaciones): WordPress con WooCommerce Bookings o Hotel Booking plugin. Suficiente para gestionar reservas simples, calendarios de disponibilidad y pagos. Coste razonable, equipo puede actualizar temporadas.
Resorts y hoteles grandes con pricing dinámico, múltiples idiomas, integración con channel managers y motores de reserva: Next.js con integración directa al PMS (Property Management System) del hotel vía API. Mayor inversión inicial pero mucho mejor rendimiento, conversión y experiencia multi-idioma. En un sector donde 0.5 segundos más de carga reducen reservas directas un 10%, el stack importa.
Restaurantes
WordPress casi siempre. Este sector no necesita complicaciones. Menú digital, fotos, formulario de reservas (o integración con TheFork/Covermanager), ficha de Google trabajada. Un equipo no técnico tiene que poder actualizar la carta los lunes sin llamar al desarrollador. WordPress con una plantilla ligera y un plugin de reservas decente cubre el 95% de los casos.
Excepción: grupos de restauración con múltiples locales, apps de pedidos propias o sistemas de fidelización sofisticados. Ahí sí puede justificarse Next.js como frontend unificado.
Clínicas y centros médicos
Clínica pequeña o de una especialidad: WordPress con buen plugin de formularios (WPForms o Forminator), cumplimiento RGPD estricto en cookies y formularios, integración con email marketing. Página por servicio, blog con contenido útil, fichas de profesionales. Resuelve perfectamente.
Clínicas multiespecialidad grandes o con integración con sistemas de citas reales (Doctoralia, Salud Tools, software de gestión clínica): Next.js con API pública de citación. Permite integrar el flujo de reserva directamente en la web sin redirecciones a terceros, mantiene al usuario y mejora la conversión.
Punto crítico en salud: RGPD y seguridad de datos son innecesariamente discutibles. WordPress puede cumplir, pero requiere más vigilancia activa. En Next.js el perímetro es más estrecho y es más fácil garantizar cumplimiento técnico.
Despachos legales y asesorías
La mayoría: WordPress. Web de servicios, blog con artículos sobre derecho, formulario de contacto, quizás calculadora simple. No requiere más. Un despacho típico de Tenerife con 3-10 abogados cubre sus necesidades con WordPress por 2.000-3.500 EUR bien hechos.
Si el despacho apuesta por content marketing a escala, quiere generar cientos de artículos jurídicos, competir a nivel nacional en keywords competitivas y automatizar SEO programático (páginas por tipo de caso + localidad), Next.js es la elección correcta. Es el caso de DameUnAbogado o jurisranking: stacks pensados para escalar contenido con rendimiento técnico sólido.
E-commerce de producto canario
Catálogo pequeño o mediano (50-2.000 productos), productos artesanos, agroalimentarios, cosmética: WooCommerce sobre WordPress. Es lo que todo el mundo conoce, la pasarela de pago funciona, las integraciones con empresas de mensajería locales (Correos, SEUR, GLS) están resueltas, y un equipo no técnico puede gestionar el catálogo.
Si el negocio vende internacionalmente, quiere cero dolor de cabeza con infraestructura, y factura más de 100.000 EUR/año online: Shopify. La curva de abandonar infraestructura propia se compensa con estabilidad, escalabilidad y soporte. También se puede usar Shopify como backend con frontend en Next.js (Shopify Hydrogen o custom), pero solo justifica para marcas con equipo técnico.
Startups y SaaS
Next.js casi siempre. Necesitan velocidad de iteración, buen stack para el equipo, escalabilidad cuando crezcan, experiencia cuidada para compensar que son marcas desconocidas. WordPress en una startup tech es una señal extraña, y rara vez tiene sentido salvo para el blog si decides separarlo.
Agencias inmobiliarias
Agencias locales con 50-300 inmuebles gestionados manualmente: WordPress con un plugin IDX o inmobiliario tipo RealEstate. Funcional y económico.
Agencias con integración a Idealista, Fotocasa, API de MLS, o portales propios con cientos de miles de propiedades: Next.js consumiendo APIs. Permite manejar volúmenes que WordPress no aguanta, filtros complejos con performance, mapas con rendimiento, y experiencia de usuario mucho mejor.
Patrón general
El patrón que veo una y otra vez: a menor tamaño y mayor autonomía editorial, WordPress es más razonable. A mayor complejidad funcional, mayor ambición SEO o mayor dependencia de datos externos, Next.js gana. La excepción siempre es el e-commerce, donde Shopify se come mercado a ambos.
WordPress headless: ¿el mejor de los dos mundos o más complejidad?
Cada cierto tiempo aparece alguien vendiendo la idea de "WordPress headless" como la solución definitiva. La propuesta es seductora: usar WordPress como backend para gestionar contenido (porque es fácil para los editores) y construir el frontend con Next.js (porque es rápido y moderno). Lo mejor de los dos mundos, ¿no?
Depende. En algunos casos sí, en la mayoría no. Y se vende más de lo que se recomienda con honestidad.
Qué es WordPress headless
"Headless" significa "sin cabeza": usar WordPress solo como API de contenido. Los editores entran al panel de WordPress de siempre, crean páginas, suben fotos y gestionan el blog. Pero el frontend público (lo que ve el visitante) no lo sirve WordPress; lo construye Next.js (o Astro, o Nuxt) consumiendo los datos vía WPGraphQL o la REST API de WordPress.
Ventajas reales
Editorial familiar. Tu equipo de contenido sigue usando el panel de WordPress que ya conoce. Cero formación nueva, cero fricción con editores que llevan años escribiendo en WP.
Rendimiento del frontend. El frontend es Next.js, así que los Core Web Vitals son excelentes, la experiencia de usuario es moderna y el SEO técnico está a tu favor.
Flexibilidad de presentación. Puedes cambiar completamente el diseño o incluso reutilizar el mismo backend para web, app móvil y otros canales sin tocar WordPress.
Desventajas reales (las que poca gente te cuenta)
La complejidad se duplica. Ahora mantienes dos sistemas: un WordPress funcional y seguro + un frontend Next.js. Dos entornos de staging, dos procesos de despliegue, dos stacks que actualizar, dos tipos de desarrolladores que pueden fallar.
La capa API añade puntos de fallo. WPGraphQL o la REST API son capas adicionales que pueden tener bugs, performance pobre en queries complejas o fallos de caché. Un fallo en la API tira el frontend. Hay que construir estrategias de fallback, caché agresiva y monitorización doble.
Mercado de desarrolladores escaso. Encontrar a alguien que sepa a la vez WordPress avanzado y Next.js con WPGraphQL es raro. Normalmente encuentras gente que sabe uno o el otro bien. Los pocos perfiles dobles cuestan significativamente más.
Previsualizaciones rotas por defecto. Una de las funciones más queridas de WordPress ("ver cómo queda antes de publicar") deja de funcionar sin configuración extra. Hay soluciones, pero hay que implementarlas y mantenerlas.
Plugins dejan de funcionar visualmente. Muchos plugins de WordPress asumen que controlan también el frontend (sliders, galerías, formularios, pop-ups). En headless, esos plugins no pintan nada. Hay que reconstruir cada funcionalidad en el frontend.
Cuándo sí tiene sentido
Equipos grandes con roles separados. Una redacción de 10 personas que solo edita, un equipo de desarrollo de 5 personas que construye el frontend. La separación de responsabilidades justifica la complejidad.
Instalación WordPress grande existente. Si ya tienes 10 años de blog en WordPress con miles de artículos, migrar a otro CMS puede ser inviable. WordPress headless te permite modernizar el frontend sin migrar el contenido.
Reutilización multi-canal. Un mismo contenido alimentando web pública, app móvil, newsletter automática y terceras plataformas. Ahí el headless CMS tiene sentido (aunque Payload o Sanity lo hacen mejor que WP headless en muchos casos).
Cuándo NO tiene sentido
Proyectos pequeños o medianos. Una web corporativa, una clínica, un restaurante, una asesoría: la complejidad añadida del headless no paga. Es matar moscas a cañonazos.
Equipos técnicos reducidos. Si solo tienes un desarrollador o una agencia pequeña, mantener dos sistemas te va a enterrar. Mejor elegir uno u otro y hacerlo bien.
Sitios con mucho contenido generado por plugins. Si dependes de plugins que controlan el frontend, headless te obliga a reconstruir todo manualmente. No compensa.
El coste real
Un WordPress headless bien construido cuesta aproximadamente un 40% más que un WordPress puro o un Next.js puro tanto en construcción como en mantenimiento. Si no hay una razón de negocio muy clara para justificar ese sobrecoste, la respuesta correcta suele ser: elige uno de los dos y hazlo bien, no ambos a medias.
Plugins vs código a medida: el debate real de la productividad
Uno de los argumentos más habituales a favor de WordPress es su ecosistema de plugins: más de 60.000 disponibles en el repositorio oficial, más los miles de premium fuera. La promesa es seductora: instala un plugin y tienes la funcionalidad. ¿Para qué pagar desarrollo a medida?
La realidad es más matizada y conviene entenderla antes de decidir.
Cuando los plugins son exactamente lo correcto
Los plugins tienen sentido cuando resuelven un problema estándar para el que ya existe una solución probada, sin necesitar personalización profunda. Algunos ejemplos de plugins que sencillamente funcionan y no tiene sentido sustituir por código propio:
- WP Rocket o LiteSpeed Cache para optimización de rendimiento: configurar, olvidarse.
- WPForms o Gravity Forms para formularios de contacto estándar: rápido, fiable, sin mantenimiento propio.
- RankMath para gestión de metadatos y sitemaps en webs de contenido.
- WooCommerce para tiendas de catálogo estándar con necesidades de pago convencionales.
- Yoast SEO Premium con su gestión de redirecciones integrada.
En estos casos, el plugin ahorra semanas de desarrollo, está mantenido por una empresa con incentivos claros, y el coste de licencia anual es mucho menor que el de desarrollar la misma funcionalidad desde cero.
Cuando los plugins se convierten en el problema
El problema aparece cuando el proyecto empieza a acumular plugins que se pisan entre sí, que no se mantienen con el ritmo de WordPress core, o que intentan resolver funcionalidades demasiado específicas para un caso de uso muy concreto.
El efecto Jenga. Un WordPress con 25-40 plugins activos es un Jenga en equilibrio. Cada actualización puede derrumbar algo. He visto webs corporativas de empresas medianas en Tenerife que llevan meses con plugins desactualizados porque el proveedor original desapareció y nadie se atreve a actualizar por miedo a romper algo. Eso es deuda técnica acumulada que más tarde o más temprano hay que pagar.
El plugin "casi perfecto". En Next.js, si quieres una funcionalidad concreta, la construyes exactamente como la necesitas. En WordPress, sueles acabar en un plugin que resuelve el 80% de tu caso y tiene el 20% que no quieres: código bloat, estilos que se cargan en todas las páginas aunque no los uses, opciones innecesarias en la base de datos, scripts que ralentizan el frontend. Conseguir que un plugin haga exactamente lo que necesitas a veces cuesta más trabajo de personalización que haberlo construido desde cero.
El plugin con propietario único. Hay plugins premium que dependen de una sola persona o empresa pequeña. Si esa empresa cierra o el desarrollador abandona el proyecto, tu funcionalidad crítica queda sin soporte. En Next.js, el código que tú escribes es tuyo y puedes mantenerlo independientemente.
La realidad del ecosistema React/Next.js
Next.js no tiene plugins en el sentido WordPress, pero tiene el ecosistema npm con millones de paquetes. La diferencia clave es cómo se integra la funcionalidad: en WordPress, un plugin puede modificar el comportamiento de cualquier parte del sistema sin que tú lo controles explícitamente. En Next.js, importas exactamente las librerías que necesitas y controlas cómo se integran.
Librerías de referencia para proyectos Next.js:
- Autenticación: NextAuth.js o Clerk, con control total del flujo.
- Formularios: React Hook Form + Zod para validación, sin dependencias pesadas.
- Email: Resend o SendGrid vía API, con plantillas controladas en código.
- CMS: Sanity, Payload o Contentlayer para Markdown en repo.
- Analytics: integración directa con Matomo, Plausible o GA4 vía paquete oficial.
- Mapas: Mapbox GL o Google Maps vía SDK oficial.
El resultado es un sistema más predecible, más fácil de depurar y sin sorpresas en producción. La contrapartida es que cada integración requiere tiempo de desarrollo y criterio técnico para elegir la librería correcta.
La regla de oro para decidir
Si existe un plugin probado, ampliamente mantenido y que resuelve exactamente tu caso sin customización profunda, úsalo. El tiempo de desarrollo que ahorras vale la dependencia.
Si el plugin requiere personalización significativa, tiene poco mantenimiento, o la funcionalidad es muy específica de tu negocio, mejor código a medida. Pagas más ahora, pero te ahorras años de fricción.
Ecosistema de desarrolladores: la realidad del mercado en Canarias
Elegir un stack no es solo una decisión técnica. Es también una decisión de negocio sobre el mercado de personas que pueden construirlo y mantenerlo. En Tenerife y Canarias en general, hay patrones claros que conviene conocer antes de comprometerse.
El mercado WordPress en Canarias
WordPress tiene la base más amplia. La mayoría de freelances y agencias locales con experiencia web trabajan en WordPress. Esto tiene consecuencias prácticas importantes:
Competencia de precio. El mercado está más saturado, lo que en teoría beneficia al cliente con precios más competitivos. En la práctica también hay más variabilidad en calidad: hay muy buenos desarrolladores WordPress en Canarias, pero también muchos que cobran poco porque construyen webs plantilla que apenas rozan la personalización.
Continuidad garantizada. Si tu proveedor actual desaparece o aumenta sus precios, encontrar un sustituto en WordPress es relativamente fácil. No te quedas atrapado con una tecnología que nadie más mantiene.
Especialización escasa en stacks avanzados. Muchos desarrolladores WordPress conocen bien el panel, los constructores de página y los plugins más populares, pero pocos saben optimizar Core Web Vitals, montar arquitecturas de caché correctas o construir plugins a medida con PHP moderno. El nivel de profundidad técnica varía mucho.
El mercado Next.js en Canarias
El mercado de Next.js en Canarias es mucho más pequeño. Eso implica:
Menor competencia de precio, mayor calidad mínima. Los desarrolladores con experiencia real en React, TypeScript y Next.js suelen venir de perfiles más técnicos y cobran más. Pero también es más improbable encontrar alguien que te entregue una web Next.js construida con plantillas copiadas sin entender lo que hace.
Riesgo de dependencia. Si tu web está en Next.js y el único equipo que conoce el proyecto deja de estar disponible, puede ser complicado encontrar relevo rápidamente en el mercado local. Es un riesgo real que hay que gestionar: documentación clara, código limpio y evitar patrones demasiado personalizados que solo entiende quien los construyó.
Tendencia al alza. Cada año hay más desarrolladores que aprenden React y Next.js en Canarias. El mercado está creciendo, aunque todavía no alcanza la masa crítica de WordPress.
Qué implica para la decisión de stack
Si valoras la autonomía de proveedor y la facilidad de cambiar de equipo en el futuro, WordPress ofrece más flexibilidad en el mercado local canario. Si priorizas calidad técnica y rendimiento y puedes trabajar con equipos remotos si hace falta, el mercado de Next.js en España y Europa es más que suficiente para encontrar buenos perfiles.
En YAG, cuando construimos Next.js para un cliente, entregamos siempre documentación del proyecto, código legible y sin magia innecesaria, y nos comprometemos a facilitar la transición si algún día deciden cambiar de proveedor. La transparencia sobre las implicaciones del stack es parte del servicio honesto.
Cómo migrar de WordPress a Next.js sin perder el SEO acumulado
La migración de plataforma es una de las operaciones más delicadas en el ciclo de vida de una web. Hecha bien, es transparente para Google y mejora el rendimiento. Hecha mal, puede costar meses de recuperación de rankings y tráfico.
Antes de migrar: ¿vale la pena?
No toda web en WordPress necesita migrar a Next.js. Antes de iniciar el proceso, hay que responder con honestidad a estas preguntas:
¿El rendimiento actual es el cuello de botella real del negocio? ¿El mantenimiento del WordPress actual consume tiempo y dinero desproporcionados? ¿El SEO está limitado por la plataforma o por contenido y autoridad? ¿El equipo tiene capacidad para adoptar el nuevo stack o para trabajar con quien lo mantenga?
Si la respuesta a la mayoría es "sí", la migración tiene sentido. Si el WordPress actual funciona bien y el problema real es otro (contenido, estrategia, conversión), migrar de plataforma no lo va a resolver.
Fase 1: Inventario y mapeo de URLs
El primer paso, siempre antes de tocar código, es hacer un inventario completo de todas las URLs del sitio actual. Crawl completo con Screaming Frog o herramienta similar. Exportar todas las URLs con su estado HTTP, metadatos, datos de tráfico de Search Console y posición media por keyword.
Con ese inventario, se construye el mapa de redirecciones 301: cada URL de origen mapea a su equivalente en el nuevo sitio. Si la estructura de URLs se mantiene igual, el proceso es trivial. Si cambia (que es frecuente cuando se pasa a Next.js y se reestructura la arquitectura de contenidos), el mapa tiene que ser exhaustivo.
Regla crítica: ninguna URL con tráfico orgánico o backlinks puede quedar huérfana. Las URLs que desaparecen sin redirección son tráfico y autoridad que se pierden permanentemente.
Fase 2: Migración de contenido
El contenido existente hay que migrarlo al nuevo sistema. Las opciones dependen del CMS elegido para Next.js:
Si se usa Sanity o Payload, el contenido se importa vía scripts usando la API de exportación de WordPress. Es un proceso técnico que requiere mapear campos de WordPress a los schemas del nuevo CMS. Los medios (imágenes, archivos) se migran al nuevo storage y se actualizan las referencias.
Si el contenido se gestiona como Markdown en repositorio (opción más sencilla para blogs puros), se exporta el contenido de WordPress y se transforma a MDX con herramientas automáticas, revisando manualmente los artículos críticos.
En ningún caso se debe hacer la migración de contenido a mano artículo por artículo si hay más de 50 piezas. Es un trabajo para scripts automatizados.
Fase 3: Implementación del nuevo sitio
El nuevo sitio en Next.js se construye con la arquitectura limpia, sin deuda técnica heredada. Es la oportunidad de limpiar: eliminar páginas que nunca tuvieron tráfico, consolidar contenido duplicado, mejorar la estructura de URLs si tiene sentido desde el punto de vista SEO.
Durante el desarrollo, el sitio vive en un subdominio o en Vercel con URL temporal, sin que Google lo indexe. El robots.txt en el entorno de staging bloquea el rastreo hasta que esté listo.
Fase 4: Validación antes del lanzamiento
Lista de verificación crítica antes de hacer el cambio de DNS:
- Todas las redirecciones 301 implementadas y verificadas con herramientas de testing.
- Sitemap XML generado correctamente con todas las URLs del nuevo sitio.
- Metadatos (title, description, og:image) correctos en todas las páginas principales.
- Datos estructurados JSON-LD validados con el Rich Results Test de Google.
- Core Web Vitals verificados en el entorno de staging: LCP, CLS e INP en verde.
- Formularios de contacto y conversión probados extremo a extremo.
- Google Analytics y Search Console configurados en el nuevo sitio.
- Hreflang correcto si el sitio es multilingüe.
Fase 5: Lanzamiento y monitorización post-migración
El cambio de DNS es el momento de la verdad. Tras el lanzamiento:
- Enviar el nuevo sitemap en Search Console inmediatamente.
- Solicitar rastreo de las páginas principales via "Inspeccionar URL" en Search Console.
- Monitorizar en tiempo real durante las primeras 48-72 horas: errores 404, tiempos de carga, indexación.
- Revisar Search Console diariamente durante las primeras 6-8 semanas buscando caídas de impresiones o clicks.
Una migración bien ejecutada no debería producir caídas de tráfico superiores al 5-10% temporal. Si la caída es mayor y persiste más de 2-3 semanas, hay que investigar: redirecciones rotas, problemas de indexación, canonicals incorrectos.
Lo que nadie te dice sobre las migraciones
El SEO acumulado no desaparece, se preserva o se pierde según cómo se hace la migración. La autoridad de dominio, los backlinks externos y el historial de indexación no están ligados a la plataforma, sino al dominio. Bien gestionados, se heredan íntegramente. La plataforma es solo el vehículo: lo que cuenta es que cada URL mantenga su equidad SEO o se transfiera correctamente.
El riesgo real no está en el cambio de plataforma, está en la ejecución. Una migración hecha con prisa, sin inventario completo, sin plan de redirecciones y sin monitorización puede costar más caro en pérdida de tráfico orgánico que todo el ahorro que se buscaba con el cambio de stack.
Matriz de decisión: cuál elegir según tu tipo de negocio en Tenerife
Para cerrar el análisis, aquí tienes una matriz de decisión directa. No es una recomendación genérica: está construida con el contexto del mercado canario, los tipos de negocio más comunes y el perfil real de los equipos locales.
| Tipo de negocio | Stack recomendado | Razón principal |
|---|---|---|
| Restaurante / bar | WordPress | Autonomía editorial, bajo coste, sin complejidad técnica |
| Hotel pequeño o casa rural | WordPress | Reservas con plugin, gestión accesible |
| Resort o cadena hotelera | Next.js | Integraciones PMS, rendimiento crítico, multi-idioma |
| Clínica dental o médica pequeña | WordPress | Gestión de contenido, formularios RGPD, bajo TCO |
| Centro médico multiespecialidad | Next.js o WordPress headless | Integración con sistemas de citas, flujo de conversión |
| Despacho de abogados local | WordPress | Web de servicios, blog básico, presupuesto ajustado |
| Portal jurídico o directorio legal | Next.js | SEO programático, escalabilidad de contenido |
| Tienda artesanal o local (catálogo de menos de 500 productos) | WordPress + WooCommerce | Estándar del sector, fácil de gestionar |
| Tienda con venta internacional | Shopify o Next.js + Shopify | Infraestructura sin mantenimiento, escalabilidad |
| Agencia inmobiliaria pequeña | WordPress | Plugin IDX, bajo coste |
| Portal inmobiliario con API Idealista | Next.js | Volumen de datos, filtros complejos, rendimiento |
| Agencia de marketing / comunicación | Next.js | Portafolio, rendimiento, imagen de marca tecnológica |
| Startup o producto SaaS | Next.js | Stack moderno, escalabilidad, iteración rápida |
| Blog de contenido puro sin e-commerce | Astro | Velocidad máxima, SEO técnico, coste hosting mínimo |
| Empresa de reformas o construcción local | WordPress | Galería, formulario de presupuesto, blog, accesible |
| Empresa de seguros con generación de leads | Next.js | Formularios complejos, integración CRM, rendimiento |
| Medio de comunicación canario | WordPress o Astro | Volumen editorial, pero Astro si priorizan velocidad |
Esta matriz no es dogma. Hay negocios turísticos pequeños que justifican Next.js por la marca. Hay startups que empiezan en WordPress y migran cuando crecen. El contexto siempre manda.
El criterio definitivo: las 5 preguntas para decidir
Después de todo este análisis, el marco de decisión se puede resumir en cinco preguntas concretas. Respóndelas con honestidad y tendrás una recomendación clara. Sin humo, sin teoría, sin preferencias de desarrollador.
1. ¿Quién va a editar el contenido y con qué frecuencia?
Si la respuesta es "mi equipo de marketing / mi becario / yo mismo, casi todas las semanas": WordPress. Pierdes más tiempo y dinero pagando un desarrollador para cada cambio del que te ahorras con un stack moderno.
Si la respuesta es "casi nunca, o solo yo que sí soy técnico": Next.js (o Astro). La autonomía editorial no compensa la complejidad.
Si la respuesta es "equipo editorial serio, pero de gran volumen y con workflow": WordPress o WordPress headless con Next.js.
2. ¿Cuánto tráfico esperas y qué picos puedes tener?
Tráfico estable y moderado (1.000-10.000 visitas/mes): cualquiera de los dos funciona. Decide por otros criterios.
Tráfico creciente con potencial viral o picos estacionales fuertes (campañas, apariciones en medios, estacionalidad turística, lanzamientos de producto): Next.js. Aguanta mejor sin tirar la web.
Tráfico muy alto y sostenido (100.000+ visitas/mes): Next.js en CDN global, o WordPress muy bien optimizado con Kinsta/WP Engine + Cloudflare Enterprise (y pagando por ello).
3. ¿Tu modelo de negocio depende del SEO orgánico a escala?
Sí, el SEO es el motor principal de mi negocio, y compito a nivel nacional o en sectores duros: Next.js. La ventaja técnica en Core Web Vitals, control de schemas, velocidad de indexación y capacidad de crear páginas programáticas pesa a tu favor cuando compites con medios grandes.
El SEO importa pero es local y de competencia media (ficha de Google, algunos keywords locales): cualquiera de los dos, con buena optimización. WordPress es suficiente.
SEO no es mi prioridad, el tráfico viene de ads, redes o referidos: WordPress por autonomía y menor coste inicial.
4. ¿Tienes o tendrás una tienda online?
Catálogo mediano, venta local o nacional básica (hasta 2.000 productos): WooCommerce sobre WordPress. Estándar, probado, económico.
Catálogo grande, venta internacional, equipo sin perfil técnico: Shopify. Externalizas toda la infraestructura y dejas de pelear con mantenimiento.
E-commerce custom, marca con ambición tecnológica, stack propio: Next.js con Shopify Hydrogen, Medusa, o integración a medida. Solo si hay equipo técnico.
No tengo tienda ni voy a tener: la pregunta no influye, pasa a la siguiente.
5. ¿Cuál es el presupuesto real total de 3 años, no solo el inicial?
Haz la cuenta real. Desarrollo + hosting x 36 + plugins x 3 + mantenimiento x 36 + contingencia de incidentes. Compara con el equivalente de la otra opción.
Si tu limitación es el desembolso del mes 1: WordPress entra antes en el presupuesto.
Si tu cuenta se calcula a 3 años y priorizas baja fricción operativa: Next.js compite o gana.
Si no puedes hacer la cuenta porque no tienes previsión: para, haz el ejercicio financiero antes de decidir el stack. Elegir tecnología sin saber el presupuesto a 3 años es cómo se pierden 5.000 EUR en un cambio de plataforma al año 2.
Árbol de decisión resumido
Juntando las cinco respuestas:
- Equipo editorial activo + SEO local + tienda mediana + presupuesto ajustado: WordPress (casi seguro con WooCommerce).
- SEO a escala + tráfico creciente + diseño que importa + presupuesto medio-alto: Next.js (con CMS headless si hay equipo editorial).
- Sitio de contenido puro + alto rendimiento + pocos editores + presupuesto medio: Astro (evaluar seriamente).
- Redacción grande + infraestructura WP existente valiosa + presupuesto alto: WordPress headless + Next.js.
- Startup tech / SaaS / producto digital con ambición técnica: Next.js sin discusión.
Lo que nadie te dice
La decisión técnica buena no es la que sigue la moda ni la que elige el desarrollador más ruidoso de LinkedIn. Es la que encaja con tu equipo, tu negocio, tu presupuesto real y tu plan a 3 años. En YAG, cuando un cliente nos pregunta, la respuesta honesta empieza por esas cinco preguntas, no por una recomendación de stack.
Preguntas frecuentes
¿Puedo migrar de WordPress a Next.js sin perder SEO?
Sí, si la migración se planifica bien. Incluye mapeo de URLs con redirecciones 301, conservación de estructura semántica, migración de contenidos y datos estructurados, reenvío de sitemap en Search Console y monitorización en las primeras 6-8 semanas. Hecho de forma casera, puedes perder rankings durante meses.
¿Next.js es más caro que WordPress a largo plazo?
Inicialmente, sí. A largo plazo, depende. Un WordPress bien mantenido con hosting gestionado y plugins premium tiene un coste mensual que, sumado, puede superar al de un Next.js alojado en Vercel con un CMS headless. La cuenta hay que hacerla a 3-5 años, no a 6 meses.
¿Puedo tener parte de mi web en WordPress y parte en Next.js?
Sí. Un patrón común es usar Next.js para la parte pública (landings de alto rendimiento, home, páginas clave) y WordPress como backend de contenidos (blog, noticias) consumido vía API REST o WPGraphQL. Es un híbrido que combina lo mejor de los dos mundos, pero requiere equipo técnico competente para mantenerlo.
¿Mi web actual en WordPress tiene algún valor si migro?
Mucho. El contenido, la autoridad de dominio acumulada y los enlaces externos se heredan en la migración. Lo que desaparece es la estructura técnica antigua. El SEO histórico es uno de los activos más valiosos que tienes y migrar bien es preservarlo.
¿Qué hago si mi desarrollador actual solo sabe WordPress y quiero Next.js?
Tienes dos opciones. La primera es buscar un nuevo proveedor con experiencia en Next.js para el proyecto nuevo. La segunda es un enfoque híbrido: mantener WordPress para el contenido existente mientras un nuevo equipo construye las partes nuevas en Next.js. En YAG trabajamos con ambos stacks y podemos hacer ese diagnóstico sin comprometerte a nada.
¿WordPress es malo para SEO?
No. WordPress es perfectamente capaz de posicionarse bien en Google. La herramienta en sí no es el problema. El problema es cuando el WordPress no está optimizado técnicamente, tiene un hosting lento, está lleno de plugins que ralentizan la carga o no tiene una estrategia de contenido sólida. Con buenas prácticas, WordPress puede alcanzar posiciones top en cualquier sector local.
¿No sabes cuál encaja en tu caso? En nuestra página de contacto puedes pedirnos un análisis gratis y te decimos con qué stack encaja mejor tu proyecto, con argumentos concretos.