Fix what blocks your visitors.

How to describe a website bug so it can be repaired efficiently

Share the public address of the affected page, the approximate screen size, and the browser or device where the issue happens. Describe what you expected, what actually occurred and the shortest steps that reproduce it. Screenshots can be useful when they contain no personal or confidential information. For example, a menu might open correctly on desktop but cover a form on a small phone. A language toggle might make the text read right-to-left while leaving navigation controls in the wrong order. Those are different symptoms requiring different acceptance checks.

Before work begins, agree on which files may be edited, how the page will be tested, and whether your organization can provide a safe test environment. Avoid sending passwords or private database exports with the initial brief. A limited repair should preserve existing content and unrelated behavior, and the handover should explain the change and any known limitations. Changes to authentication, transactions, payment processing, databases or production infrastructure need their own authorization, security checks and rollback plan. The current site prepares a project description only; it does not receive source code or deploy fixes automatically.