--- title: "Before you ask someone to fix your website: what to send" description: "A practical checklist for asking a developer to fix your website: URL, symptoms, screenshots, timing, recent changes, versions, access, priorities and staging." url: "https://djwp.xyz/blog/what-to-send-before-website-fix/" date_modified: "2026-09-22" Category: "Website care" --- # Before you ask someone to fix your website: what to send > Send the exact URL, what you expected and what happened, steps to reproduce, screenshots with the full error text, when it started and what changed around then. Add the CMS, theme, PHP and hosting details, your priorities and whether a staging copy exists. Share passwords later, through a secure channel, using a separate account. ## 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](/glossary/#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](/glossary/#noindex) rule. If it is about speed, say which pages and which devices, and include the [Core Web Vitals](/glossary/#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](/glossary/#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](/services/website-fixes/) page. **A short template.** If you prefer one, these lines cover the essentials: - Site and page: the full URL. - Problem: what happens, and what should happen instead. - Steps: what to click or enter to see it. - Who and where: all visitors, mobile only, one browser. - Since when, and what changed around then. - Platform: CMS and version, theme, PHP, hosting. - Priority: most urgent first, plus any deadline. - 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](/services/support-maintenance/). When you are ready, [send us the link and a short description](/contact/). ## Key takeaways - The exact URL, steps to reproduce and the full error text save more time than a long description.- When the problem started and what changed around then are often the fastest route to the cause.- WordPress's Site Health screen can copy versions, theme and plugin details in one click.- Share access through a separate account and a secure channel, and test fixes on a staging copy first. ## Questions ### Do you work on websites built by other developers? Yes. Most fix-and-improve projects start with someone else's code. We review it first, explain what we find and only then estimate the work. ### Should I give a developer my own admin password? Better not. Create a separate administrator account, share it through a secure channel and delete it when the work is done. Access is then easy to revoke, and separate accounts support attribution when activity logging is enabled. ### What if I don't know my plugins or versions? That is fine. In WordPress, Tools → Site Health → Info lists versions, the theme and active plugins, and can copy them in one click. If you cannot reach the admin, send the URL and a description, and we will start from what is visible. ## Sources - [Site Health screen (WordPress documentation)](https://wordpress.org/documentation/article/site-health-screen/)- [Debugging in WordPress (WordPress Developer Resources)](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) --- **[Read full article: Before you ask someone to fix your website: what to send](https://djwp.xyz/blog/what-to-send-before-website-fix/)**