Is It Out of Scope? — SEO & marketing
Is fixing bugs found after sign-off out of scope for a SEO / marketing project?
For technical SEO implementations specifically, a genuine defect (a tag implemented incorrectly, a redirect that doesn't work as specified) is typically covered by warranty. A new issue unrelated to what was delivered is a separate, billable request outside the retainer.
SEO engagements sometimes include a technical implementation component — schema markup, redirect rules, canonical tags, sitemap configuration — that gets formally signed off once it's live and verified. Later, something looks wrong: a rich result stops appearing, a redirect throws an error, structured data fails validation. Whether that's a covered fix depends on whether the implementation itself was flawed or something else changed underneath it.
Is it out of scope?
If the implementation genuinely doesn't match the spec that was signed off — the schema markup has an error, a redirect rule was configured wrong — that's typically a covered defect. If the issue traces back to something outside the SEO team's control — a site redesign, a CMS update, a change search engines made to how they render a feature — that's a new diagnosis-and-fix request outside the retainer's scope.
Clause typically implicated
Clause typically implicated
Warranty clause→ — Covers defects in the signed-off technical implementation for a defined window; issues with an external cause fall outside it even when they affect the same feature.
Example contract wording
Example contract wording (illustrative, not legal advice)
Let me check what's going on before committing to anything. If the schema/redirect implementation itself has an error, that's covered under warranty and I'll fix it at no charge. If it turns out to be caused by [the recent redesign / a CMS change / something on the search engine's side], I'll explain what I'm seeing and quote the fix as separate work.
How MarginFlow flags it
MarginFlow checks the request against the warranty terms and, where the email itself doesn't make the cause obvious, keeps its confidence appropriately low rather than defaulting to "covered" or "not covered." The explanation names what would need confirming (implementation error vs. external change) so the account manager knows what to check before responding to the client.