Web Server Audit (Apache/Nginx, PHP-FPM, MySQL): Performance & Security

Is your site slow, throwing 502/504 errors, or lacking security? Does your server hit 100% CPU with just 50 concurrent visitors? I perform a complete technical audit of your server (Ubuntu/Debian, OVH/Scaleway, Contabo...) to reduce TTFB, stabilize the load and harden security.

The audit covers the entire technical stack: network protocols (TLS/HTTP2), web server configuration (Nginx/Apache), PHP-FPM optimization, analysis of slow MySQL queries, system hardening, and setting up monitoring tools. Deliverable: a clear, prioritized report, with the option of having me apply the fixes myself.

Why get a web server audit?

Warning signs to watch for

Your server infrastructure is showing signs of weakness if you're experiencing one or more of these problems:

Degraded performance:

• Server response time (TTFB) above 600ms, when the target is < 200ms
• The site becomes slow or unreachable as soon as traffic increases (50–100 concurrent visitors)
• Pages take 5–10 seconds to load, when the HTML alone should be served in < 1 second
• Core Web Vitals are in the red (LCP > 4s, TTFB > 800ms)

Recurring errors:

• 502 Bad Gateway or 504 Gateway Timeout errors several times a day
• 500 Internal Server Errors with no apparent cause in the application logs
• PHP-FPM connections maxing out (“max children reached”)
• MySQL refusing new connections (“Too many connections”)

Stability problems:

• The server needs frequent restarts (several times a week)
• CPU or RAM usage constantly at 90–100% without any traffic spike to justify it
• PHP-FPM or MySQL processes terminating randomly (OOM Killer)
• Logs showing dozens of slow requests (> 2 seconds) every day

Security vulnerabilities:

• Expired SSL/TLS certificate or weak configuration (obsolete ciphers, no HSTS)
• No firewall configured, or overly permissive rules
• No protection against brute-force attacks (no fail2ban)
• Outdated, unpatched versions of PHP, MySQL or the operating system
• Root SSH access with a password (instead of SSH keys)

Business impact of these problems

A poorly configured server has direct, measurable consequences for your business:

Lost revenue: A site that takes 5 seconds to load loses 20% of its visitors (Google study). For an online store doing €50,000/month, that's €10,000 in lost revenue every month.

SEO penalties: Google's algorithm penalizes slow sites. A page whose load time goes from 2 seconds to 5 seconds can lose 30–50% of its organic traffic within a few months.

Inflated infrastructure costs: A poorly optimized server often leads to a costly hardware upgrade (going from 4 to 8 CPUs, doubling the RAM) when a simple software optimization would solve the problem for a tenth of the price.

Risk of hacking: 43% of cyberattacks target SMBs (Verizon 2024 report). An unhardened server is an entry point for phishing, customer data theft or ransomware.

What I analyze in detail

My server audit covers 7 essential technical layers, with before/after measurements to quantify the improvements.

1. Network & protocol

What I check:

• TLS/HTTPS configuration: protocol version (TLS 1.2 minimum, ideally 1.3), secure cipher suites, complete certificate chain
• Security headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options
• HTTP/2 or HTTP/3 enabled for multiplexing and header compression
• Gzip/Brotli compression configured for HTML/CSS/JS/JSON
• DNS: resolution time, DNSSEC configuration if applicable

What it reveals: Obsolete ciphers (RC4, 3DES) leave your site vulnerable to BEAST or POODLE attacks. Not having HTTP/2 costs 20–30% in speed on pages with many resources. A high DNS lookup time (> 100ms) systematically slows down every request.

Measurable impact: Switching to TLS 1.3 + HTTP/2 + Brotli = 25–40% reduction in total load time and an A+ grade on SSL Labs.

2. Nginx / Apache configuration

What I check:

• Static caching: expires, cache-control and etag directives for images/CSS/JS
• Compression headers: gzip_types, brotli_types
• Logs: custom format with $request_time and $upstream_response_time for debugging
• Rate limiting: protection against scrapers and aggressive bots
• Basic WAF: ModSecurity or Nginx limit_req to block common attack patterns
• Configuration files: worker_processes, worker_connections, keepalive_timeout, client_max_body_size

What it reveals: worker_connections set to 768 instead of 4096 artificially limits the number of concurrent connections. Without static caching, the browser has to re-download assets on every visit. A client_max_body_size of 2M blocks media file uploads.

