A useful website update request tells the person doing the work where to look, what should change, and how to tell when it is right. You do not need technical vocabulary. You need the details that remove guesswork.
If a routine update keeps bouncing between inboxes, the missing piece is often an exact page address, final copy, or a person who can approve it. Here is how to request website updates clearly, with examples you can adapt to your own business.
Start with the outcome and the exact page
Describe what a visitor should be able to understand or do after the change. Then paste the full URL of every affected page. “The services page” may refer to a main overview, an individual service, or a page that is no longer in the menu.
Identify the section by its heading and, if useful, attach an annotated screenshot. Mention whether the same detail appears elsewhere, such as the footer, a download, or a form confirmation. A screenshot helps locate the change; written instructions make its meaning clear.
Separate current content from replacement content
For a text change, provide the current wording and the exact approved replacement. Say whether the replacement is final or still needs editing. If you want help writing it, include the facts, audience, and purpose rather than describing unfinished copy as ready to publish.
For links and buttons, specify both the visible label and the destination. For an image, provide the original file, where it belongs, any crop preference, and confirmation that your business has permission to use it.
Explain what the image needs to communicate. W3C’s image guidance treats alternative text according to the image’s purpose; informative, functional, and decorative images can need different treatment. Let your provider know the intended meaning rather than adding a string of keywords.
Name the approver and give a real deadline
Identify one person who can consolidate feedback and approve the result. If service, pricing, or other factual details need internal checking, complete that review before presenting them as final.
Include the requested publication date, time, and time zone when timing matters. Explain the reason, such as an offer beginning or a printed brochure going out. Distinguish a firm deadline from a preference, and ask the provider to confirm feasibility.
State whether the change can be published once checked or whether you need to review a preview first. A deadline and permission to publish answer different questions.
Example of a complete routine update request
The following is a hypothetical request using a reserved example address and fictional project details.
- Subject: Update the consultation information before the November brochure goes out.
- Page: https://example.com/services/consultations/
- Section: “What happens next,” directly above the inquiry button.
- Current copy: “Call the office to arrange your consultation.”
- Replace with: “Tell us what you would like help with using the inquiry form. Our team will contact you to discuss the next step.”
- Button: Replace “Call us” with “Send an inquiry” and link it to https://example.com/contact/.
- Asset: Use consultation-room-approved.jpg from the shared project folder. Usage permission is confirmed. Keep the seating area visible in the crop.
- Image purpose: Show the consultation room. Proposed description: “Two chairs beside a round table in the consultation room.” Please check the final crop.
- Approval: The operations lead will provide one consolidated response to the preview. Wait for that approval before publishing.
- Deadline: Please publish by 16:00 UTC on 17 November 2026, subject to approval. The brochure is being distributed the following morning. Please confirm whether this is feasible.
- Acceptance checks: The approved text and image appear on phone and desktop, the button reaches the contact page, and a labeled test inquiry reaches the agreed inbox.
Attach the file you named or provide a working link with the necessary access. “See attached” is less helpful when the attachment is still on your desktop.
Report a bug with what happened and what you expected
A bug report needs observations before theories. Describe the steps you took, the result, and what should have happened. Include the device, browser, approximate time with time zone, and whether it happens consistently.
Here is a hypothetical report:
- Page: https://example.com/contact/
- Steps: On an iPhone using Safari, open the page, complete the required fields with test data, and tap “Send inquiry.”
- Expected: A confirmation message appears after a successful submission.
- Actual: The button shows “Sending” and stays there. No confirmation appears. Reproduced twice at approximately 14:20 UTC on 10 November 2026.
- Evidence: Attached screen recording with test information only. The phone’s software and browser version are included in the support ticket.
- Impact: Inquiry completion may be affected on this device. We have not confirmed whether submissions reach the inbox or whether other devices are affected.
- Contact: The designated website coordinator can confirm test-email receipt and answer questions.
Avoid including passwords, payment details, or real customer submissions in screenshots. Use an agreed secure channel if diagnosis genuinely requires private information.
Make review and testing part of the request
Keep feedback in one place. Refer to the page and section, describe the requested correction, and resolve conflicting comments internally. If the request changes, identify which instruction replaces the earlier one.
Before signing off, read the published copy, check the affected links, and try the intended visitor task. Include a phone check and basic keyboard interaction where relevant. W3C’s initial accessibility checks can help guide a first review, although they do not establish complete accessibility.
Ask for confirmation of what was changed, what was tested, and anything still outstanding. New layouts or functionality may need a separate scope and estimate; giving the goal early helps that discussion happen before work starts.
Send the details and start the conversation
Imbark provides ongoing website updates and troubleshooting. For a wider change, our website design process explains how we approach the work.
Send us the page address, the change or problem, and your target date. Include approved copy or the steps that reproduce the issue. That gives us something concrete to work from.
