De WordPress a una web a medida: cuándo conviene y qué implica

Cambia cuando el trabajo lo justifique

Una web a medida puede ser una buena inversión cuando la actual dificulta una y otra vez algo que tu negocio necesita hacer. Quizá los editores introducen la misma información en varios lugares. Quizá las consultas deben llegar a distintos equipos según unas reglas cada vez más difíciles de mantener. O quizá el catálogo ha crecido más allá de lo que permite la organización de las páginas.

En esas situaciones, puedes diseñar el contenido, las pantallas de edición y las conexiones en torno al trabajo real de las personas. Un editor podría introducir un evento una sola vez y ver su fecha correctamente en toda la web. El personal podría recibir una consulta con los datos pertinentes del cliente ya adjuntos. También puedes acordar qué cambios importan después, en vez de adaptar cada necesidad a los plugins disponibles.

Esas mejoras hay que diseñarlas, construirlas y probarlas. Sustituir WordPress, por sí solo, no las produce. Un sistema a medida mal planificado puede dejarte un editor con menos funciones y una factura de mantenimiento mayor.

Empieza describiendo el problema en términos de negocio: qué les cuesta hacer a las personas, con qué frecuencia ocurre, cuánto tiempo o trabajo se pierde y cómo sería un resultado satisfactorio. Después compara las formas de conseguirlo. Elige la opción menos exigente que cumpla el requisito y que alguien pueda seguir operando.

¿Qué tipo de cambio necesitas?

La expresión «una web nueva» puede referirse a proyectos muy diferentes. Aclara qué vas a contratar antes de comparar precios.

Cambiar de proveedor puede bastar si la web en sí te sirve y el problema está en cómo se gestiona. Nuestra guía para trasladar una web sin rehacerla trata esa decisión por separado.

Usar WordPress solo para gestionar el contenido, lo que se conoce como «headless WordPress», es una opción real: la API REST de WordPress permite que otras aplicaciones trabajen con el contenido según los permisos de acceso. Eso no significa que los datos o el comportamiento de todos los plugins estén disponibles mediante esa API. La nueva parte visible puede seguir dependiendo de la estructura antigua del contenido y de las reglas de los plugins. Pregunta qué resuelve esta opción, qué permanece en WordPress y quién mantiene la conexión.

Cuándo conviene conservar WordPress

Si tu equipo publica con comodidad, las funciones necesarias van bien y los cambios son razonablemente sencillos, mantener WordPress puede ser lo más sensato. Las necesidades habituales de publicación no justifican por sí mismas encargar una sustitución.

Incluso una web incómoda puede tener un problema reparable. Las páginas lentas pueden requerir revisar las imágenes, el alojamiento, las consultas a la base de datos o una función concreta. Un editor difícil puede mejorar con una estructura de contenido más clara o un mejor desarrollo sobre WordPress. Examina los problemas y sus consecuencias en lugar de juzgar la web por el número de plugins.

Compara también las plataformas estándar que encajen. Si una ya cubre bien tus reservas, tu tienda o tus publicaciones, configurarla y hacer un traslado cuidadoso puede exigir menos trabajo continuo que un sistema a medida.

Tus recursos también importan. Alguien debe decidir qué ha de hacer un sistema a medida, comprobar que lo hace y pagar su mantenimiento. Puedes contratar la atención técnica, pero tu negocio seguirá necesitando a una persona que tome decisiones y acepte el trabajo. Si no dispones de esa capacidad, una plataforma existente que puedas gestionar puede encajar mejor.

Averigua qué hace realmente la web

El número de páginas es un punto de partida. El alcance del traslado depende del contenido, las relaciones y las tareas que hay detrás de esas páginas.

Recorre la web con quienes la usan y la gestionan. Incluye también lo que el visitante no ve:

• Contenido: páginas, artículos y otros tipos de contenido; categorías y etiquetas; autores y fechas de publicación; traducciones y relaciones entre ellas.
• Archivos: imágenes originales y otros ficheros, pies de foto, textos alternativos, adjuntos y lugares donde se usa cada elemento.
• Cómo se encuentra la información: menús, búsqueda, filtros, patrones de URL, redirecciones existentes, títulos y descripciones SEO, y reglas sobre qué páginas deben indexar los buscadores.
• Tareas del visitante: formularios, confirmaciones, entrega de correos, inicio de sesión, acceso a cuentas y permisos.
• Trabajo conectado: sistemas de clientes o contabilidad, herramientas de envíos, analítica, importaciones, exportaciones, tareas programadas y otros procesos en segundo plano.