Measurable impact: Optimal configuration = 50–60% bandwidth savings thanks to browser caching + the capacity to handle 4x more concurrent connections.

3. PHP-FPM: the invisible bottleneck

What I check:

• Process management strategy: pm = dynamic vs static vs ondemand
• Sizing: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers
• Limits: pm.max_requests (worker recycling), request_timeout, request_terminate_timeout
• Opcache: opcache.memory_consumption, opcache.interned_strings_buffer, opcache.max_accelerated_files, hit rate
• PHP limits: memory_limit, max_execution_time, post_max_size, upload_max_filesize
• Slow logs: enabling and analyzing slow PHP requests (> 1s)

What it reveals: This is THE #1 bottleneck on 80% of servers. A typical example: pm.max_children = 5 on a 4-CPU server → as soon as there are 6 concurrent requests, the rest are queued, causing timeouts.

A misconfigured opcache (too small, no preloading on PHP 8.x) forces PHP to recompile scripts on every request, multiplying the CPU load by 5–10x.

Measurable impact: Going from pm.max_children = 5 to pm.max_children = 40 (sized according to available RAM) + optimized opcache = 70% reduction in TTFB + no more “502 Bad Gateway” errors.

Real-world example: WordPress site with WooCommerce, 4GB RAM, pm.max_children = 5 (default).

• Before: 502 errors from just 8 concurrent visitors, TTFB of 3–6 seconds
• After: pm.max_children = 30, pm = dynamic, opcache enabled → TTFB 0.4s, no 502s up to 100 concurrent visitors

4. MySQL / MariaDB database

What I check:

• Connection settings: max_connections, wait_timeout, interactive_timeout
• Buffers and cache: innodb_buffer_pool_size, query_cache_size (if MySQL < 8.0), tmp_table_size
• Slow query log: enabling it and analyzing queries > 1 second
• Missing indexes: EXPLAIN on the most frequent queries to identify full table scans
• Locking: detecting deadlocks and long-running transactions
• Table optimization: fragmentation, unused tables, ANALYZE TABLE

What it reveals: An innodb_buffer_pool_size of 128MB (the default) on a server with 16GB of RAM = MySQL can't cache frequently used data and keeps hitting the disk.

Queries without indexes force MySQL to scan 500,000 rows instead of 10, multiplying execution time by 5,000x (from 0.001s to 5s).

Measurable impact: innodb_buffer_pool_size set to 70% of RAM + 3–5 strategic indexes added = 80% fewer slow queries + page response time divided by 3.

5. Application performance & TTFB

What I measure:

• TTFB (Time To First Byte) from different geographic locations: target < 200ms for Europe
• LCP (Largest Contentful Paint): target < 2.5s
• Pure HTML generation time (without assets): should be < 400ms for a dynamic page
• Number of SQL queries per page: more than 50 queries = an N+1 problem to investigate
• Asset size and weight: unoptimized images, unminified JS/CSS
• Application caching strategy: Redis/Memcached, static HTML cache (Varnish, nginx fastcgi_cache)

What it reveals: A TTFB of 2–4 seconds means the server needs that much time just to start sending data. Even on a fiber connection, the user has to wait. The problem is often a combination of slow PHP + unoptimized MySQL queries + no caching.

Measurable impact: Combined optimization (PHP-FPM + MySQL + Redis cache) = TTFB going from 2.8s to 0.3s, LCP from 6s to 2.1s → moving into the “Good” Core Web Vitals range.

6. System security & hardening

What I check:

• Firewall: UFW or iptables configured, minimal open ports (22, 80, 443), port scan blocking
• Fail2ban: SSH, HTTP and MySQL protection against brute-force attacks
• SSH access: root login disabled, SSH key authentication only, non-standard port
• Users and permissions: no services running as root, separate web/db users
• Updates: PHP, MySQL and operating system versions up to date with security patches
• Backups: frequency, retention, restore testing, off-server storage
• Log rotation: logrotate configured, compression, automatic deletion of old logs
• Intrusion monitoring: detection of modified files, system integrity monitoring

What it reveals: 80% of the servers I audit have no fail2ban or a poorly configured one, allowing thousands of SSH login attempts per day. No tested backups = risk of total data loss in the event of a disk crash or ransomware.

