Before you ask someone to fix your website: what to send

Why the first message matters

When a website breaks, the first message is usually short: “the site is broken, can you help?” That is a fine way to start, but much of the first day then goes to questions. A developer cannot estimate a fix without seeing the problem, and cannot see the problem without knowing where, when and for whom it happens.

Most of our fix-and-improve work starts with code someone else wrote, on WordPress, WooCommerce, Laravel, custom PHP and most other stacks. This is the list we wish every first message included. You do not need all of it to get in touch; even half of it makes the first reply faster and the estimate more accurate.

Where and what

• The exact URL of the page with the problem, not just the home page.
• What you expected and what happened instead, in a sentence or two each.
• Steps to reproduce: what you clicked or entered, in order.
• Who sees it: everyone, only logged-in users, only on phones, only in one browser, only in one language.

Evidence and timing

• Screenshots or a short screen recording. Include the address bar and any error message in full.
• The exact error text. Copy it rather than paraphrasing; error messages are specific and searchable.
• When it started, as precisely as you can. “Since Tuesday morning” is far more useful than “recently”.
• What changed around then: plugin or theme updates, a new plugin, a hosting move, a domain or DNS change, a new tracking script, a content import, a developer’s last release.
• Whether it is constant or intermittent. Problems that come and go often point to caching, server limits or a third-party service.

If the problem is about search, such as pages dropping out of results, mention whether anyone recently changed redirects, the “Discourage search engines” setting in WordPress, or added a noindex rule. If it is about speed, say which pages and which devices, and include the Core Web Vitals report from Search Console if you have access to it.

Technical details you can collect yourself

• Platform and versions: CMS and version, theme, PHP version and the list of active plugins. In WordPress, Tools → Site Health → Info has a button that copies most of this to the clipboard in one go.
• Hosting: the provider and plan, and whether a CDN or caching service sits in front of the site.
• History: who built the site, and whether there is a code repository, a custom theme or custom plugins.
• Error logs, if your host provides them. Many hosting control panels include a log viewer.

Access, shared safely

Do not send passwords in the first email. Once you have agreed to work together, share access through a password manager or another secure channel, and prefer separate accounts over your own:

• a dedicated administrator account in the CMS, which you can delete when the work is done;
• hosting or SFTP access, or a team invitation if your hosting panel supports it;
• access to the code repository, if there is one;
• where relevant, access to Google Search Console, analytics or the DNS provider.

Separate accounts are easy to revoke, and they make it clear afterwards who changed what.

Priorities, limits and a staging copy

• What matters most. If there are several problems, rank them. “Checkout is broken” and “the footer is misaligned” deserve different urgency.
• Deadlines and constraints: a campaign launch, busy hours when the site should not be touched, a budget range.
• Whether a staging environment exists. A staging copy lets changes be tested before they reach the live site. If there is none, one can be set up; it should be hidden from search engines and, for a store, kept from sending real emails or taking real payments.

We make changes on a staging copy first, release carefully and then check that everything works in production. The process is described on our website fixes page.

A short template. If you prefer one, these lines cover the essentials:

1. Site and page: the full URL.
2. Problem: what happens, and what should happen instead.
3. Steps: what to click or enter to see it.
4. Who and where: all visitors, mobile only, one browser.
5. Since when, and what changed around then.
6. Platform: CMS and version, theme, PHP, hosting.
7. Priority: most urgent first, plus any deadline.
8. Staging: yes or no.

Small tasks are welcome: a single bug, a form or a layout fix is a normal request. For ongoing care after the fix, see support and maintenance. When you are ready, send us the link and a short description.