“Could you sort out our SEO?” almost always evaporates without changing anything. Not because engineers are unwilling, but because the sentence contains no starting point. Without an address, a piece of evidence and a target state, there is nothing to begin.
This part is how you actually use the previous six. The purpose of understanding the mechanics is not to fix things yourself — it is to write a request that can be fixed.
Five lines
The two most often missing are the observation and the verification. Without the first, the engineer spends the time reproducing your problem; without the second, nobody can tell when it is finished, and the work ends in another round of “so is it fixed?”.
Keep observation separate from interpretation
The most valuable line in any request is a plain description of what you saw. Lead with your interpretation and the engineer spends their time testing your theory; if the theory is wrong, the whole investigation points the wrong way.
In practice it reads like this. “The filter URLs under /products/ are being indexed” (observation). “Duplication reasons have risen in the pages report since last month, and a site: search shows URLs with ?sort= in them” (evidence). “Please make the parameter URLs point at the parameter-free address as canonical” (desired state). “After release, check the canonical on those URLs and watch the duplication reasons in next month’s report” (verification).
One change per request
Bundle several items into one request and you lose both the ability to say what worked and the unit you would roll back. Change five things, watch a metric drop, and you now have to undo them one at a time to find out which.
Forwarding a tool’s report wholesale causes the same problem. Those reports mix items that do not apply to your site with items that barely matter, and choosing between them is the marketer’s judgement. Hand that judgement over and the engineer will reasonably work from the top down — which has no particular reason to match your priorities.
Three things to check before asking
Three checks get you halfway to a finished request. Run URL Inspection to see which stage it stopped at (part one), open the sitemap to see whether the address is listed (part three), and look at the live result to see how it appears (part two). Attach those three and the engineer skips reproduction entirely.
Turning requests and releases into one flow continues in the development workflow archive, and the order we work in — including what we accept as proof that something is done — is published on our process page.
Next part
The final part compresses all of this into something repeatable every month: eight checks, thirty minutes, in a fixed order so it becomes a habit rather than a project.