Measurable impact: Full hardening = 95% fewer intrusion attempts (fail2ban logs) + guaranteed restore in < 2 hours in the event of a major incident.

7. Observability & monitoring

What I set up:

• Log analysis: PHP errors, Nginx errors, MySQL slow queries, system errors
• Server metrics: CPU, RAM, disk, network, swap
• Basic alerting: email/SMS if CPU > 90% for 5 min, disk > 85%, service down
• Tools: Netdata (lightweight, free) or New Relic (if the budget allows)
• Simple dashboard: check your server's health at a glance

Impact: Proactive detection: you get an alert 10 minutes before the server goes down instead of finding out from unhappy customers. MTTR (Mean Time To Repair) reduced from 2 hours to 15 minutes.

My complete methodology

Phase 1: Access & preliminary analysis (30 min)

Access:

• SSH connection (public key provided) or access to the OVH/Plesk/ISPConfig panel
• Read access to logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• Read-only MySQL credentials to analyze slow queries

Initial data collection:

• Inventory: PHP, MySQL, OS and web server versions
• Statistics: uptime, load average, current CPU/RAM/disk usage
• Quick log review: spotting recurring errors

Phase 2: Performance & load testing (1 hour)

Baseline measurements:

• TTFB from 3 different locations (Europe, US, Asia) with curl/webpagetest
• Load test: simulating 10, 50 and 100 concurrent users with Apache Bench or k6
• PHP profiling: enabling Xdebug or Blackfire to identify slow functions
• MySQL analysis: top 20 slow queries via pt-query-digest (Percona Toolkit)

Identifying bottlenecks: The load test reveals exactly where things break: is PHP-FPM maxing out? Is MySQL locking? Is the RAM swapping?

Phase 3: Security analysis (45 min)

Vulnerability scan:

• SSL test: ssllabs.com, testssl.sh to identify TLS weaknesses
• Open port scan: nmap to detect unnecessary exposed services
• CVE check: outdated PHP/MySQL versions with known vulnerabilities
• File audit: files with 777 permissions, potential backdoor scripts

Configuration review:

• Analysis of /etc/ssh/sshd_config, firewall rules, fail2ban jails
• Checking that backups exist and are valid

Phase 4: Configuration analysis (1 hour)

Deep dive into the configs:

• Nginx/Apache: line-by-line review of the config files + benchmarks
• PHP-FPM: calculating total memory consumption (pm.max_children * memory_limit) vs available RAM
• MySQL: analysis of my.cnf, MySQLTuner recommendations
• System: limits configuration (ulimit), swap, kernel parameters

Phase 5: Writing the report (1–2 hours)

Report structure:

1. Executive Summary (2 pages)

• The 3 critical problems identified
• Estimated business impact (e.g., loss of 15% of SEO traffic, 25% of visitors abandoning)
• Budget for fixes: €0–500 (configuration), €500–1,500 (complex optimizations), > €1,500 (migration/hardware upgrade)

2. Detailed diagnostics (5–10 pages)

• Each problem documented with screenshots, log excerpts and metrics
• Accessible technical explanations (no unnecessary jargon)
• Severity: Critical / Important / Opportunity

3. Prioritized action plan (2–3 pages) Table: Action | Estimated impact | Complexity | Time | Cost

Example:

• Increase pm.max_children from 5 to 30 | 70% fewer 502 errors | Low | 10 min | Included
• Add 3 MySQL indexes on the orders table | Queries 50x faster | Medium | 1 hour | Included
• Migrate to an 8GB RAM server | Handles 3x the load | High | 4 hours | €150 migration

4. Long-term recommendations

• Ongoing monitoring plan
• Recommended update frequency
• 6–12 month improvement roadmap

Real client case: a WooCommerce online store

Initial situation

Client: Online store specializing in handcrafted products, 500–800 visitors/day, 5,000 products, average order value of €85.

Infrastructure:

• OVH Comfort VPS (4 vCPUs, 4GB RAM)
• Ubuntu 20.04, Nginx 1.18, PHP 7.4, MySQL 5.7
• WordPress 6.1 + WooCommerce 7.5 + 15 active plugins

Reported symptoms