Decide si cada elemento debe conservarse, sustituirse o retirarse. Anota quién puede tomar esa decisión y cómo sabrás que el resultado funciona. Un plugin abandonado quizá se pueda eliminar; otro puede estar enviando discretamente las consultas de las que depende tu equipo comercial.

Si vendes productos, membresías o reservas, define ese trabajo como un alcance propio. Productos, pedidos, derechos de acceso de clientes, renovaciones, disponibilidad y proveedores de servicios conectados requieren decisiones explícitas. Una migración de contenido no resuelve cómo continuará una suscripción activa o una reserva existente. Hay que investigar los sistemas y proveedores concretos antes de prometer que se pueden trasladar.

Diseña el editor con tanto cuidado como las páginas públicas

Puedes seguir teniendo un sistema de administración aunque abandones WordPress. Define lo que tu equipo debe poder hacer con él. Un desarrollo a medida no incluye automáticamente todas las funciones a las que están acostumbrados los editores.

Decide qué contiene cada tipo de contenido. Un evento podría tener fecha, lugar, enlace de reserva y artículos relacionados. Dar a cada dato su propio campo facilita reutilizarlo y comprobarlo. También exige acordar cómo se tratan las excepciones: un evento de varios días, un lugar aún desconocido o un enlace de reserva añadido más adelante.

Acuerda quién puede crear, aprobar y publicar contenido. Incluye borradores, programación, vista previa, historial de versiones, gestión de archivos, menús, búsqueda y edición de redirecciones cuando tu equipo los necesite. Decide cómo corregirán los editores un error y si podrán deshacer un cambio.

Antes de aceptar el editor, pide a usuarios reales que completen tareas representativas. Que alguien prepare un artículo, añada una imagen y su texto alternativo, consulte la vista previa en un móvil, programe la publicación, corrija un error y encuentre un contenido antiguo. Observa dónde necesitan ayuda. Una demostración atractiva aporta menos que ver a tu equipo terminar una tarea normal.

¿Qué se traslada y qué hay que reconstruir?

WordPress tiene una herramienta de exportación. Su formato de exportación WXR contiene contenido documentado como entradas, páginas, tipos personalizados, comentarios, campos, categorías y etiquetas. Puede aportar datos de origen valiosos. No es una copia funcional de toda la web.

El equipo encargado del traslado debe revisar qué guarda realmente tu instalación: base de datos, archivos subidos, exportaciones, respuestas de la API y registros propios de plugins. Conserva una copia original segura antes de transformar nada. Identifica dónde está cada campo necesario y cómo se relacionan los registros.

Mapear los datos significa decidir dónde irá cada valor antiguo en el nuevo sistema. Cada artículo debe conservar su autor correcto. Una categoría puede convertirse en un tema. Un enlace a una historia relacionada debe apuntar a su versión nueva. Acordad cómo tratar los valores ausentes y los duplicados, en vez de dejarlos desaparecer sin aviso.

Las imágenes necesitan su propio traslado y comprobaciones. Confirma que los archivos existen en la nueva ubicación, siguen asociados al contenido correcto y cargan en tamaños adecuados. Actualiza las URL de imágenes y descargas insertadas donde sea necesario. Ver una imagen en una página trasladada no basta si todavía la sirve la web antigua que piensas cerrar.

También hay que revisar la disposición del contenido. WordPress explica que los bloques pueden guardar código de marcado y atributos, mientras que los bloques dinámicos pueden guardar un marcador de posición para generar el resultado más tarde. Por eso, un artículo copiado puede contener instrucciones que el sistema nuevo no entiende. Los maquetadores de páginas tienen sus propias estructuras y necesitan una revisión aparte.

La solución puede ser convertir el contenido en componentes admitidos, reconstruir diseños seleccionados o simplificar páginas antiguas con aprobación editorial. Copiar el HTML visible puede conservar la apariencia en ciertos casos, pero no demuestra que los editores puedan actualizar el resultado correctamente. Acordad tanto el resultado público como su forma de edición.

Un ejemplo con una pequeña editorial

Imagina una editorial que traslada una web de WordPress. Es un ejemplo hipotético, no el resultado de un cliente. Su artículo de prueba tiene un autor, una imagen principal, dos noticias relacionadas y un formulario de consultas publicitarias.

El título y el texto del artículo se importan bien. Después, el equipo comprueba que se han conservado el autor y la fecha de publicación, que las noticias relacionadas conducen a las páginas correctas y que la imagen se ha trasladado con su pie y su texto alternativo. Un editor abre el artículo, cambia la introducción y consulta la vista previa. Así se prueban juntos el contenido y la forma de editarlo.

