Skip to content

Technical SEO Audit Workshop · Writing tickets developers act on · lesson 10 of 14 · 12 min

Working with development teams: sprints, QA and release risk

SEO is a team sport

Even perfect tickets fail if they arrive at the wrong time, to the wrong person, in the wrong format. This lesson covers how to get Kiran Home's two developers to ship the roadmap — and how to avoid breaking something in the process.

Fit into their process, not yours

  • Use their tool (Jira, Linear, GitHub Issues, Trello). Tickets in a PDF appendix are not tickets.
  • Attend sprint planning (or send a short brief before it). Explain the top three tickets in five minutes: problem, evidence, expected outcome.
  • Respect estimation. Let developers size the work. If their estimate is much larger than you expected, ask what drives it — often there is a simpler implementation.
  • Offer alternatives. "If changing the filter component is too big this sprint, the robots.txt rule plus removing the 'popular searches' links gets most of the crawl benefit."

A definition of done for SEO-affecting changes

Agree a short checklist with the team and add it to their pull request template. For Kiran Home:

SEO checks for any change touching templates, routing, redirects or robots:
[ ] Status codes correct for new/changed URLs (200/301/404 as intended)
[ ] Canonical: one, absolute, self-referencing (unless specified), in raw HTML
[ ] Meta robots / X-Robots-Tag: no unexpected noindex/nofollow
[ ] hreflang set complete and reciprocal for affected templates
[ ] Internal links are anchor elements with href
[ ] Structured data valid (Rich Results Test on one URL per template)
[ ] robots.txt unchanged unless ticket says otherwise
[ ] No LCP image lazy-loaded; no new layout shift

Automate what you can

Manual checks do not scale. Suggest lightweight automation that developers are comfortable with:

  • Template tests asserting canonical, robots meta and hreflang output for sample routes.
  • A robots.txt check in CI that fails the build if production robots.txt contains Disallow: / or differs from an approved version.
  • Lighthouse CI or similar on key templates, with budgets for LCP and CLS in the lab.
  • Post-deploy smoke test requesting ten critical URLs and asserting status codes and key tags.
# post-deploy smoke test sketch
for url in / /en-ae/products/brass-lantern-large/ /en-gb/collections/cushions/; do
  code=$(curl -s -o /tmp/p.html -w "%{http_code}" "https://www.kiranhome.example$url")
  grep -q 'name="robots" content="noindex' /tmp/p.html && echo "NOINDEX on $url"
  echo "$code $url"
done

QA on staging

Before each release:

  1. List-crawl the URLs affected by the tickets on staging (with authentication).
  2. Check acceptance criteria per ticket and record pass/fail in the ticket.
  3. Diff against the pre-change crawl to catch unintended side effects (for example, a canonical fix that also changed trailing-slash behaviour sitewide).

Release risk management

Some SEO changes are high-risk: robots.txt edits, sitewide canonical logic, redirects in bulk, and changes to rendering. For these:

  • Deploy at a time when someone can monitor (not late on a Thursday before Eid holidays or a bank-holiday weekend).
  • Have a rollback plan written in the ticket.
  • Monitor logs and Search Console for 48–72 hours afterwards.
  • For robots.txt, check the Search Console robots.txt report to confirm Google fetched the new version.

Handling pushback

| Pushback | Productive response | |---|---| | "Google can handle it" | "Sometimes — here is the Search Console evidence that it currently isn't." | | "It's just SEO, it can wait" | Tie it to revenue: "These are the best-selling products not crawled in four weeks." | | "Our framework does it automatically" | "Great — here is a staging URL where the output differs; can we check the config?" | | "Too big for this sprint" | Offer a smaller first step that captures most value. |

Hands-on: an SEO smoke test in GitHub Actions

Turn the post-deploy smoke test into a CI job that runs after every production deploy (adapt for GitLab CI, Bitbucket Pipelines or your platform):

# .github/workflows/seo-smoke.yml
name: SEO smoke test
on:
  workflow_dispatch:
  deployment_status:
jobs:
  smoke:
    if: github.event_name == 'workflow_dispatch' || github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install requests beautifulsoup4 pytest
      - run: pytest -q tests/seo_smoke.py
        env:
          BASE_URL: https://www.kiranhome.example

