You saw that right. There’s a weird split within SEMrush that’s bitten more than a few folks trying to diagnose why their keyword research data looks like it came from two parallel timelines. The problem is their interface vs API vs export don’t always agree. If you’re running an SEO audit through the interface, you’ll often see slightly different keyword volumes—sometimes different enough to make “Keyword A” look better than “Keyword B”, but once those land in your CSV export or if you query the API, the numbers jump or shrink by a border-line deceptive margin.
I once spent an entire Friday combing through a spreadsheet trying to explain why our client’s #3 ranking was driving less traffic this quarter—we discovered the live GUI report was using outdated keyword volume estimates. Exported raw data showed the traffic curve as it really was… just not updated in their frontend cache. I had to put a screen-recording in the client deck showing the GUI and CSV side-by-side.
Campaign Data Consistency (or Lack of It)
What really messes with repeatable workflows is SEMrush’s tendency to cache elements at unpredictable scopes. Like, say you’re comparing two projects across regions. You’d assume things like keyword difficulty or backlink trends would be relatively consistent across tabs, right? Not quite.
If you’ve ever flipped between two projects and noticed tiny flickers in your data—like a keyword volume that was “27.1” five minutes ago and now it’s “23.9”—you’re not losing your mind. It’s usually the variation between pulled live data and previously cached dashboard snippets. The interface doesn’t always invalidate old pulls between tab switches.
Try this:
Run the same Domain Overview on “project A” twice 15 minutes apart
Export both sets as CSV
Open them in a diff tool
You’ll sometimes get more than 5% variance in backlink totals and referring domains. Which doesn’t sound like much—until you pitch a growth increase to a client, and then a week later they log in and see less than what you promised.
Rank Tracking Is a Moving Target
SEMrush’s position tracking tool is useful, don’t get me wrong. But semi-frequently, you’ll notice SERP screenshots from “yesterday” that contradict their reported position index for that same date. Why? Because SEMrush doesn’t always pick up SERP features correctly.
Let’s say your URL is #2, but you’re behind a featured snippet and a map pack. Are you effectively #4 to a person scrolling down? Yep. But SEMrush sometimes ranks that as #2 based on organic index listing alone. Which doesn’t reflect how your users actually see things on mobile, where results look stacked, squished, and vaguely cursed.
“SERP Features not detected in snapshot”: buried in some JSON there was a flag marked false, even though the screenshot clearly showed 3 features above the client link. Interface: no warnings.
So if you’re tracking rank changes to correlate with CTR dips, triple-check that SEMrush isn’t mis-classifying rich snippets. Otherwise you’ll think a drop from #2 to #4 hurt conversions—when in reality, your spot didn’t even move, but a YouTube carousel showed up and ate all your clicks.
Keyword Magic Tool’s Relevance Is… Magic
This thing is like a beautiful mess. On some days, it feels like it reads your mind. On others, it returns garbage keyword tangents like “how to remove raccoons with lemon” for queries like “citronella lamp uses”.
The actual issue? Its relevance scoring algorithm gets wonky whenever you filter by Exact Match + Questions. You’d think limiting to more tightly scoped question-based terms would bump up relevance. Instead, the Scoring metric sometimes collapses, returning lower-score keys with good intent matches buried under irrelevant long-tails.
I found an edge case where adding a negative filter—opposite of what I wanted—actually pulled better matches to the top. I screenshot this for a client because it was so backwards, and I didn’t want them to think I was just stuffing in junk keywords.
It’s like removing “cook” tricked Magic Tool into going gear-first instead of recipe-first. And no, that’s not documented anywhere.
Historical Data Gets Flattened Post-Merge
If you’ve ever merged two SEMrush Projects (like one for desktop, one for mobile), you may notice your older snapshots quietly stop aligning. This is because their historical snapshots are normalized to whatever your current config is—not the original setup when the snapshot was taken. So your mobile SERP positions from 6 months ago? Retroactively adjusted to look more like your current device mix.
This really messed with one ad team we worked with. They were trying to compare mobile CTR trends over time. Except after the merge, historic mobile-only data got normalized into the joint segment. Result: the reported accurate mobile-based CTRs from last quarter were, on export, now “blended” with desktop impressions that didn’t even exist at the time.
It creates a data mirage. Accurate at point-in-time, but misleading after a config change. And there’s zero warning before that happens. You just… notice your old charts look different. And if you didn’t PDF them? Good luck explaining post-facto why your June numbers changed in September.
Project Limits Can Kneecap Agencies Early
A lot of early SEMrush users (especially small agencies) hit a wall without realizing it because of unadvertised limitations. Like, sure, it says “check 5 projects” or “track 500 keywords”. But what they don’t advertise up front: Project slots burn one per domain AND per device split if you want to do SERP separation, which is probably required if you’re auditing mobile SEO properly.
I burned two client-project slots because I assumed I could track /segment/ mobile versus desktop without spawning an entirely new project. Turns out, if you want to configure crawl frequency + desktop/mobile simultaneously, you literally need to create two instances.
This means:
You lose half your “included” slots out of the gate
Keyword tracking per project doesn’t spill over — it’s duplicated per slot
Client reporting gets janky unless you import both into a third dashboard
The API lets you cross-pull by device, but good luck doing that without scripting around their weird `device` key values — they’re strings instead of flags, and inconsistent between endpoints.
Integrations Only Go One Way
This isn’t just a SEMrush thing, but still: their GA and GSC integrations lean completely inbound. You can pull from GSC to populate your SEMrush dashboards—but you can’t push SEMrush keyword plans back into GSC campaigns or GA goals. So any time your paid team wants to align search campaigns with organic gains tracked in SEMrush? You’re rebuilding everything manually in Google Ads or GA4.
There’s no sync-back pipeline.
Even worse: SEMrush’s exported CSVs don’t always play nice when you paste them into G Ads Editor or Search Console query uploads. Their columns don’t follow native G-format schemas, and there’s no headerless export button. I’ve seen our senior PPC lead mutter-breathe “quote-hell” under her breath trying to strip quotation marks from bulk lists.
Sentiment Detection in Content Analyzer Is Comically Bad
If you’re using SEMrush Writing Assistant’s Tone of Voice or Sentiment Guidance—you’ve probably seen the issue. You could write a neutral paragraph about semiconductors going up in price and get flagged for being “too angry”. Apparently, using any negative adjective trips that wire.
Here’s a real snippet I tested while mocking up a piece:
“Chip supplies were down 15% last year, and fabricator costs jumped.”
→ Score: angry, unwelcoming tone
That’s… literally just factual. No insults, no yelling. I stripped all adverbs and it still dinged me. The suggestion? “Make your writing more friendly.” Which, sure, if you’re writing about beagle tricks. Not tech market volatility.
That tool isn’t sentiment—it’s vibes. And it ignores context completely.
The Actual SEMrush Support Experience
Honestly? Surprisingly human. But also occasionally… disjointed. You’ll usually get a real person via chat within an hour. But I once had a bug where the Position Tracking graph silently reset when I removed a tag group. Support confirmed the chart history got purged due to tag filter loss. No way to recover. And the rep said:
“Yeah that’s not supposed to happen. We updated tag logic recently, but we didn’t realize users were relying on mid-chart filters for comparisons.”
So the assumption internally was: no one compares position rankings across tag-grouped keywords. Which is wild, because that’s literally the only reason we use them.
They did follow up with a workaround (download graphs before updating tags) but… y’know… too late.
