Visual testing for marketing teams
Your landing pages break for reasons that have nothing to do with you — a component change three teams away. How to get visual coverage on the pages that carry pipeline, without learning to write tests.
The uncomfortable thing about marketing pages is that they break for reasons that have nothing to do with marketing. Nobody touched the pricing page. An engineer three teams away changed the padding on a shared button, and now the plan comparison overlaps on tablet. You find out when a prospect mentions it, or you do not find out.
This piece is about getting coverage on the pages that carry pipeline. It does not require you to write tests or read code.
Why your pages break without you
- Shared components. Buttons, forms, navigation and modals are defined once and used everywhere. A change made for the product changes your landing page too.
- Design tokens. One colour or spacing value updated centrally propagates to every page that uses it, including pages nobody thought about.
- Content length. A headline two words longer wraps to a third line and pushes your call to action below the fold — on mobile, where most of your paid traffic lands.
- Third-party scripts. A chat widget, consent banner, or A/B testing tool updates itself and covers your primary button.
- Fonts. A web font loading late reflows the whole page. Common, invisible in testing, and it moves everything.
None of these appear in a CMS preview, because the CMS renders content, not the surrounding application.
Why nobody catches them
It is reasonable to assume engineering's tests cover this. They do not, and the reason is structural rather than negligent.
So the question "don't we have tests for this?" has an honest answer: yes, and they are blind to exactly this category. What visual bugs actually cost has the detail if you need to make that case internally.
What to protect first
Not everything. Rank by what a broken page costs you, which is roughly traffic multiplied by intent.
| Priority | Pages | Why |
|---|---|---|
| 1 | Paid landing pages | You are buying the traffic. A broken page burns budget in real time. |
| 2 | Pricing and sign-up | Highest intent on the site; a layout break here is lost pipeline. |
| 3 | Homepage | Highest volume, and the brand impression |
| 4 | Top organic pages | Compounding traffic you did not pay for |
| 5 | Everything else | Nice to have |
Five to ten pages is a sensible starting scope. And check them at mobile width first — most paid traffic is mobile, and mobile is where layout breaks are both most common and most expensive.
The one check worth asking for by name
If you get one thing from engineering, ask for this: an automated check that the page does not scroll sideways on mobile.
Horizontal scroll on a phone is the single most common and most damaging layout defect. One element a few pixels too wide makes the whole page slide, the layout feels broken, and users leave. It takes an engineer about ten minutes to add as an automated check, it produces almost no false positives, and it catches a genuinely frequent problem. The technical detail is in responsive visual testing if they ask.
What to ask for, in their language
A request framed this way is much more likely to get a yes than "can we test the marketing pages":
Can we add automated visual checks on our five highest-traffic pages, at mobile and desktop, running on every pull request? We want to be told when they change, not to block anyone's merge.
Three things make that easy to agree to: it is a small scope, it is non-blocking so it threatens nobody's release, and "tell us when it changes" is a much lower bar than "guarantee it never breaks".
What you will be asked in return
- "Which pages, exactly?" Have the list ready, with traffic numbers. This is the whole difference between a vague request and an actionable one.
- "What counts as broken?" Say: anything that changes where the call to action sits, hides it, or makes the page scroll sideways on mobile.
- "Who reviews the alerts?" Offer to do it. You are better at spotting a wrong-looking marketing page than an engineer is, and it makes the request cost them almost nothing.
- "How often will it fire?" Honestly: more than you want in the first fortnight while it is tuned, then rarely.
Things that will not solve this
- Checking it yourself after each release. You will do it for three weeks. Also you cannot check every breakpoint by eye, and a 6px shift is invisible from memory.
- Uptime monitoring. Tells you the page loaded, not that it looks right. A completely broken layout returns a healthy 200.
- Lighthouse and Core Web Vitals. Performance and accessibility, not whether your button is visible.
- Analytics alerts on conversion drops. These work, and they are the slowest possible detector — by the time the drop is statistically visible, it has been broken for days.
That last one is worth internalising. Conversion monitoring tells you something broke after you have already paid for the traffic that bounced. Visual checks tell you before the change ships. If you run a storefront, the catalogue-data and third-party-script problems get their own treatment in visual testing for ecommerce.
Frequently asked questions
Why do marketing landing pages break when nobody edited them?
Because they share components, design tokens, fonts and third-party scripts with the rest of the application. An engineer changing a shared button's padding for a product screen changes it on your landing page too, and a CMS preview will not show it because the CMS renders content, not the surrounding application.
Don't engineering's automated tests already cover the marketing pages?
Not for appearance. Automated tests assert on behaviour — that a button exists and can be clicked. They pass when that button is invisible, off-screen, white-on-white, or hidden behind a cookie banner. Visual regression testing is the category that checks how the page actually looks.
What is the single most valuable check for a marketing site?
An automated check that the page does not scroll horizontally at mobile width. It is the most common and most damaging layout defect, takes an engineer minutes to add, produces almost no false positives, and most paid traffic is mobile.