“The website is broken, can you look?” is the message most developers receive first. It is a perfectly human thing to send. It is also the start of a slow conversation: which page, broken how, since when, for whom, on what device? Each of those questions costs a round of messages, and if your developer is in a different time zone, each round can cost half a day.
You do not need to know anything technical to cut that out. A developer mostly needs the same handful of facts every time, and you are the only person who has them. This post is a checklist of those facts, why each one matters, and a short template you can copy the next time something goes wrong.
Why the first message matters so much
Fixing a website problem is mostly finding it. The repair itself is often a few minutes once the cause is clear. What takes the time is reproducing the problem: seeing it happen on the developer’s screen, in the same conditions you saw it. A problem that only happens on one page, for logged-out visitors, on phones, after adding a product to the basket, can look completely fine to someone who opens your home page on a laptop while logged in. So the more of the conditions you describe, the sooner they see what you saw.
The eight things to include
1. The exact address
Copy the full URL from the browser’s address bar, not “the contact page” or “the shop”. Many sites have two contact pages, an old one and a new one, and many problems only affect one product or one post. If the problem happens on several pages, give two or three examples and say whether it is everywhere or only some.
2. The exact words of any error
Copy and paste the error text, or type it out word for word, including any file names and line numbers. “Some PHP error” is far less useful than Fatal error: Uncaught Error: Call to undefined function … in /wp-content/plugins/…, because the plugin name and file are right there in the full version. If WordPress showed “There has been a critical error on this website”, say so, and check the admin email inbox, because WordPress often sends a message with the technical details and a recovery mode link to that address.
3. A screenshot that shows the whole screen
Capture the entire window, including the address bar, not a tight crop of the error. The address bar shows the URL and whether you are on https; the rest of the screen shows whether you are logged in, which browser you use, and what else is on the page. For problems that involve several steps, a short screen recording is even better. Phones and computers can both record the screen without extra software.
4. What you were doing
Write the steps the way you would tell a colleague. “I went to the Book Now page, chose Tuesday, filled in the form, pressed Submit, and the button spun for a while, then nothing happened. No email arrived.” Steps are what let someone repeat the problem on purpose.
5. When it started, and what changed around then
This is often the single most useful line. Did anyone update plugins, the theme or WordPress? Install something new? Change hosting plan, renew the domain, move the DNS to a new provider, or switch on a CDN? Did the host send an email about a PHP upgrade or maintenance? Even “nothing that I know of, but it was fine last Friday” helps, because it gives a window to look at in the logs.
6. Who sees it, and where
- Device and browser. “iPhone, Safari” or “Windows laptop, Chrome” is enough.
- Logged in or not. Try the same page in a private browsing window. If it works there and not in your normal window, say so; that points to caching, cookies or something tied to your account.
- Other people. Ask a colleague or a friend on a different network to try. “It fails for me and my customer, but works for my sister” is real information.
7. How often it happens
Every time, sometimes, or once? Only at busy times of day? Only for orders with a certain payment method? Intermittent problems are the hardest ones to find, and a pattern, even a rough one, gives the developer somewhere to start.
8. What it is costing you
Be honest about impact so the work can be prioritised sensibly. “The blog layout looks odd” and “customers cannot pay” both deserve fixing, though one clearly comes first. If the site is completely down, or a shop cannot take orders, say that in your first line; our page on getting a downed site back up lists what to send in that case.
A template you can copy
Paste this into WhatsApp or an email and fill in the blanks. It takes about five minutes and usually saves several rounds of questions.
- Page address: https://…
- What happens: (what you see, and the exact error text)
- What should happen:
- Steps to see it: 1. … 2. … 3. …
- Started: (date or rough time) Changes around then:
- Device / browser: Logged in? Private window?
- Happens: every time / sometimes / once
- Impact: (lost orders, enquiries, or just appearance)
- Attached: full screenshot or recording
Extra details that help a great deal
The Site Health report
If you can log in, go to Tools > Site Health, open the Info tab and press Copy site info to clipboard. That copies a plain-text summary of your WordPress version, PHP version, active theme, plugins and server settings, which you can paste straight into a message. It answers a dozen questions a developer would otherwise ask. Our post on what the Site Health screen is telling you explains the rest of that screen.
The browser console
For problems with buttons, forms, sliders or anything that “does nothing”, press F12, click the Console tab, reload the page and repeat the action. A screenshot of any red lines there is very useful, even if they mean nothing to you.
Error logs, if you have them
Some hosts show recent PHP errors in the control panel. If debug logging was turned on, WordPress writes errors to wp-content/debug.log. Sending the last few lines from around the time of the problem is ideal. If you want to look yourself first, our guide on how to find and read error logs shows where they live.
Sharing access safely
A developer will often need to log in. Please do not send your own admin password, and never send passwords in the same message as the site address on an open channel if you can avoid it.
- Create a separate user for them from the Users menu in the dashboard, with its own email and password. Give it the Administrator role only if the work needs it; our post on WordPress user roles explains what each role can do. Delete or demote that user when the work is done.
- Hosting and FTP access are best shared as a separate FTP account or a collaborator login if your host offers one, so you can switch it off later without changing your main password.
- Use a password manager’s share feature if you have one, or send the password through a different channel from the username.
If a previous developer or agency still holds all the logins and you are not sure what you own, sort that out first. Our post about taking a site over from another developer lists what to collect.
What to avoid while you wait
- Do not keep retrying the thing that broke it. Re-running a failed update, re-importing a file or pressing Pay again can make the situation messier.
- Do not restore a backup without saying so. It may fix the problem, but it can also wipe orders, form entries or posts added since, and it removes evidence of what went wrong. If you do restore, tell the developer when and which backup.
- Do not install a new plugin to “fix” it. Adding one more plugin to a broken site is a common way to turn one problem into two.
- Do write down anything you try. “I deactivated the cache plugin at 3pm, no change” is helpful. Silent changes make the diagnosis much harder.
Working with a developer in another time zone
For owners in America or Britain hiring a team based in India, a full report in your first message matters even more, because a question sent in your evening may not be answered until your next morning. Our own team works on Indian time (IST), and clients outside India usually pay by PayPal or Wise. A complete first message, with access already set up, means work can often begin while you sleep instead of waiting for a reply.
For a symptom-by-symptom view of what different WordPress errors mean before you write to anyone, our guide to common WordPress errors is a good place to look up what you are seeing.
Sending it to us
If you have a problem now, the template above is exactly what we would ask for. Send it on WhatsApp or through the contact form, and if the site is down or a shop cannot take orders, put that first so we treat it as urgent. Before any change we back the site up, we test fixes on a copy whenever that is possible, and afterwards you get a plain explanation of the cause. Most day-to-day problems fall under our WordPress fixes, and we will tell you honestly if yours turns out to be something else.
Next in this series: WordPress Site Health Explained: Which Warnings Matter
