Respuesta breve
Los arreglos web son una lista concreta de cambios en un sitio que ya está en marcha: errores corregidos, páginas más rápidas, una versión móvil mejor, bloques nuevos e integraciones. Se diferencian del rediseño, que rehace todo el sitio, y del soporte, que dura mes a mes. Describe cada problema con los pasos para repetirlo, haz una copia antes y redirige cada dirección que cambie.
Arreglos web: cambiar un sitio que ya funciona
Los arreglos web son cualquier cambio en un sitio que ya está publicado y trae solicitudes: reparar un formulario roto, acelerar una página lenta, añadir una sección al menú. El sitio no empieza de cero. Conserva su dirección, su contenido y su historial en el buscador. El riesgo es que cada cambio cae sobre un sistema vivo que los clientes usan en ese mismo momento.
Un rediseño cambia el aspecto y la organización de todo el sitio; suele tocar todas las plantillas y a menudo la estructura de las páginas. El soporte, que muchos llaman mantenimiento, es un acuerdo permanente: alguien vigila el sitio cada mes, instala actualizaciones, guarda copias y reacciona cuando algo falla. Crear desde cero significa un sitio nuevo que sustituye al anterior. Los arreglos quedan en medio: una lista definida de cambios, hecha una vez, con un resultado que se puede comprobar.
Las fronteras no son nítidas. Una lista larga de cambios puede convertirse sin ruido en un rediseño, y los encargos pequeños de cada mes ya son soporte. Un arreglo se juzga por si el problema concreto desapareció, un rediseño por si todo el sitio funciona mejor, y el soporte por la rapidez de respuesta.
Tareas típicas, de formularios rotos a velocidad y móviles
El encargo más común es un error: un botón que no hace nada, una página que devuelve un fallo, un precio que aparece mal, un formulario que envía solicitudes a ninguna parte. Ojo con los formularios: un fallo silencioso ahí se parece mucho a una semana tranquila. Enviar una solicitud de prueba y comprobar que llega al correo, al CRM o al WhatsApp del equipo es uno de los arreglos web más baratos y útiles que existen.
La velocidad es el segundo gran grupo. web.dev, el sitio de Google para desarrolladores, describe tres Core Web Vitals con un objetivo para cada una: el contenido principal debe aparecer en 2,5 segundos como máximo (Largest Contentful Paint), la página debe responder a un toque o clic en 200 milisegundos (Interaction to Next Paint) y el diseño no debe moverse más de 0,1 en la escala de Cumulative Layout Shift. Recomienda medir en el percentil 75 de las cargas, por separado en móvil y en ordenador. Lo habitual: imágenes más ligeras, menos scripts pesados y medidas fijas para los bloques.
La versión móvil es el tercero. Google Search Central indica que Google usa la versión móvil del contenido de un sitio para indexarlo y posicionarlo, y que para la indexación solo cuenta el contenido que se muestra en el sitio móvil. Un texto oculto en el teléfono, o una tabla que no cabe en la pantalla, es por tanto un problema de búsqueda además de uno de uso. El resto de la lista es conocido: títulos y descripciones, enlaces rotos, un bloque nuevo en la portada, un pago en línea, un chat, un catálogo para un marketplace.
Cómo pedir un arreglo que un desarrollador pueda ejecutar
Una buena solicitud responde a cuatro preguntas. Qué falla, en una frase. Dónde exactamente: la dirección de la página, el dispositivo, el navegador. Cómo repetirlo: los pasos desde que se abre la página hasta el momento del fallo. Y cómo sabrás que está resuelto: el resultado que esperas ver. Una captura o una grabación corta vale más que un párrafo.
Separa los errores de los deseos. «El formulario no envía» es un error con un final claro. «Haz la portada más moderna» es un deseo que necesita un brief de diseño antes de que nadie pueda presupuestarlo. Pon primero los problemas que cuestan solicitudes o dinero y al final los estéticos. Una lista numerada, con un problema por línea, permite al proveedor valorar cada punto por separado y a ti aprobarlos uno a uno.
Accesos y una copia de seguridad reciente antes de tocar nada
El trabajo necesita accesos: el panel del CMS o del constructor, el hosting o el servidor, el registrador del dominio y, a veces, la analítica y el servicio de correo que envía los avisos de los formularios. Dale al proveedor cuentas propias en lugar de tu contraseña. Los cambios grandes son más seguros en una copia del sitio, una versión de prueba donde un error no cuesta nada, y pasan al sitio real solo tras revisarlos.
La segunda condición es una copia de seguridad. La documentación de WordPress divide la copia en dos partes, la base de datos y los archivos, y dice que hacen falta ambas para restaurar un sitio típico. Propone copias semanales para sitios pequeños y diarias para los que tienen mucha actividad, siempre una antes de actualizar, y guardar al menos de tres a cinco copias recientes en lugares distintos, como el servidor del hosting, la nube y un ordenador local. El consejo está escrito para WordPress, pero la lógica sirve para cualquier plataforma: antes de cambiar algo, asegúrate de que hay un camino de vuelta.
Conservar posiciones cuando los arreglos cambian direcciones
La mayoría de los cambios no toca las direcciones de las páginas, y los buscadores apenas los notan. El riesgo aparece cuando se renombran páginas, se fusionan secciones o el sitio pasa a otro dominio o a HTTPS. La guía de Google Search Central sobre migraciones empieza por un mapa: la lista de las URL antiguas con la URL nueva de cada una, construida a partir de los sitemaps, los registros del servidor y el CMS.
Ese mapa se convierte en redirecciones. Google pide redirecciones permanentes en el servidor, como la 301 o la 308, que lleven cada URL antigua directamente a su destino final sin cadenas, y aconseja mantenerlas en general durante al menos un año. Su página sobre redirecciones explica la diferencia: tras una permanente, Google trata el destino como dirección canónica; tras una temporal, como la 302 o la 307, la dirección antigua puede seguir en los resultados. Las redirecciones con JavaScript aparecen allí como último recurso, porque Google podría no verlas si falla el renderizado.
Ni siquiera una migración cuidadosa pasa inadvertida. La misma guía advierte de que habrá fluctuaciones temporales en el posicionamiento mientras Google vuelve a rastrear el sitio. Los enlaces internos deben apuntar a las nuevas direcciones, el sitemap debe actualizarse y cada página nueva debe llevar una etiqueta canónica que apunte a sí misma.
Actualizar el CMS y los plugins sin romper el sitio
Las actualizaciones son el arreglo que nunca termina. La documentación de WordPress explica que desde la versión 3.7 la mayoría de los sitios instala sola, en segundo plano, las actualizaciones menores y de seguridad, mientras que las versiones principales siguen necesitando que alguien pulse el botón de actualizar. También advierte de que una actualización sustituye los archivos del núcleo, así que cualquier cambio hecho directamente en ellos se pierde. Su procedimiento manual desactiva los plugins antes y los reactiva después. Un cambio escrito en el núcleo, y no en un tema o un plugin, tiene fecha de caducidad.
La seguridad sigue la misma línea. OWASP presenta su Top 10 como el estándar de referencia sobre los riesgos más críticos de las aplicaciones web; la edición vigente es la de 2025. Su tercera categoría, fallos en la cadena de suministro de software, cubre roturas o compromisos al construir, distribuir o actualizar software, y procede de una entrada antigua sobre el uso de componentes con vulnerabilidades conocidas. Entre las medidas que enumera OWASP están eliminar dependencias, funciones y componentes que no se usan, actualizar a tiempo según el riesgo y desplegar por etapas en lugar de en todas partes a la vez.
Cuándo rehacer el sitio sale más barato que seguir arreglando
Arreglar tiene sentido mientras la base está sana. Las señales de que ya no lo está se ven pronto: cada cambio rompe algo en otra parte, nadie se atreve a actualizar el CMS porque el código se editó a mano, la plantilla o la plataforma ya no tienen soporte, la versión móvil es un sitio aparte que nadie cuida y los presupuestos de las tareas pequeñas no dejan de crecer. Cada arreglo nuevo rinde entonces menos que el anterior.
Una prueba práctica es sumar lo que costará el próximo año de cambios y compararlo con el precio de un sitio nuevo que resuelva los mismos problemas. Si la lista toca la mayoría de las plantillas, o el negocio ha cambiado tanto que la estructura del sitio ya no encaja, un rediseño o un sitio nuevo suele ser la respuesta honesta. Si los problemas son locales y la plataforma está viva, arreglar cuesta menos y conserva el historial en el buscador.
Qué preparar antes de encargar arreglos web
Mucho se puede hacer sin proveedor. Textos, fotos, precios y bloques sencillos en un constructor o un CMS están pensados para que los edite el propietario. El código, la configuración del servidor, las redirecciones, las integraciones y todo lo que toque pagos o datos personales es mejor dejarlo a quien hace ese trabajo a diario.
Antes de encargar, prepara la lista de problemas redactada como se ha descrito, las cuentas de acceso, la prueba de que existe una copia reciente y las cifras de analítica que muestran qué páginas traen solicitudes y cuáles van lentas. Con todo eso en una hoja, cualquier estudio, VITON13 incluido, puede valorar cada punto por separado, y tú eliges qué arreglos web van primero.
Lista práctica
- Envía una solicitud de prueba por cada formulario y comprueba que llega al correo, al CRM o al chat.
- Escribe cada problema en su propia línea: página, dispositivo, pasos para repetirlo y resultado esperado.
- Haz una copia reciente de los archivos y de la base de datos y guárdala en más de un lugar.
- Antes de renombrar páginas, haz la lista de direcciones antiguas y nuevas y una redirección para cada una.
- Tras cada actualización o arreglo, abre las páginas clave en el móvil y envía otra solicitud de prueba.
Preguntas frecuentes
¿En qué se diferencian los arreglos web del soporte continuo?
Los arreglos son una lista puntual de cambios cuyo resultado se comprueba punto por punto. El soporte es un acuerdo permanente: actualizaciones, copias y respuesta a las averías mes tras mes. Los arreglos pequeños encargados cada mes acaban siendo soporte.
¿Arreglar una web puede empeorar su posicionamiento?
Los cambios que mantienen las direcciones de las páginas casi nunca lo hacen. Las páginas renombradas, las secciones fusionadas o un dominio nuevo necesitan redirecciones permanentes desde cada dirección antigua, y Google avisa de que las posiciones pueden oscilar un tiempo incluso tras una migración cuidadosa.
¿Puedo actualizar yo los plugins de WordPress antes de encargar arreglos?
Puedes, si antes haces copia de los archivos y de la base de datos y después revisas las páginas principales. Si alguien editó directamente archivos del núcleo o un tema antiguo, que lo mire primero un desarrollador, porque la actualización puede borrar esos cambios.
¿Qué accesos necesita un desarrollador para arreglar una web?
Normalmente el panel del CMS y el hosting o el servidor; a veces el registrador del dominio, la analítica y el servicio que envía los correos de los formularios. Crea cuentas propias para el proveedor y así podrás retirar el acceso al terminar.
¿Cómo decido entre arreglar el sitio actual o hacer uno nuevo?
Compara un año de cambios previstos con el precio de un sitio nuevo que resuelva lo mismo. Si cada cambio rompe otras partes, la plataforma ya no tiene soporte o hay que rehacer la mayoría de las plantillas, lo nuevo suele salir mejor.