Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Hosting Dns Ssl

Cómo recopilar evidencias útiles antes de pedir una reparación urgente

Prepara evidencias seguras de un incidente WordPress con horas, errores, cambios, accesos, copias y autorización para repararlo.

«La web no funciona» inicia una investigación, pero no identifica la capa averiada. Un paquete pequeño con hora exacta, URL, respuesta, cambios recientes y acceso permite comenzar con seguridad sin pedir secretos por chat.

Recoge evidencias sin repetir operaciones de escritura ni exponer datos de clientes.

Describe el síntoma con precisión

Anota dominio o URL, fecha con zona horaria, primera aparición, frecuencia y usuarios afectados.

Ejemplos:
todas las páginas devuelven un 502 del servidor
wp-admin entra en bucle, pero la web pública funciona
el editor recibe REST 403 al guardar
imágenes grandes devuelven 500

No concluyas «base corrupta» si los registros no lo demuestran.

Captura la evidencia HTTP

Guarda estado, cadena de redirecciones, cabeceras relevantes, request ID y captura. Prueba raíz y www, HTTP y HTTPS, y un recurso estático solo si aporta información.

No incluyas cookies, Authorization, nonces ni queries privadas en archivos HAR. Un HAR completo puede contener formularios y datos personales; redacta antes de compartir.

Conserva logs de una ventana estrecha

Extrae solo el intervalo relevante de PHP, servidor web, MySQL y eventos de recursos. Incluye el primer error y su ruta de ejecución.

Conserva:
fecha y hora
clase y mensaje
ruta relativa del componente y línea
identificador de petición
versión de PHP o software

Elimina contraseñas, tokens, consultas completas y contenido personal.

Documenta los cambios recientes

Lista actualizaciones de plugins, tema, núcleo, PHP, DNS, SSL, caché, firewall, despliegues, migraciones e importaciones con hora, responsable y versión.

«No hubo cambio planificado» también ayuda: revisa actualizaciones automáticas y mantenimiento del proveedor. No reviertas varios elementos antes de analizar la evidencia porque perderías la atribución.

Registra el estado del hosting

Captura disco, inodos, CPU, RAM, entry processes, handler y límites PHP, estado MySQL y fallos de cron o backup.

Usa informes de cPanel, Plesk o proveedor sin secretos de cuenta. Indica si otros servicios autorizados del mismo hosting fallan. No lances escaneos pesados durante una sobrecarga.

Preserva la integridad de la evidencia

Guarda extractos y capturas originales con fecha y checksum cuando pueda existir revisión contractual. Trabaja sobre copias y documenta conversiones de zona horaria o redacciones.

No edites el único original para quitar secretos: crea una versión redactada y protege la fuente con acceso y retención restringidos. Declara los huecos debidos a rotación de logs.

Define autoridad y condiciones de parada

Indica sistemas incluidos y acciones aprobadas: diagnóstico de lectura, mantenimiento, desactivar plugin, reparar base, cambiar DNS o restaurar. Identifica quién autoriza caída o rollback.

Establece parada ante pagos inciertos, backups ausentes, datos divergentes o un objetivo destructivo sin resolver. La urgencia no autoriza borrar información desconocida.

Prepara acceso seguro

Proporciona cuentas individuales, temporales y de privilegio mínimo para panel, SFTP, SSH o WordPress mediante un sistema aprobado para secretos, nunca correo o chat ordinarios.

Confirma dominio, document root y permiso para modificar producción. Activa auditoría y define caducidad y retirada. No compartas la contraseña del propietario si sirve un usuario limitado.

Confirma los recursos de rollback

Lista fechas de backups, componentes incluidos, ubicación y última prueba de restauración. No digas «hay copia» sin comprobar que acabó y es accesible.

Protege la copia previa y crea un snapshot actual solo si es seguro. No llenes el disco averiado con otro archivo. Identifica datos nuevos que no pueden perderse.

Explica impacto y restricciones

Aclara si afecta a login, publicación, consultas, checkout, correo o solo al diseño, y los límites de tráfico, plazos o mantenimiento.

Identifica integraciones que staging no debe llamar y quién aprueba la interrupción. Restringe cifras de ingresos o clientes a destinatarios necesarios.

Entrega un caso reproducible

Resume síntoma, una reproducción, referencias de evidencia, cambios, acceso, copia y permiso de actuación. Actualiza el documento cuando cambien los hechos.

La monitorización recurrente debe automatizar métricas seguras y mantener inventario de accesos y copias. Una buena evidencia reduce el diagnóstico sin destruir el estado necesario para decidir.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia