What information a website repair technician needs

Repair technicians are not guessing because they lack skill. They guess when the failure is moving — when logs were cleared, when three plugins were deleted in one pass, when nobody remembers whether DNS changed Tuesday or Wednesday.

Good intake turns a vague “WordPress is broken” into a bounded problem: what fails, when it started, what changed, what access exists, and what “fixed” would look like. You do not need to diagnose the root cause yourself. You need to supply evidence so someone else can do it once.

What probably happened before you call

By the time owners reach out, the story usually follows a pattern. Something changed. Someone tried quick fixes. The error message shifted or disappeared. Access got tighter because passwords were rotated in a hurry.

Maybe the public site still loads but admin does not — a split outage with its own checklist (site up, admin down). Maybe the whole site white-screens after updates. Maybe the host sent a malware notice. Maybe nobody touched anything and PHP upgraded overnight.

Whatever the trigger, the technician’s first job is to freeze the narrative: separate symptoms from theories, and separate what you tried from what actually changed on disk or in DNS.

If you skipped the calm first moves, read what to do immediately when WordPress breaks before submitting intake — ten minutes of documentation can save a full billable hour.

What to gather before intake

You do not need every item on this list to start. You do need enough that diagnosis is not blocked on day one.

Symptoms (exact, not approximate)

• URLs that fail vs URLs that work (home, wp-admin, checkout, single product).
• Exact error text, HTTP status, or “blank white screen.”
• First noticed time and time zone.
• Browsers or devices tested (sometimes admin breaks only on Safari, or only when logged in).

Screenshots beat paraphrasing. “Critical error” without the full line hides whether the fault is theme, plugin, or core.

Timeline of changes

List anything that touched the stack in the 72 hours before failure:

• WordPress, plugin, or theme updates (which ones).
• Host migrations, PHP version changes, SSL installs.
• DNS or CDN changes (Cloudflare orange cloud, new A record).
• New users, password resets, security plugin toggles.
• Content launches, imports, or bulk edits.

“If nothing changed” is useful information too — but verify with your host ticket history and auto-update settings.

Access inventory

State plainly what you can hand over securely:

• Hosting panel (cPanel, Plesk, Kinsta, WP Engine, etc.) — SFTP/SSH if available.
• WordPress admin — if reachable; if not, say so.
• Domain registrar — only if DNS is in scope.
• CDN or DNS provider (Cloudflare, Route 53).
• Database — phpMyAdmin or host SQL console.
• Backup system — where backups live and last known good date.

Missing access is not a dealbreaker, but it changes the plan. A technician cannot rename plugins via FTP if nobody has FTP.

Backup status

Answer honestly:

• Do backups exist? Where?
• When was the last successful backup taken (before or after the break)?
• Have you restored one recently on staging or production?
• Did anyone start a restore that might still be running?

“We have backups” without a verified restore is a hope, not a plan. If you are unsure, say that — it affects risk.

Business impact and deadline

Technicians prioritize differently when checkout is down during a sale versus when a brochure blog has a cosmetic glitch. Share:

• Revenue or lead flow affected?
• Hard deadline (event, launch, compliance notice)?
• Can the site stay in maintenance mode briefly?

Scope follows impact. Emergency repair exists for high-impact, time-bound failures — not because panic feels loud.

What you already tried

List each DIY step and whether you reversed it:

• Renamed plugins folder? Which name, which time?
• Edited wp-config.php? Restored default theme?
• Cleared cache layers (host, plugin, CDN)?
• Ran repair plugins or database “optimize” tools?

Untracked changes are the main reason repairs take longer. If you followed risky moves, note them — see how to avoid making a broken website worse so you know which patterns to flag.

Logs and host notices

Attach or paste:

• PHP error log excerpts around the failure time.
• wp-content/debug.log if enabled (disable public display afterward).
• Host suspension, malware scan, or resource limit emails.
• Uptime monitor alerts with timestamps.

Redact customer data if logs include form submissions, but keep file paths and error lines intact.

What not to do while preparing intake

Intake is not the moment for one more hail-mary fix.

• Do not wipe logs to “clean things up” before sharing access.
• Do not run bulk optimizers on the database to make it “look maintained.”
• Do not change passwords without updating the secure share you will send.
• Do not start a production restore while a technician is about to inspect — you may overwrite evidence.
• Do not post full credentials in email bodies if your process supports secure sharing.

If the site may be compromised, say so upfront. Security repairs need containment first, not a quick plugin deactivate from a possibly stolen admin session.

When to stop gathering and submit

You have enough to start when a technician could answer these without a call:

1. What is broken, specifically?
2. When did it start?
3. What changed around that time?
4. What access and backups exist?
5. What does success look like by when?

You do not need to know whether it is .htaccess, opcode cache, or a rogue mu-plugin. That is the diagnostic.

If you are still actively clicking fixes, pause and write down the next step before you take it. If you cannot articulate the next reversible step, you are past DIY — submit intake with what you have.

How good intake speeds repair

Technicians work faster with a frozen failure mode. They compare file timestamps to your timeline, reproduce the error in a staging clone, bisect plugins with a paper trail, and choose restore vs repair based on backup age and business cost.

Thin intake (“it’s broken, please help”) forces discovery work: chasing access, reconstructing changes, re-breaking a site that accidentally started working when cache cleared. That is billable time that does not move you closer to fixed.

Treat intake like handing off a patient chart, not like venting frustration. Symptoms, history, allergies to certain fixes, and what “healthy” means — that is the package.

Bring the facts. We will bring the systematic repair.