# tests/seo_smoke.py
import os, requests, pytest
from bs4 import BeautifulSoup
BASE = os.environ["BASE_URL"]
CASES = [("/", 200), ("/en-ae/products/brass-lantern-large/", 200), ("/en-gb/collections/cushions/", 200),
         ("/old-shop/lantern.html", 301)]

@pytest.mark.parametrize("path,expected", CASES)
def test_status_and_tags(path, expected):
    r = requests.get(BASE + path, allow_redirects=False, timeout=20)
    assert r.status_code == expected
    if expected == 200:
        s = BeautifulSoup(r.text, "html.parser")
        robots = (s.find("meta", attrs={"name": "robots"}) or {}).get("content", "")
        assert "noindex" not in robots.lower() and "noindex" not in r.headers.get("X-Robots-Tag", "").lower()
        canon = s.find("link", rel="canonical")
        assert canon and canon["href"] == BASE + path

def test_robots_not_blocking_site():
    txt = requests.get(BASE + "/robots.txt", timeout=10).text.replace("\r", "")
    assert "\nDisallow: /\n" not in "\n" + txt + "\n"

A failing run should notify the developer on call and the SEO lead — and the team should agree in advance whether a failure triggers rollback.

Worked example 2: a UK agency and a retained dev team

A London agency (illustrative) works with a client's outsourced developers in another time zone. What made it work: tickets in the developers' Jira with the template from Lesson 4.1; a 15-minute weekly call to walk through the top three; the smoke test above in their pipeline; and an agreed "SEO-sensitive change" label that triggers a check before release. Ticket cycle time fell because questions were answered in the ticket, not over email.

Common mistakes

  • Sending tickets directly to developers and bypassing their lead or product owner.
  • Assuming a merged PR means the issue is fixed in production.
  • Treating developers as an audience for SEO lectures instead of partners with constraints.

Video lecture: Working with development teams: sprints, QA and release risk

Lecture coming soon · 13 chapters · about 8 minutes. Read the full transcript below.

  1. Working with development teams
  2. Fit their process
  3. SEO definition of done
  4. Automate checks
  5. Hands-on: CI smoke test
  6. Staging QA
  7. Release risk
  8. Handling pushback
  9. Example 1: Kiran Home's smaller first step
  10. Example 2: remote dev team (illustrative)
  11. Watch me do it: smoke test in the pipeline
  12. Make developers' lives easier
  13. Mistakes, recap, try this now

Lecture transcript

Working with development teams

Even perfect tickets fail if they arrive at the wrong time, to the wrong person, in the wrong format. SEO is a team sport, and developers are your most important teammates. In this lecture you'll learn how to fit into a development team's process, agree an SEO definition of done, automate checks in CI, run QA on staging, manage release risk, and handle pushback productively, all in the context of getting Kiran Home's two developers to ship the roadmap.

Fit their process

Fit into their process, not yours. Use their tool, whether that's Jira, Linear, GitHub Issues or Trello; tickets in a PDF appendix aren't tickets. Attend sprint planning, or send a short brief before it, and explain the top three tickets in five minutes: problem, evidence, expected outcome. Respect estimation: let developers size the work, and if an estimate is bigger than you expected, ask what drives it, because there's often a simpler implementation. And offer alternatives when capacity is tight.

SEO definition of done

Agree a definition of done for SEO-affecting changes, and add it to the pull request template. For Kiran Home: status codes correct for new or changed URLs. One absolute, self-referencing canonical in the raw HTML. No unexpected noindex or nofollow. hreflang complete and reciprocal on affected templates. Internal links as anchors with hrefs. Structured data valid on one URL per template. robots.txt unchanged unless the ticket says otherwise. And no lazy-loaded LCP image or new layout shift.

Automate checks

Automate what you can, because manual checks don't scale. Template tests that assert canonical, robots meta and hreflang output for sample routes. A robots.txt check in CI that fails the build if production robots.txt contains a sitewide disallow. Lighthouse CI or similar on key templates, with budgets for LCP and CLS in the lab. And a post-deploy smoke test that requests ten critical URLs and asserts status codes and key tags.

Hands-on: CI smoke test

Hands-on. The lesson text has a GitHub Actions workflow that runs after a successful deployment, installs Python and pytest, and runs a smoke test file. The tests request key URLs without following redirects, check the expected status, confirm there's no noindex in meta robots or the X-Robots-Tag header, confirm the canonical equals the page's own URL, and check robots.txt isn't blocking the whole site. Adapt it for GitLab, Bitbucket or whatever the team uses. The important part is agreeing what happens when it fails.

