On a news site traffic and revenue are not the same thing, but they are linked — and the link works in reverse too. More ad slots raise RPM in the short term; the page slows down; Core Web Vitals degrade; Discover and Top Stories visibility drops; traffic drops; total revenue drops. At Magazin Burada I had to manage both ends of this loop, as SEO consultant and monetisation manager at once.
Three situations where RPM lies
- When the traffic mix shifts: If Discover traffic falls and search traffic rises, RPM can look up — because the remaining traffic browses more "valuable" pages. RPM rising while total revenue falls is a red alarm that shows green on the dashboard.
- When viewability inflates: As content pushed below the fold drives users away, the patient minority that remains sees more ads, so per-page revenue rises. The metric improves, the business deteriorates.
- In seasonal effects: Q4 advertiser demand lifts everything. A bad placement change made in October hides in the shadow of rising CPMs for months; the invoice arrives in January.
News SEO is different
Classic SEO's "keywords and backlinks" logic doesn't work alone in news. Speed, structured data (NewsArticle), publishing cadence, internal linking and Discover-friendly visuals and headlines are decisive. Discover traffic is not a keyword ranking, it is a signal; if the site is slow, the signal cuts out.
The fragility of Discover
Discover is news sites' largest and least reliable traffic source: one week it carries half your traffic, the next it quietly withdraws. Living with that fragility means not ignoring it but not leaning on it. In practice we did three things: kept the publishing rhythm fixed independent of Discover (production doesn't oscillate when the algorithm does), invested in evergreen content types that grow search and direct traffic, and imposed a no-panic-changes rule during big dips — because most Discover drops come not from something you did but from the algorithm's own swing, and the panicked template change is what causes the real damage.
Core Web Vitals problems specific to news sites
- CLS — jumping content: The chief culprit is ad slots without reserved space. Fixed height reservations on every slot are the cheapest CLS fix; if no ad fills, the space stays empty and nobody dies.
- LCP — the late cover image: In news the largest visual element is almost always the cover photo. Priority loading (fetchpriority), correct sizing and modern formats solve most of it.
- INP — script clutter: Third-party scripts accumulated in the template over the years (old analytics snippets, social widgets, abandoned tools) lock up interactivity. A "script inventory" every six months, deleting the unused, is not maintenance — it is revenue work.
Ad loading order
The biggest win came not from removing ads but from changing the loading order: visible content first, ads after, with lazy loading. Unnecessary scripts were purged from the template. Better Core Web Vitals with the same number of ads is possible.
How to run a placement test
Placement decisions are made in tests, not meetings. The working routine: one variable at a time (a slot's position or its existence), template-scoped rollout (test on one content template, not sitewide), at least two weeks of data (let the weekday/weekend cycle complete), and a joint reading of three metrics — RPM, page speed, pages per session. No placement becomes permanent unless two of the three improve. "RPM rose but users browse fewer pages" is not a gain; it is erosion.
One dashboard
Traffic (Search Console, GA4), speed (CrUX) and revenue (AdSense/programmatic RPM) went onto one dashboard. When a placement test ran, all three metrics were read together. "RPM went up" stopped being sufficient grounds for a decision on its own.
The anatomy of a test: a worked scenario
Let me make it concrete. Say the test is removing the ad slot right after the first paragraph on the article template. Week one: the change runs only on the article template; homepage and gallery templates untouched. Three lines are watched on the dashboard: article RPM, article LCP/CLS, and the rate of moving to a second page. By the end of week two the table is clear: RPM dipped somewhat, page speed improved markedly, pages per session rose. Step three is arithmetic: does the extra pageview volume cover the revenue lost per slot? If yes, the change becomes permanent and moves to the next template; if not, the slot returns — but lazy-loaded this time. That whole loop — one variable, template scope, two weeks, three metrics, arithmetic — is the template for every placement decision. It replaces the meeting-room sentence "I don't think we should remove that ad".
Speed–revenue audit checklist
- Does every ad slot have a fixed height reservation? (CLS)
- Is the cover image priority-loaded and correctly sized? (LCP)
- Has a third-party script inventory been done in the last six months? (INP)
- Are below-the-fold ads lazy-loaded?
- Are traffic, speed and revenue read on one dashboard?
- Are placement tests single-variable and at least two weeks long?
- Is Discover's share of total traffic tracked, with a dependency plan?
The lesson
Monetisation is an SEO decision and SEO is a monetisation decision. Run them with separate teams, separate dashboards and separate targets, and they will eat each other. Sit them at the same table. And at that table ask a single question: does this change increase total revenue a month from now — not today's RPM.
Short questions, short answers
Speed first or revenue first? A false dilemma: measurement first. Until the three metrics read on one dashboard, every decision is a guess.
Are AMP-style solutions mandatory? No; a well-optimised normal mobile template is enough. What decides is not the format but the ad loading order and script discipline.
Are video ads worth it? The format that raises RPM fastest and sinks the page fastest at the same time. My one rule for video: a non-autoplay, space-reserved, lazy-loaded player — or none at all.