Website performance, security and production recovery

I identify which journeys create revenue or support customers: enquiry forms, checkout, booking, login, admin processing and confirmation. Recovery work starts there rather than optimizing low-impact pages while the core transaction is broken.

Temporary safeguards can be introduced while the root cause is investigated.

A slow page may come from images, scripts, database queries, hosting, third-party calls or a compromised plugin. A failed form may be frontend validation, server configuration, email delivery or API authentication.

The diagnosis uses logs, browser tools and controlled tests instead of applying unrelated optimization plugins.

Malicious files, database content, users, scheduled tasks and credentials must be reviewed together. Removed spam URLs should return a real 404 or 410, stay out of the sitemap and be monitored in Search Console.

The clean site then needs stronger professional pages and internal linking so the correct topic becomes dominant as Google recrawls.

Core Web Vitals and page speed matter, but changes are tested against forms, checkout, tracking and interactive components. Deferring or removing a script is not an improvement if it stops a conversion or hides a required control.

Performance work is prioritized by real user impact and template reuse.

The final work documents what failed, what changed, which credentials were rotated and what should be monitored. Backups and update responsibility are clarified.

This reduces the chance that the same incident returns or that a future developer unknowingly restores the vulnerable component.