• Slowdowns every day between 2 and 4 p.m. (lunch break = peak traffic)
• 502 Bad Gateway errors 2–3 times a day requiring a PHP-FPM restart
• Product pages taking 6–8 seconds to load
• Google Search Console flagging “Poor” on 70% of pages (LCP > 4s)
• Bounce rate up from 45% to 62% in 3 months
• Estimated loss: €200–300/day in missed sales

Audit findings (2.5 hours)

1. PHP-FPM: disastrous configuration

pm = dynamic
pm.max_children = 5 ATTENTION: (CRITIQUE)
pm.start_servers = 2
memory_limit = 128M

Calculation: 5 children × 128MB = 640MB max for PHP, with 4GB of RAM available → from 6 concurrent requests on, requests are queued → 502 timeout

2. MySQL: slow queries and missing indexes

• 847 queries > 2 seconds in the last 24 hours
• Query on wp_postmeta without an index: 3.8s to filter by meta_key
• innodb_buffer_pool_size = 128M (default) for a 2.1GB database

3. PHP opcache: disabled

• PHP recompiles every WordPress/WooCommerce file on every request
• Unnecessary CPU load multiplied by 8–10x

4. No application caching

• No HTML caching plugin (WP Super Cache, W3 Total Cache)
• Every page regenerated on every visit, even for logged-out visitors

5. Weak security

• Fail2ban not installed: 3,200 SSH login attempts/day
• PHP 7.4: 12 unpatched critical CVEs (PHP 8.1 available)

Fixes applied (3 hours)

PHP-FPM (15 min)

pm.max_children = 30 (4GB RAM / 130MB par enfant)
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

Opcache (5 min)

opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 0 (prod)
opcache.enable_cli = 1

MySQL (45 min)

-- Ajout index manquant
ALTER TABLE wp_postmeta ADD INDEX meta_key_value (meta_key, meta_value(20));
-- Configuration
innodb_buffer_pool_size = 2G (50% de la RAM)
max_connections = 200
query_cache_size = 0 (inutile MySQL 5.7+)

Application caching (30 min)