El formulario es un trabajo aparte. Su sustituto debe recoger la información acordada, guardarla o enviarla al destino previsto y mostrar al visitante una confirmación útil. Alguien hace una prueba y comprueba que la consulta se ha recibido de verdad. Que el formulario estuviera en la página antigua no significa que su comportamiento haya viajado con el artículo.

La editorial ya tiene pruebas sobre cuatro cosas: un artículo, su imagen, una tarea de edición y una consulta del visitante. Repetir ese método con las distintas estructuras de la web da una base mucho mejor para definir el alcance que decir «podemos importar las entradas».

Conserva las URL útiles y planifica los cambios

Al sustituir un sistema de contenido, a menudo puedes conservar el dominio y las rutas actuales de las páginas. Pídelo expresamente cuando esas direcciones sigan siendo útiles. Cambiar el gestor de contenidos no exige un dominio nuevo ni un patrón nuevo de URL.

Cuando una dirección deba cambiar, relaciona la antigua con su sustituta adecuada y prueba la redirección. Evita enviar todas las páginas antiguas a la portada. Un artículo retirado, un tema fusionado y un producto trasladado requieren decisiones acordes con lo que el visitante buscaba.

Las indicaciones de Google para traslados con cambios de URL tratan la correspondencia entre direcciones, las redirecciones permanentes y las comprobaciones de URL canónicas, enlaces internos, imágenes, versiones lingüísticas y mapas del sitio. La URL canónica indica a los buscadores qué versión de una página prefieres. Asegúrate de que señale a la nueva página pública, no a un sitio de pruebas ni a la dirección antigua.

Revisa títulos y descripciones, reglas de indexación, rutas de los distintos idiomas y enlaces en todo el contenido. Gestiona bien las restricciones del entorno de pruebas al lanzar la web: el sitio de prueba debe seguir siendo privado cuando corresponda y las páginas destinadas al público deben ser accesibles e indexables.

La herramienta de Google Cambio de dirección se refiere a un traslado de dominio o subdominio. Sustituir WordPress manteniendo las mismas direcciones no requiere utilizarla por sí solo.

Las posiciones en buscadores pueden fluctuar después de cambios importantes. Acordad qué vais a vigilar, quién investigará páginas ausentes o cambios inesperados de tráfico y cómo se harán las correcciones. Nadie puede convertir responsablemente un plan de migración en una promesa de no perder posiciones o de crecer automáticamente.

Acordad qué debe funcionar antes del lanzamiento

Define las pruebas de aceptación en torno a los trabajos que la web debe cumplir. Compara contenido, imágenes y enlaces y después prueba el comportamiento real. Un formulario debe entregar el mensaje al lugar correcto. La búsqueda debe encontrar elementos representativos. Un usuario autorizado debe poder iniciar sesión y otro sin permiso debe ser rechazado. Los editores deben poder terminar las tareas acordadas.

Si el alcance incluye compras, reservas o integraciones, prueba también esos recorridos y sus excepciones importantes. Una pantalla que parece correcta es solo parte del resultado si otro sistema aún debe recibir el registro.

Utiliza un entorno de pruebas protegido. Limita el acceso a datos privados e impide que las pruebas envíen mensajes reales a clientes o activen acciones no deseadas en los sistemas en producción. Acordad qué datos se pueden usar y cómo se tratarán las copias de prueba.

Planifica qué sucederá con los cambios realizados mientras se prepara la nueva web. Podríais detener brevemente las publicaciones y trasladar los últimos cambios, o hacer un traslado final de los registros añadidos desde la primera importación. Indica qué sistema contiene el registro válido en cada fase. Si no, un editor puede corregir una noticia en un lugar mientras un visitante envía una consulta en otro.

Nuestra guía sobre el funcionamiento paralelo de sistemas antiguos y nuevos durante una sustitución examina con más detalle esas decisiones de responsabilidad y transición.

Acordad también un plan realista para volver atrás. Las indicaciones de WordPress sobre copias de seguridad distinguen la base de datos y los archivos necesarios para recuperar el servicio. Tener copias es un punto de partida; el equipo aún debe demostrar que puede restaurar el servicio necesario. Nuestro artículo sobre qué debe recuperar realmente una copia de seguridad web explica qué comprobar.

Volver atrás se complica cuando la nueva web ya ha recibido consultas, pedidos o cambios, o ha enviado instrucciones a otro servicio. Esos registros y acciones deben conciliarse. No se puede suponer que restaurar la base de datos de ayer conserve el trabajo de hoy. Define las condiciones para volver atrás y quién se ocupará de ello antes del lanzamiento.

