CI/CD for Marketing: The Tests Worth Running and the Deploy Worth Trusting

A nurture sequence went to eleven thousand people with a link to a pricing page renamed six weeks earlier. Every click landed on a 404, and nobody noticed until a customer success manager forwarded a reply asking whether the company had gone out of business.

A link checker would have caught that in two seconds. It costs nothing, and nobody ran it because there was nowhere to run it. That is what a marketing pipeline is: somewhere for the cheap checks to live, so the expensive mistakes stop reaching customers. Version control gives you the diff. CI reads the diff before a human does.

Cheap checks run first, and they catch most of it

Order matters more than coverage. Put the fast, deterministic checks at the front so a broken pull request fails in thirty seconds, not four minutes.

lint:
  links        internal paths resolve, external return 200
  utm          source, medium and campaign on every outbound URL
  spell        dictionary + product glossary, de-DE and en-GB
  banned       terms from checks/banned-claims.txt
  weight       hero images under 200KB, nothing over 1MB
  schema       JSON-LD validates, FAQ blocks have Q and A
  frontmatter  required keys, no [NEEDS-DATA] in ready files

None of these is clever, and all of them fail in production regularly. Internal link checking is the highest-yield check in marketing CI, because marketing sites rename URLs constantly and nothing tells the person who wrote the email. Run it against the built site, so a slug changed in the same pull request still fails.

The UTM check quietly saves your reporting. A missing utm_medium on one variant creates a row in the analytics tool that looks like a different channel, and three weeks later somebody is explaining why direct traffic grew. Image weight belongs in the same stage, because no reviewer notices a filesize in a diff and a 3.4MB hero costs real conversion on mobile.

The expensive checks earn their minutes

Then come the three checks that need judgement.

The claims check. Keep a file of approved claims: each claim, its evidence, its source, its expiry date. The check extracts factual assertions from the changed copy and matches each against an entry. "Trusted by 400 teams" fails if the file says 340, or the entry expired in March. This is what keeps legal out of the review queue: they review the claims file quarterly instead of every ad variant. Its failure mode: it misses implied claims, because "the only platform that does X" gives an extractor no number to check.

The tone check. Feed the diff and the voice file to a model and ask for violations with line references, not a score. Scores are uninterpretable and people learn to ignore them. "Line 14 uses 'revolutionise', which the voice file bans" is actionable. Run it as a warning for the first month: an untuned tone check produces noise, and a gate that cries wolf is routed around.

The eval set, for anything AI-generated. If an agent drafts copy, you need a fixed set of inputs and assertions about the output. Twenty to forty cases is enough. Does it stay under the character limit for the placement, does it name the ICP correctly, does it avoid claims absent from the approved file, does it use the German formal register the audience file calls for. Set a pass threshold, 90 per cent say, and fail below it. The score on one run does not matter. What matters is that when someone edits a prompt or a context file, you find out whether they made it worse. Without an eval set, prompt changes are superstition.

A merge has to reach the platform, not just the branch

Deployment in marketing is four or five targets, each with its own failure mode. The site is easy: a merge triggers a build and the host swaps the deployment atomically. Ad platforms are harder. Meta, Google and LinkedIn all expose campaign, ad set and creative endpoints, so a merged variant can be created through the API, but creation is not activation. Create the entity paused and let a human unpause it. An ad going live automatically at merge time is a budget event with nobody watching, and the first time that happens at 2am you will change the policy anyway.

Email and sequencing tools follow the same pattern: the pipeline updates the definition, a person triggers the send. CRM field mappings, scoring rules and routing logic deploy cleanly because they are configuration rather than content. The ad engine is this wiring built out, platform APIs and ledger on one deploy path. Where a platform has no API, and review sites often do not, the pipeline opens a task with the diff attached.

Every pull request gets a URL

Preview environments are the highest-value addition after the link checker. Netlify, Vercel and Cloudflare Pages build a pull request to its own URL automatically, and review quality changes immediately: the reviewer stops reading markdown and starts looking at the page, on a phone, with real typography and real crops. It also widens who can review: a founder who would never open a diff will click a link, and review latency drops without anyone being asked to work differently.

The rollback path is the part people skip

Everyone builds the deploy. Almost nobody tests the revert. Then something goes out wrong at 4pm on a Friday and the team discovers that reverting the commit rebuilds the site correctly, does nothing whatsoever to the ad platform, and leaves the sequence in the sending tool exactly as it was last written.

Test it on a quiet Tuesday. Make a trivial change, merge it, revert it, watch each target and time the whole thing. That number is your real worst case, usually longer than anyone assumed. Then write down what the revert cannot undo, because there are always three things: spend that already happened, emails already delivered, and platform state a revert does not reset, such as an ad set's learning phase.

For email the rollback is not a revert at all. It is a decision about whether to send a correction, and it needs a named owner and a pre-written template, because it gets made by whoever is nearest at the time.

What CI cannot catch, and the difference that matters

A pipeline verifies properties, not quality. It can confirm that every claim matches the approved file, that links resolve, that the voice file is respected and the schema is valid. It cannot tell you the ad is aimed at the wrong buyer, the offer is unconvincing, or the campaign answers a question nobody asked.

It also misses errors living between correct things. Two paragraphs individually true and jointly misleading pass every check. A landing page whose headline and call to action describe different products passes, because no check knows what the page is for.

Green means safe to ship, not worth shipping. The pipeline removes the errors that waste review time, which lets human review spend attention on what only humans can judge. Teams that confuse the two ship a great deal of well-formed, compliant work nobody responds to. That problem sits upstream of CI, and it is a positioning problem rather than a pipeline problem.

Frequently asked questions

What checks should a marketing CI pipeline run?

Run the cheap deterministic checks first so failures return in seconds: link resolution against the built site, UTM parameters matching the tracking plan, spelling against a product glossary, banned terms, image weight limits, schema validation and complete frontmatter. Then the checks needing judgement: factual claims matched against an approved claims file with evidence and expiry dates, a tone check reporting line-level violations rather than a score, and an eval set with a stated pass threshold for AI-generated copy.

How does a merge actually deploy a marketing change?

The site rebuilds and the host swaps the deployment atomically. Ad platforms expose campaign, ad set and creative APIs, so a merged variant is created through the API, but it should be created paused so a human decides when spend starts. Email and sequencing tools update the definition while a person triggers the send, and CRM field mappings, scoring and routing rules deploy cleanly because they are configuration rather than content.

Why do marketing teams need preview environments?

Because reviewers judge pages badly from markdown and well from a page. A build per pull request, which Netlify, Vercel and Cloudflare Pages provide automatically, gives every change its own URL, openable on a phone with real typography and real crops.

Does a passing pipeline mean a campaign is good?

No. A pipeline verifies properties, not quality. It confirms that claims are approved, links resolve, tone rules are respected and schema is valid, but it cannot tell you the ad targets the wrong buyer, the offer is weak, or the headline and the call to action describe different products. Green means safe to ship, not worth shipping.