Staging QA

QA on staging before each release. List-crawl the URLs affected by the tickets on staging, with authentication. Check acceptance criteria per ticket and record pass or fail in the ticket itself. And diff against the pre-change crawl to catch unintended side effects, for example a canonical fix that also changed trailing-slash behaviour sitewide. Side effects are where most SEO regressions come from.

Release risk

Release risk management. Some SEO changes are high-risk: robots.txt edits, sitewide canonical logic, bulk redirects, rendering changes and CDN bot rules. For these, deploy when someone can monitor, not late on a Thursday before Eid holidays or a bank-holiday weekend. Write a rollback plan in the ticket. Monitor logs and Search Console for forty-eight to seventy-two hours. And for robots.txt, confirm in Search Console's robots.txt report that Google fetched the new version.

Handling pushback

Handling pushback. When someone says Google can handle it: sometimes, and here's the Search Console evidence that it currently isn't. When someone says it's just SEO, it can wait: tie it to revenue, these are the best-selling products not crawled in four weeks. When someone says our framework does it automatically: great, here's a staging URL where the output differs, can we check the config? And when someone says it's too big for this sprint: offer a smaller first step that captures most of the value.

Example 1: Kiran Home's smaller first step

Worked example one: Kiran Home. The developers say the facet change is too big for this sprint. The SEO lead offers a smaller first step: remove the popular searches widget links and add the robots.txt rule for search and sort parameters, after confirming no approved pages use them. That captures most of the crawl benefit in a day, and the full component change moves to the next sprint.

Example 2: remote dev team (illustrative)

Worked example two, illustrative. A London agency works with a client's outsourced developers in another time zone. What made it work: tickets in the developers' Jira using the template from the previous lesson; a fifteen-minute weekly call to walk through the top three; the smoke test in their pipeline; and an agreed SEO-sensitive change label that triggers a check before release. Ticket cycle time fell, because questions were answered in the ticket, not over email.

Watch me do it: smoke test in the pipeline

Watch me do it. I'll add the SEO smoke test to Kiran Home's pipeline with the senior developer. Step one: we open the repository together and create a tests folder file called seo smoke. I paste the test from the lesson and fill in the cases: the home page, a UAE product, a UK category, and one old URL that must return three-oh-one. Step two: we run it locally against production. Four pass. One fails: the UAE product's canonical doesn't equal its URL. Of course. That's RC one, not yet fixed. We mark that case as expected to fail until the fix ships, with a comment linking the ticket. Step three: we add the GitHub Actions workflow file, triggered after a successful deployment and manually. Step four: we push to a branch, and the developer triggers it by hand. It runs in about a minute and shows the expected failure clearly. Step five: we agree the response. If a test fails after a production deploy, the on-call developer and I are notified in the team channel, and a sitewide noindex or robots failure means immediate rollback. Step six: we add three SEO checks to the pull request template. The whole session takes forty minutes and becomes part of every release from now on.

Make developers' lives easier

Here's something that transforms relationships with development teams: make their lives easier, not harder. Give them test URLs, not just rules. Give them the exact command to verify, so they can check their own work before QA. Group SEO work by component so they touch each file once. Celebrate shipped fixes publicly, with the before and after chart, and credit the developers by name in the stakeholder report. Teams that feel their SEO work is noticed and valued prioritise it. Teams that only hear from SEO when something's broken quietly deprioritise it.

Mistakes, recap, try this now

Common mistakes. Sending tickets directly to developers and bypassing their lead or product owner. Assuming a merged pull request means the issue is fixed in production. And treating developers as an audience for SEO lectures, instead of partners with constraints. Recap: fit their process, agree a definition of done, automate checks in CI, QA on staging, manage risky releases, and meet pushback with evidence and smaller steps. Try this now: add three SEO checks to your team's pull request template, and propose the smoke test for your pipeline.

Key takeaways

  • Work inside the team's tools and ceremonies; brief sprint planning with problem, evidence and outcome.
  • Agree an SEO definition of done and add it to pull request templates.
  • Automate checks for canonicals, robots directives and robots.txt in tests, CI and post-deploy smoke tests.
  • Treat robots.txt, canonical logic, bulk redirects and rendering changes as high-risk releases with rollback plans.

Try it

Draft an SEO definition-of-done checklist and a post-deploy smoke test list of ten critical URLs for a site you work on.