• WP Rocket installed (client's license)
• Configuration: HTML caching, CSS/JS minification, image lazy loading
• Cache generated for the top 500 pages

Security (1 hour)

• PHP upgraded from 7.4 → 8.1
• fail2ban installed with SSH + HTTP jails
• SSH hardening: root disabled, keys only
• Automatic daily backups to S3

Measured results (7 days later)

Performance:

• TTFB: ~~3.2s~~ → 0.4s (-87%)
• LCP: ~~6.1s~~ → 2.0s (-67%)
• Product page: ~~7.2s~~ → 1.8s (-75%)
• Core Web Vitals: ~~12% Good~~ → 89% Good

Stability:

• 502 errors: ~~2-3/day~~ → 0 in 7 days
• Load average: ~~4.5~~ → 0.8 (on 4 CPUs)
• RAM used: ~~92%~~ → 65%

Business:

• Bounce rate: ~~62%~~ → 48% (-14 points)
• Time on site: +22%
• Conversions: +18% (calculated over 7 days vs the previous week)
• Estimate: +€280/day in revenue, or +€8,400/month

Security:

• SSH attempts blocked: 3,200/day → 0 (IPs banned automatically)
• CVE vulnerabilities: ~~12 critical~~ → 0

Total cost: Audit (€490) + Implementation (€350) + WP Rocket license (€59/year) = €899 excl. VAT ROI: Paid for itself in 3 days of additional revenue

Server audit vs other types of audits

It's important to distinguish between the different types of web audits, as they don't cover the same aspects:

My advice: For a sluggish site, always start with the server audit. There's no point optimizing your images if your TTFB is 4 seconds because of a misconfigured PHP-FPM.

Checklist: Do you need a server audit?

Answer the following questions honestly. If you check 3 boxes or more, a server audit is highly recommended.

• [ ] My site takes more than 3 seconds to load on a good connection
• [ ] I get 502, 504 or 500 errors at least once a week
• [ ] My server needs a manual restart at least once a month
• [ ] I don't know the pm.max_children value of my PHP-FPM
• [ ] My site slows down considerably when I have 50+ concurrent visitors
• [ ] I have never optimized my MySQL database
• [ ] My SSL certificate has a grade < A on SSL Labs
• [ ] I haven't updated the system or PHP in more than 6 months
• [ ] I don't have a tested automatic backup system
• [ ] My hosting provider has already contacted me about “excessive resource usage”
• [ ] Google Search Console shows “Poor” for my Core Web Vitals
• [ ] My bounce rate has risen by more than 10% in recent months for no apparent reason

Score:

• 0–2 checks: Your server seems OK, but a preventive check every 12–18 months is still recommended
• 3–5 checks: An audit is advisable within 1–2 months; you probably have some easy quick wins
• 6+ checks: Urgent audit needed; you're probably losing customers and revenue every day

Deliverables & process

What you receive

1. Complete audit report (15–25 page PDF)

• Executive summary with the top 3 critical problems
• Detailed diagnostics with screenshots and log excerpts
• Action plan prioritized by impact/complexity
• Long-term recommendations

2. Optimized configuration files

• Commented Nginx/Apache configurations, ready to deploy
• PHP-FPM pool sized for your server
• Optimized MySQL my.cnf file
• Basic monitoring and alerting scripts

3. Procedure documentation

• Checklist for deploying the fixes
• Rollback guide in case of problems
• Backup restore procedure

4. Post-intervention follow-up (optional)

• 30-day access to the monitoring dashboard
• 7 days of email support for questions
• 30-min training session (configuration, reading the metrics)

Typical timeline

Day 0: First contact

• 15-min phone or video briefing to understand your problems
• Preliminary technical questionnaire sent to you
• Quote within 24 hours

Day 1 to Day 2: Access & preparation

• SSH/panel access set up
• Non-intrusive monitoring tools installed, if you agree
• Collection of logs and baseline metrics

Day 3: Audit (2–4 hours)

• In-depth analysis of every layer (network, server, PHP, MySQL, security)
• Load testing to identify limits
• Findings documented in real time

Day 4 to Day 5: Report & presentation

• Writing the complete report
• 30–45 min video call to present the findings and recommendations
• Answers to your technical questions

Day 6 (optional): Implementing the fixes

• Full system backup before any changes
• Optimizations applied in order of priority
• Regression testing after each change
• Post-intervention measurements: checking that the targets are met

Day 7: Validation & wrap-up

• Validation report with before/after metrics
• Knowledge transfer and quick training
• Final documentation + 7 days of support

Typical results after an audit + optimization

Based on 40+ server audits carried out since 2020, here are the average improvements observed:

Performance

• TTFB reduced by 30 to 70%: from 1.5–3s down to 0.3–0.8s on average
• LCP improved by 40–60%: most sites move from “Poor” to “Good” (< 2.5s)
• Load capacity multiplied by 3–5x: a server that crashed at 30 concurrent visitors now handles 100–150
• 5xx errors eliminated: 90% of sites have no more 502/504 errors after optimization

Security

• 95%+ fewer intrusion attempts thanks to fail2ban
• Reduced attack surface: unnecessary ports closed, security updates applied
• SSL grade going from B/C to A+ through TLS hardening
• Stronger compliance: GDPR (encryption, backups), PCI DSS (for e-commerce)

Costs

• 30–50% savings on infrastructure: often avoids a costly server upgrade
• 70–80% less time spent on maintenance: less firefighting, proactive monitoring
• Average ROI: 3–6 months for an online store (through higher conversions)

SEO & Conversion

• 15–30% increase in organic traffic thanks to Core Web Vitals (a Google ranking factor)
• Bounce rate down by 10–20 points: visitors no longer leave because of slowness
• 10–25% increase in conversion rate: a fast site converts better

Environments covered

Operating systems

• Ubuntu 18.04, 20.04, 22.04, 24.04 LTS
• Debian 10, 11, 12
• Other Linux distributions on request (CentOS, Rocky Linux, Alpine)

Hosting providers & infrastructure

• OVH / OVHcloud (VPS, Dedicated, Public Cloud)
• Scaleway (Instances, Elastic Metal)
• Contabo (VPS, Dedicated)
• Hetzner (Cloud, Dedicated)
• DigitalOcean, Linode, Vultr
• On-premise dedicated servers

Control panels

• Plesk Obsidian
• ISPConfig 3.x
• cPanel/WHM (less experience, but doable)
• Manual configuration (no panel): preferred for maximum performance

Web servers

• Nginx 1.18+ (recommended for performance)
• Apache 2.4+ with MPM Event or Worker
• OpenLiteSpeed (on request)
• Hybrid configurations (Nginx reverse proxy + Apache backend)

PHP

• PHP 7.4, 8.0, 8.1, 8.2, 8.3 (all FPM versions)
• Support for multiple PHP versions running side by side
• Extensions: opcache, APCu, Redis, Memcached, imagick, etc.

Databases

• MySQL 5.7, 8.0+
• MariaDB 10.3, 10.5, 10.6, 10.11+
• PostgreSQL (on request, less experience than with MySQL)

Common web applications

• WordPress / WooCommerce (80% of my experience)
• Magento 2.x
• PrestaShop 1.7, 8.x
• Drupal 9, 10
• Laravel, Symfony, CodeIgniter (PHP frameworks)
• Custom PHP applications

Pricing & turnaround

Audit packages

Essential Audit – €390 excl. VAT

• Simple server: 1 site, standard stack (Nginx/Apache + PHP + MySQL)
• 2–3 hours of analysis
• 10–15 page report with a prioritized action plan
• Optimized configuration files provided
• Ideal for: business websites, blogs, small online stores (< 1000 visitors/day)

Advanced Audit – €690 excl. VAT

• Complex server: multiple sites, custom configurations, high traffic
• 4–6 hours of in-depth analysis
• 20–30 page report + load testing + application profiling
• Architecture recommendations (Redis, CDN, load balancing)
• 1-hour video presentation of the findings
• Ideal for: medium/large online stores, SaaS, business applications

Audit + Implementation – Custom quote (typically €900–1,500 excl. VAT)

• Advanced Audit + I apply the fixes myself
• Full backup before any changes
• Regression testing
• Before/after measurements with a validation report
• 7 days of post-intervention support
• Ideal if: you don't have in-house sysadmin skills

Emergency Audit (< 24 hours) – Rate × 1.5

• Intervention within 24 hours (business days)
• Express report within 48 hours
• Ideal for: an ongoing crisis, a site that's down, a recent hack

Add-on options

• Training session (1 hour): +€150 excl. VAT
  • Reading the metrics, using the monitoring, preventive maintenance
• Monthly maintenance support: from €200 excl. VAT/month
  • Monthly security updates
  • 24/7 monitoring with alerting
  • Corrective interventions included (up to 2 hours/month)
• Follow-up audit (6 months later): 50% off the initial price
  • Checking that the optimizations hold up over time
  • Adjustments if your traffic has changed

Standard turnaround times

• Quote: within 24 hours of the initial briefing
• Access & preparation: Day 1 to Day 2
• Audit: Day 3 (2–4 hours of focused work)
• Report delivery: Day 4 to Day 5
• Implementation (if selected): Day 6
• Final validation: Day 7

Total turnaround: 7 business days on average, 3–4 days for emergencies.

Included in every package

Complete analysis of all 7 layers (network, server, PHP, MySQL, security, performance, monitoring) Detailed PDF report with screenshots and actionable recommendations Optimized configuration files ready to deploy 30-min video presentation of the findings (Advanced package and above) 1 round of follow-up questions by email after delivery

Payment methods

• Bank transfer (IBAN provided on the invoice)
• Credit card via Stripe (secure payment link)
• PayPal (French businesses)

Terms: 50% upon ordering (after the quote is accepted), 50% upon delivery of the report.

Frequently asked questions

What exactly does the web server audit cover?

The audit analyzes 7 technical layers: network protocol (TLS/HTTP2), web server configuration (Nginx/Apache), PHP-FPM optimization (pm.*, opcache), MySQL database (slow queries, missing indexes), system security (fail2ban, firewall, updates), application performance (TTFB, Core Web Vitals), and monitoring (logs, metrics, alerting). You receive a detailed report with a prioritized action plan.

Can you fix the problems you find, or only identify them?

Both are possible. The “Essential Audit” or “Advanced” package identifies the problems and provides optimized configuration files that your technical team can deploy. The “Audit + Implementation” package includes having me apply the fixes, with a prior backup, regression testing, and before/after measurements. This is the recommended option if you don't have an in-house sysadmin.

How long does an audit take and how much does it cost?

Basic audit from €390 excl. VAT for a simple server, completed within 7 business days (24-hour emergency service available for an extra fee). The “Audit + Implementation” package is quoted on request (typically €900–1,500 excl. VAT) depending on complexity. A free 15-min initial briefing lets me prepare an accurate quote within 24 hours.

Do I need to take my site offline during the audit?

No, the audit is non-intrusive. The analysis is done mainly via read-only SSH access (logs, configurations, metrics). Load tests are carried out with your agreement and can be scheduled during off-peak hours if you prefer. Only implementing the fixes (optional package) may require 2–5 minutes of downtime to restart services (PHP-FPM, MySQL), and this is scheduled in advance.

My server is hosted with OVH/Scaleway/another provider. Is that a problem?

Not at all. I regularly work with OVH, Scaleway, Hetzner, Contabo, DigitalOcean and other standard hosting providers. The audit is independent of the host as long as I have SSH or panel access (Plesk, ISPConfig). If your hosting is very specific (e.g., managed AWS hosting with restrictions), a preliminary briefing will confirm feasibility.

What happens if you find critical security flaws?

I alert you immediately (even before the full audit is finished) if I detect a critical, actively exploitable vulnerability (backdoor, PHP version with a critical CVE exploited in the wild, completely open server). The report then includes a prioritized action plan with the urgent fixes at the top of the list. With the “Audit + Implementation” package, I can apply the security patches as a priority as soon as they're identified.

Does the audit cover optimizing my application's code?

The server audit focuses on infrastructure and system configuration (server, PHP, MySQL). I can identify that a page runs 150 SQL queries or that certain PHP functions are slow (through profiling), but detailed optimization of the application code (refactoring, rewriting complex queries) calls for a dedicated application audit. That said, 80% of performance problems come from server configuration, so the audit solves most cases.

Do you guarantee results?

I guarantee that the report will contain actionable, measurable recommendations. For the “Audit + Implementation” package, I commit to quantified targets agreed on together beforehand (e.g., TTFB < 400ms, 0 502 errors for 7 days, “Good” Core Web Vitals on 80%+ of pages). If the targets aren't met after the intervention, I continue optimizing at no extra cost until you're satisfied.

Can I get a sample audit report?

Yes, I can email you an anonymized report (client data masked) on request, which will give you a precise idea of the level of detail and the format. Contact me at [your email] with “Sample audit report” in the subject line.

Do you offer follow-up or maintenance after the audit?

Yes, there are several options:

• Post-audit support included: 7 days of Q&A by email after delivery
• Follow-up audit at 6 months: 50% off the initial price to check that everything holds up over time
• Monthly maintenance: from €200/month, including security updates, 24/7 monitoring, and corrective interventions (up to 2 hours/month)

My site runs on WordPress/Shopify/another CMS. Does that change anything?

The server audit is CMS-agnostic, since it focuses on the system layer (Linux, Nginx, PHP, MySQL). However, my extensive experience with WordPress/WooCommerce (80% of my audits) lets me go further: I can audit problematic plugins, optimize the WP database (wp_options, transients), configure object caching (Redis), etc. For hosted Shopify stores, a server audit doesn't apply (the infrastructure is managed by Shopify), but I can audit custom Shopify apps if they're hosted on your server.

What access do you need to my server?

Minimum requirements:

• SSH access (user account with sudo, or root if you agree) via a public key that I provide
• Read access to logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• Read-only MySQL credentials to analyze slow queries

Optional (but recommended):

• Panel access (Plesk, ISPConfig) if applicable
• CMS credentials (WordPress admin) to test under real conditions
• Google Search Console / Analytics access to correlate with business metrics

Security: All access you provide is removed immediately after the audit (within 48 hours max). An NDA can be signed on request.

If you're looking for complementary solutions, also check out:

• Website security audit: Application focus (XSS/CSRF/SQLi vulnerabilities, outdated plugins, GDPR compliance)
• Hacked website repair: Emergency intervention after a hack (backdoor cleanup, restoration)
• Core Web Vitals optimization: Improving LCP/FID/CLS on the front end
• Website speed optimization: Overall optimization (front end + back end)
• Website troubleshooting and optimization: Overview of my troubleshooting services
• Performance and speed: Resources and guides on web optimization
• Security and compliance: Security resource center (GDPR, SSL, backups)

Ready to boost your server's performance and security? Request your free audit