Website repair preparation guide
Show the problem without having to diagnose it.
Use this guide to prepare for a repair discussion. It is a checklist for your own notes, not a diagnosis or a form that collects information.
Reviewed 16 October 2026 · Faith Forge Labs
Write down one failing task
Choose a specific example: “On the contact page, I press Send and see an error,” rather than “the website is broken.” Note the page address, approximate time, browser and device. Record what should happen and what actually happens.
If a screenshot helps, remove customer details, private messages and other sensitive information before sharing it.
Keep a short change history
List recent software or theme updates, new apps, hosting moves, domain changes and code edits. A change made shortly before the failure is a clue, not proof that it caused the problem. Avoid stacking more updates on top of it while you are trying to understand what happened.
Know who controls the important accounts
You do not need to send access details in the first inquiry. Check privately who can approve changes and help recover the site.
| Item | Question to answer | Useful note |
|---|---|---|
| Domain and hosting | Who owns the account and can contact the provider? | Provider name and responsible person; no password. |
| Website files and software | Who can supply the current files or an authorized export? | Where the latest version is kept. |
| Backup | When was it made, and has a restore been checked? | Date and known restore status; do not upload the backup. |
| Connected services | Does the failing task depend on email, payments or another provider? | Service name and owner; no keys or customer data. |
Agree on a check that shows the repair works
For a form, check both the visitor’s confirmation and the intended stored record or delivery. For a mobile menu, open it, follow a link and return to the page without hidden controls. For an update failure, repeat the important tasks after the site loads again.
Testing a payment or outgoing message needs a safe method agreed for the site. A test should not charge or contact a real customer by accident.
Ask what happens if the change goes wrong
A repair plan should explain what will be backed up, where the change can be tested and how to return to the previous version. It should also identify work that cannot be checked yet and decisions that depend on an account owner or provider.
If the website was built with an AI tool
Keep the exported source files and any instructions for running or publishing them. A working preview or screenshot alone does not show that the website can be updated, hosted elsewhere or connected to real forms. Mention which tool was used and whether you have the code; leave private access information out of the inquiry.
Keep the first message short
Send the page address, the failed task, recent changes and the date you need help by. If ownership, backups or source files are uncertain, say so. Those unknowns can be checked before anyone decides whether to repair or rebuild.
Tell us what stopped working
Share the affected page, what you expected to happen and what happened instead. Use Contact Us at the bottom right or email Faith Forge Labs. A short description is enough to start; leave out passwords and private customer information.
Prepare your inquiry