¿Qué determina el coste y el plazo?

La cantidad de contenido importa, pero su variedad puede importar tanto como ella. Miles de artículos con una estructura uniforme pueden ser más previsibles que una colección menor de páginas construidas una a una con comportamientos especiales.

Un presupuesto comparable debe explicar las suposiciones sobre el trabajo:

• ¿Qué estructuras de contenido, bloques personalizados y registros de plugins se investigarán y convertirán?
• ¿Qué integraciones, cuentas, transacciones e idiomas están incluidos?
• ¿Cuánto cambiará el diseño y cuánto contenido se limpiará?
• ¿Qué funciones de edición, permisos y formación hacen falta?
• ¿Qué pruebas, apoyo durante el lanzamiento, medidas de continuidad y atención posterior están incluidos?

Reserva también tiempo de tu equipo. Tendrá que facilitar accesos, responder preguntas, decidir qué retirar, ordenar el contenido, probar el editor y aceptar el resultado. Si falta quien debe decidir, el trabajo puede detenerse aunque el desarrollo esté listo para continuar.

Pide a los proveedores que separen el trabajo conocido de lo que aún hay que investigar. Una conversión de prueba de una página difícil o de una función dependiente de un plugin puede resolver una duda costosa antes de comprometer toda la construcción. Un precio cerrado basado en una exportación sin examinar puede ocultar suposiciones muy distintas entre proveedores.

Compara el coste de operar cada opción además del de construirla. Incluye alojamiento, licencias, servicios externos, actualizaciones, copias de seguridad, seguimiento, asistencia y cambios posteriores. Mantener WordPress cuesta dinero; el software a medida también. La comparación útil es lo que aporta cada camino durante el tiempo que esperas usarlo, con las responsabilidades claras.

¿Quién se ocupará del sistema a medida?

Acuerda esto al elegir la solución. Una web a medida sigue dependiendo de frameworks, bibliotecas, alojamiento y servicios conectados. Hay que cuidar esas dependencias. La seguridad sigue requiriendo trabajo: las propias indicaciones de seguridad de WordPress describen cómo reducir riesgos y repartir responsabilidades, y cambiar de plataforma no elimina la necesidad de asignarlas.

Incluye en el acuerdo las actualizaciones, copias de seguridad, supervisión y ayuda ante incidentes. Indica quién recibe una alerta, quién puede actuar, cómo se notifican los problemas urgentes y qué cubre exactamente la asistencia. Establece también un proceso para mejoras normales, además de las averías.

Aclara el acceso y la entrega: cuentas de alojamiento y despliegue, credenciales, exportación de datos, documentación, licencias y acceso al repositorio o al código fuente cuando corresponda. Tener acceso al código fuente no transfiere por sí solo los derechos de autor ni demuestra que otro proveedor pueda operar el sistema. Una entrega útil también explica cómo desplegarlo, recuperarlo y gestionar sus dependencias.

Los especialistas de Google Acacio Cruz y Ashish Bhambhani describen la documentación, la formación y el traspaso de la responsabilidad operativa en su explicación sobre la preparación de un servicio. Una pequeña empresa no necesita la estructura de equipos de Google para aplicar la idea de fondo: quienes asumen la responsabilidad necesitan conocimientos y acceso para hacer el trabajo.

LINK-V desarrolla webs y sistemas a medida y ofrece migraciones, integraciones, diseño y mantenimiento continuo. La construcción, los derechos, la entrega y el cuidado posterior deben acordarse para tu proyecto. Puedes consultar el desarrollo a medida o los servicios individuales según el trabajo que necesites.

Qué preparar para la primera conversación

No hace falta que llegues con una especificación técnica. Trae suficiente información para mostrar el problema:

• Tu web actual y quién tiene acceso a su administración, alojamiento, dominio y servicios conectados.
• La dificultad recurrente, un ejemplo y lo que quieres que las personas puedan hacer en su lugar.
• El contenido, las funciones y las direcciones útiles que deben conservarse, además de lo que quieres retirar.
• Los editores y otros usuarios que deberían ayudar a probar la nueva web.
• Los servicios conectados, las fechas comerciales o de publicación importantes y cuánto tiempo puede tolerar tu negocio una interrupción.
• Tus preguntas sobre costes, derechos, acceso, asistencia y cambios futuros.

Así, la siguiente conversación tendrá un propósito práctico: determinar si basta con mejorar la web actual, identificar las incógnitas y acordar qué debe demostrarse antes de encargar una sustitución.