Un presupuesto útil de reparación WordPress empieza con una incidencia concreta y termina con una forma acordada de comprobar el trabajo. Entre ambos puntos están los accesos, el diagnóstico, la corrección, la recuperación y esa pregunta que siempre acaba llegando: ¿qué incluye exactamente este precio?
Si vas a encargar una reparación en 2027, utiliza este briefing para comparar el mismo trabajo entre proveedores. Es una estructura original de contratación y aceptación. El ejemplo es ficticio: no describe un cliente, una oferta cerrada ni la promesa de resolver cualquier avería en una sesión.
Ya existe una guía para recopilar evidencias de hosting antes de pedir una reparación. Úsala para preparar el paquete técnico. Aquí concretamos el encargo comercial: qué pides, quién puede autorizarlo y qué permitirá darlo por terminado.
Empieza por la tarea del negocio que ha dejado de funcionar
«La web está rota» puede significar caída pública, administrador en blanco, notificación perdida o fallo en un navegador. Aporta la URL pública y la tarea que intentaba completar la persona afectada.
Explica a quién afecta y qué sigue funcionando. Una portada en caché dice poco sobre si el editor puede guardar o una consulta nueva llega a ventas. Separa observación y teoría: «empezó después de actualizar» es un dato útil, pero todavía no demuestra la causa.
Describe la consecuencia con información que puedas sostener: consultas sin verificar, equipo sin poder publicar o clientes bloqueados en un paso concreto. Si se desconoce cuántas operaciones están afectadas, déjalo indicado en vez de convertir una estimación en facturación perdida.
Delimita la cronología de la incidencia
Registra cuándo se detectó, el último uso correcto conocido y los cambios recientes de publicación, hosting, DNS o configuración. Incluye zona horaria. Para comparar registros, el técnico necesita un intervalo utilizable, no «ayer en algún momento».
Anota también intentos de solución, quién los hizo y qué ocurrió. Desactivar un plugin, comenzar una restauración desde hosting o purgar caché desde una agencia cambia la evidencia disponible. Conserva un registro compartido mientras la incidencia siga abierta.
Si participan varios equipos, acuerda quién coordina. Hosting, desarrollador e integración pueden controlar tramos diferentes. Conviene evitar que todos cambien el mismo sistema sin ver las intervenciones de los demás.
Separa diagnóstico, reparación y recuperación de registros anteriores
Pregunta si el presupuesto incluye identificar la causa, aplicar una corrección acotada o ambas cosas. Cuando el diagnóstico sea una fase con precio propio, concreta su entrega y qué autorización necesita el trabajo posterior.
Restaurar el comportamiento futuro y recuperar registros ya afectados pueden ser encargos distintos. El formulario puede volver a entregar mientras siguen pendientes las consultas anteriores. La web puede regresar tras una restauración y necesitar otra decisión para el contenido creado después de la copia.
Escribe estos límites en la propuesta. Un alcance inicial pequeño puede ser útil si lo pendiente tiene responsable y siguiente decisión. Una reparación bien delimitada se gestiona mejor que una promesa general de arreglarlo todo.
Compara el alcance antes de comparar los totales
| Partida | Qué debe identificar la propuesta | Límite de autorización |
|---|---|---|
| Diagnóstico | Recorrido afectado, evidencia necesaria y resultado que se entrega | Qué ocurre si la causa sigue sin resolverse |
| Preparación de recuperación | Copia disponible, método de restauración y datos recientes afectados | Quién aprueba restaurar o restringir temporalmente |
| Corrección | Componente o configuración incluidos y sus dependencias | Qué hallazgos requieren otro presupuesto |
| Verificación | Tarea original, condición del visitante y resultado esperado | Quién acepta la evidencia |
| Traspaso | Registro de cambios, pendientes y cierre de accesos | Quién se ocupa de cada continuación |
Completa las mismas filas para cada proveedor. Un total menor puede cubrir solo diagnóstico; otro puede incluir intervención y repetición de pruebas. Solo se pueden comparar cuando queda visible qué compra cada importe.
Identifica sistemas y responsables de los accesos
Indica CMS, hosting o plataforma gestionada, integraciones relevantes y quién las controla. La consulta pública necesita ese inventario, no contraseñas, claves privadas ni exportaciones de clientes.
Después de acordar el alcance, prepara el acceso necesario mediante el proceso seguro elegido. Define finalidad, responsable y retirada o revisión prevista. Un usuario WordPress puede quedarse corto para un problema de hosting; un acceso amplio al servidor puede sobrar para un cambio de contenido.
Haz visibles las dependencias externas. Si nadie puede acceder al correo o a DNS, la propuesta debe reflejar el límite y cómo obtener la evidencia pendiente. No se puede verificar un sistema que el responsable de la intervención no puede inspeccionar.
Acuerda los límites de recuperación antes de intervenir
Pregunta qué copia existe, qué contiene y cómo se restauraría. Copiar archivos y respaldar la base de datos protege elementos diferentes. Comprueba fecha y registros que podrían desaparecer si se volviera a un estado anterior.
Decide quién puede autorizar esa consecuencia. Pedidos, consultas, reservas y cambios editoriales posteriores a la copia necesitan atención antes de una vuelta atrás general. Quien autoriza debe conocer ese límite.
El técnico debe conservar la evidencia relevante y acotar la intervención a lo que respalda el diagnóstico. Si hace falta depurar, la documentación de depuración de WordPress —en inglés— es la referencia técnica. Entorno de pruebas, registros y exposición en producción deben encajar con el trabajo acordado.
Haz visibles el estado y el responsable
Una reparación necesita dueño y estados comprensibles: pendiente de evidencia, diagnóstico en curso, esperando autorización, corrección aplicada, verificación pendiente o cerrado. Elige los que representen vuestro proceso y explica quién mueve el trabajo entre ellos.
La referencia ayuda a hablar de estado y asignación. El acuerdo necesita además persona responsable, canal de comunicación y proceso de autorización reales. Marcar un ticket resuelto es una acción administrativa; la verificación acordada sostiene el cierre del trabajo.
Fija un ritmo de comunicación que facilite decisiones
Acuerda cuándo recibirás novedades y qué deben incluir: observación actual, acción, resultado, bloqueo y siguiente decisión. La frecuencia depende de urgencia y trabajo. Obtén un acuerdo concreto en vez de deducir tiempos de una descripción general del servicio.
Asigna quién aprueba ampliar diagnóstico, cambiar un sistema externo o aplicar una restricción temporal. Guarda esas decisiones en un lugar común para que quien recupera el servicio vea la última situación autorizada.
Una actualización útil puede explicar que la causa sigue abierta e identificar la siguiente comprobación. La ausencia de otra queja todavía no demuestra que haya funcionado una corrección.
Define la aceptación alrededor de la tarea original
Escribe la prueba antes de intervenir. Para una pantalla blanca pública, incluye contenido previsto bajo la condición del visitante afectado. Para un fallo del administrador, incluye la tarea real de edición o gestión.
La guía de pantalla blanca y la de administrador en blanco con web pública funcionando ayudan a separar esos límites. Si falla el dominio mientras responde el servidor, utiliza el diagnóstico de IP frente a dominio.
Registra resultado observado, fecha, entorno, URL y exclusiones pendientes. Añade comprobaciones relevantes de lo que podría haberse afectado sin convertir silenciosamente el encargo en una auditoría de toda la web.
Ejemplo de briefing: la página carga, pero no se verifica una consulta
Es un ejemplo ficticio de contratación. Dale una referencia como REPAIR-BRIEF-001 y conserva como pendiente toda prueba aún no realizada. Sirve para convertir incertidumbre en trabajo acotado.
Síntoma observado: carga la página de contacto, pero el responsable no puede confirmar recepción de una consulta de prueba autorizada. El briefing recoge URL, hora y resultado visible. No presupone un fallo del proveedor de correo.
Alcance de diagnóstico: seguir una referencia controlada por el almacenamiento admitido, proveedor de notificación y destino previsto. El técnico identifica accesos. CRM queda fuera de la primera fase hasta que esté disponible su responsable.
Decisión de reparación: presentar fallo identificado y corrección propuesta antes de ampliar lo autorizado. Definir por separado la revisión de consultas anteriores cuando exista una fuente recuperable.
Aceptación: repetir una prueba nueva permitida bajo las mismas condiciones relevantes, confirmar etapas acordadas y señalar la dependencia pendiente de CRM. Ni el éxito visible ni un estado del proveedor sin revisar permiten cerrar todo el recorrido.
Compara supuestos y exclusiones del presupuesto
Pregunta cómo afectarían accesos ausentes, copias no disponibles, componentes propios sin soporte o un compromiso de seguridad recién detectado. La respuesta debe explicar decisión y autorización necesarias, sin fingir un importe preciso para una causa desconocida.
Comprueba si se incluyen costes externos, licencias, reconstrucción de contenido, investigación de seguridad y mantenimiento posterior. Cada proveedor puede delimitar estas partidas de otra forma. Hazlas visibles junto al precio.
Revisa cómo define la oferta su aceptación y cualquier periodo de seguimiento. La palabra reparación no implica arreglos futuros ilimitados. El alcance escrito debe explicar qué ocurre si vuelve el síntoma original y cómo se valora una avería diferente.
Preguntas que conviene cerrar antes de aceptar
¿Cómo comparo horas y precio cerrado?
Compara el mismo trabajo autorizado, evidencia y exclusiones. Por horas, acuerda información de avance, límite de gasto aprobado cuando corresponda y momento de consultar antes de continuar. Con alcance cerrado, identifica supuestos y hallazgos que lo cambiarían. El formato de precio no resuelve si están incluidos datos anteriores, terceros o repetición de pruebas. Coloca esas partidas junto al importe y distingue la fase de diagnóstico.
¿Y si necesitamos recuperar servicio antes de conocer toda la causa?
Acuerda un objetivo provisional y sus riesgos. Una restauración temporal, respuesta de mantenimiento o función limitada puede ayudar a continuar mientras se investiga. Registra qué se ha recuperado, qué sigue restringido y quién hace el siguiente paso. La respuesta temporal no demuestra que desapareciera el fallo de fondo. La propuesta debe explicar cómo se encargarán diagnóstico y verificación finales.
¿Cómo se acepta una reparación intermitente?
Describe la condición original y acuerda prueba repetible, observaciones que conservar y un periodo razonable de revisión. Anota muestra y reproducción del síntoma. Unos intentos correctos no prueban que nunca volverá, pero aportan una base identificada para aceptar. Define qué evidencia abriría otra investigación y quién la recibirá. Esto facilita decidir sin convertir una comprobación puntual en una garantía indefinida.
¿Puedo pedir presupuesto antes de compartir accesos?
URL pública, síntoma, hora y tarea comercial permiten una primera valoración. El proveedor debe explicar qué desconoce y si necesita una fase de diagnóstico controlada para presupuestar la corrección. Conserva visibles los supuestos de cualquier estimación. El acceso se prepara después para la finalidad acordada; la primera consulta pública puede hacerse sin credenciales.
Dos incidencias observadas: qué debería contener el cierre de una reparación
El 25 de octubre de 2026 documentamos estos dos problemas en webs de nuestra red. Son intervenciones propias, no casos de clientes ni ejemplos ficticios. Sirven para comparar entregables: síntoma, causa, cambio y comprobación. No hemos medido cuánto tardó cada reparación ni calculado ventas recuperadas.
WR-01. Una tabla que se llevaba toda la página hacia la derecha
Síntoma: en la guía de pruebas de formularios de Forms Not Sending, una ventana configurada a 412 píxeles tenía un documento de 517 píxeles de ancho. El bloque del artículo medía 622 píxeles. La tabla conservaba sus 620 píxeles mínimos y el desplazamiento acababa afectando a la página. La tabla había decidido alquilarse un piso más grande.
Causa confirmada: el mínimo automático del elemento dentro de la cuadrícula impedía que el contenido se estrechara con la ventana. El contenedor de la tabla ya permitía desplazamiento horizontal, pero su padre seguía ensanchándose. La referencia de MDN sobre min-width explica ese mínimo en elementos de grid.
Cambio aplicado: permitimos encoger los hijos de la cuadrícula con min-width:0 y fijamos la columna móvil mediante minmax(0,1fr). La tabla mantuvo su desplazamiento dentro del contenedor. La corrección quedó en una extensión acotada a los artículos; el archivo del tema terminó con su contenido original. No se ocultó el desbordamiento de toda la página para disimular el problema.
Comprobación pública: el registro posterior dio 412 píxeles de documento para 412 de ventana. Repetimos ahora la visita pública en Chromium con ventanas de 412 y 1440 píxeles: la página cabe y, en la estrecha, la tabla se recorre dentro de su contenedor. Son tamaños de ventana de un navegador de escritorio, no pruebas en teléfonos físicos ni una matriz de todos los navegadores.
WR-02. El interruptor de cookies decía una cosa y la elección guardada, otra
Síntoma: durante una revisión del artículo de rendimiento y consentimiento de Code GxP, la preferencia de analítica estaba denegada y la visita medida no registraba las peticiones de seguimiento contadas. Sin embargo, el panel servido desde caché mostraba su interruptor encendido. Mirar únicamente el interruptor habría dado un diagnóstico equivocado.
Causa confirmada: el estado visual recibido en el HTML no estaba sincronizado con la categoría guardada en ese navegador. La reparación necesitaba reconciliar el control mostrado con la elección existente; cambiar la preferencia del visitante para hacer coincidir la pantalla habría resuelto el problema al revés.
Cambio aplicado: añadimos un acceso para reabrir las preferencias existentes y sincronizamos los interruptores al cargar y al abrir el panel. Ese ajuste lee la elección guardada; no la sustituye. Renovamos las respuestas públicas en caché afectadas y retiramos el observador temporal utilizado para medir.
Comprobación pública: la serie original alternó tres visitas con rechazo y tres con aceptación, todas en Chrome de escritorio. Registró cero recursos de los orígenes de seguimiento contados con rechazo y dos en cada visita con aceptación. En la repetición actual usamos dos contextos nuevos de Chromium: elegimos rechazar o aceptar mediante la interfaz, recargamos y reabrimos la configuración. El interruptor coincide con la categoría guardada en ambos casos. Esto verifica ese recorrido; no constituye una auditoría completa de privacidad ni demuestra una mejora de velocidad.
| Incidencia | Antes | Criterio de cierre comprobado |
|---|---|---|
| WR-01 · Maquetación | Documento de 517 px en una ventana configurada a 412 px. | Documento de 412 px; tabla con desplazamiento interno. |
| WR-02 · Preferencias | Analítica denegada y control visual encendido. | Tras elegir, recargar y reabrir, estado guardado y control coinciden. |
Para pedir presupuesto, no necesitas conocer de antemano la propiedad CSS o el origen del estado incorrecto. Sí conviene pedir este mismo hilo: qué fallaba, qué se confirmó, qué cambió y bajo qué condiciones se repitió la prueba. Una captura bonita del «después» puede acompañarlo; el cierre necesita algo que otra persona pueda comprobar.
Cierra accesos y conserva un traspaso utilizable
Pide una explicación breve de causa observada, cambio, verificación y pendientes. Conserva identificadores y evidencia técnica necesarios para continuidad, manteniendo credenciales y datos personales innecesarios fuera del documento compartido.
Revisa accesos temporales y configuración de diagnóstico con sus responsables. Asigna seguimiento, actualizaciones o implementación posterior. La reparación puede destapar una necesidad de mantenimiento; ese trabajo continuado merece su propio alcance acordado.
Para pedir un presupuesto de reparación de una web WordPress, envía URL pública, síntoma original, cronología aproximada, cambios recientes y tarea que necesitas recuperar. Website Repair revisa ese contexto antes de pedir accesos o comenzar. Un briefing preciso no tiene que ser un documento solemne. Basta con que la siguiente persona encuentre algo útil para ponerse a trabajar.