Gmail Was Eating My Newsletter (and My Open Rate)

Last week, I started off by saying that the issue was “simpler than normal”. I had to essentially strip out some of the things I usually do each week… and make it a little bit more “barebones” than usual.

I had a reason for that. And this week’s issue goes fully into what I was doing… and why.

This week, I’m producing this issue using an entirely re-worked process. And, if you are producing a weekly email newsletter (or considering doing so), this is very much relevant to you, too.

And here we go…

I Was Quietly Throwing Away My Own Open Rate

So here’s a business mystery I recently solved. And if you create any kind of email newsletter (and I’m a big fan of the strategy), this is something you MUST know. I didn’t…. and it is a little embarrassing. 🤪

As you know, I pour real effort into this newsletter every week. It takes me 2-3 hours to do it… and my goal is to create an email you actually WANT to open. Because you find it valuable. Even if not every issue is relevant to you personally, my goal is that you find it to be a valuable weekly newsletter you look forward to reading every Monday.

And, the feedback certainly seems to show that I’m doing that. Thing is… you would ALSO expect that the metrics would reflect that, right?

Right?! 🥴

But, they didn’t. My open rate just sat there in the low 20s and wouldn’t move. I even had some weeks where it was lower. Funny thing is, a few months ago, I was seeing some open rates in the 40’s. I will say, I was sending out to a bit smaller segment at that point. So, there’s a lesson there about tighter segmentation, right message to the right people… and getting even better open rates. But, that’s not our topic for today.

Because, what I found was that my efforts to over-deliver…. were actually HURTING me.

You guys know… I can bring the meat. I can write long messages without much hassle. And I even ASKED you guys if you were enjoying the longer-form newsletters! And the feedback on that was quite good. Yet… open rates were declining.

And I finally figured it out.

Here’s the thing I didn’t know: Gmail won’t render an email past about 102KB of HTML. Go over, and it chops the bottom off and slaps a “[Message clipped]” link on it. And guess what lives at the very bottom of your email? The tracking pixel… the tiny invisible image that’s the only way your email tool knows a message got opened.

You see where this is going. 🤪

My Gmail readers were opening the email, reading the whole thing, enjoying it… and registering as a non-open, because the pixel that proves it got clipped clean off the bottom. So my “low” open rate was never an engagement problem at all. It was a measurement problem.

And now you can see why so many people say the open rate is an unreliable metric. It truly is.

And the irony is almost perfect: my effort to over-deliver is exactly what broke the metric. The longer and more valuable I made each issue, the more reliably I shoved myself over the line and trashed my own opens.

Now here’s where it stops being a theory…

Look at the open rates on my last few issues:

• 4 issues ago: 21.87%
• 3 issues ago: 19.9%
• 2 issues ago: 20.98%

Stuck in the low 20s, like clockwork. Then, last week, I stripped the email down just enough to get it under that 102KB line. Same audience. Same kind of content. Same me.

Last week’s open rate: 31.66% (as of this morning, anyway).

That’s a jump of over 50%… and I didn’t write a better subject line, clean my list, or change a single thing about who I was emailing. I just stopped getting clipped. All those “missing” opens? They were real readers the whole time. The pixel was just falling off a cliff before it could phone home.

The scary part: if I’d had a re-engagement campaign running on autopilot during all this, I’d have been quietly purging people for “inactivity”… while they were reading every single issue.

Here’s the full breakdown on this:
How “Over-Delivering” On My Email Newsletter Secretly Tanked My Open Rate

So that’s the what and the why. The how is its own story… because I’ve completely rebuilt the way this newsletter gets made to solve it at the root, not just trim words off the bottom. I’ll go more into that in the second article below…

WordPress News & Updates

Five Awesome Motive plugins got hit in a supply-chain attack. A high-severity UpdraftPlus bug was disclosed June 10, and within 48 hours attackers were inside Awesome Motive’s infrastructure… the fallout spread to OptinMonster, TrustPulse, PushEngage, MonsterInsights, and Uncanny Automator. Tampered code got served from their own CDN, and Uncanny Automator confirmed customer names, emails, license keys, and site URLs were stolen. If you run any of these, go rotate your stuff.

ShapedPlugin’s Pro updates were backdoored at the source. Attackers compromised ShapedPlugin’s build pipeline and pushed malware through official licensed update channels to 400,000+ sites… Real Testimonials Pro, Product Slider Pro, and Smart Post Show Pro were affected, and the payload steals admin logins and 2FA secrets. The uncomfortable lesson: “just keep everything updated” doesn’t save you when the update itself is the attack.

One guy ran backdoors through the plugin repo for 13 years. Developer Austin Ginder traced a backdoor campaign across 44 WordPress.org plugins back to a single operator… and the Plugins Team now says it’s even bigger: 56 plugins across 27 accounts. A solid gut-check on grabbing “free” plugins from random authors.

A critical Avada Builder bug could hand over your whole site. A flaw in Avada (≈1 million installs) lets unauthenticated attackers delete arbitrary files and potentially take over the site. Patched in 3.15.4 — update now if you’re on Avada.

Wordfence is retiring its standalone Login Security plugin. If you run Wordfence Login Security as a separate install (2FA, login CAPTCHA), it’s being discontinued around July 1… everything in it already lives in the main free Wordfence plugin, so just switch over.

SEOPress 10.0 leaned all the way into AI agents. The new version adds support for the WordPress Abilities API… meaning an AI agent can read and update your SEO titles, meta descriptions, and indexing rules (Pro goes further with redirects, schema, target keywords, and AI-generated alt text). This is the Abilities API actually showing up in tools people use, not just a spec.

FluentCommunity 2.6 is all about Courses. This one’s a real step up for anyone running a community or membership on FluentCommunity… you get Course Welcome Banners (a proper landing-page view for non-enrolled visitors, plus a “start here” view once they join), one-click duplication of lessons and quizzes, a cleaner quiz editor, and first-comment spam approval. If you’ve been treating it as a BuddyBoss alternative, this makes the Courses side a lot more legit.

FluentCRM 3.1.5 shipped — a minor performance-focused release that also lets you turn FluentCart customers into checkout subscriptions.

FluentCart 1.4.2 added EU “withdrawal button” compliance ahead of a new German rule that took effect June 19. Niche, but it matters if you sell into the EU.

WordPress 7.1’s release squad is set, with Anne McCarthy leading. It’s McCarthy’s first time as release lead, and the roadmap centers on collaboration, responsive styling, and a new Guidelines feature that ties editorial rules into AI tooling. Real-time collaboration is still the big open question after getting pulled from 7.0. Target release: August 19.

WordPress 7.0.1 has a date. The bug-fix maintenance release is scheduled for general release on July 9, with RC1 on July 1.

60% of consumers say slapping “AI” on your marketing is a turnoff. WordPress VIP’s Future of the Web 2026 report found most U.S. consumers are put off by brands waving the AI flag… even as enterprises chase AI search visibility. Also telling: 74% say the internet feels less human than a decade ago.

WordPress.org open-sourced the AI toolkit running its own social media. Marketing director Nicholas Garofalo published the agent skills and a 44,000-word brand writing guide that took WordPress from 3–4 posts a week to 3–4 a day across 11 platforms… and says the AI copy draws fewer complaints than when humans wrote it. Worth a look if you’re doing your own social.

Bonus, file under “fun”: Automattic turned wp-admin into a windowed desktop OS called Desktop Mode — draggable windows, a dock, an optional AI copilot, built in a few days during an internal hackathon. Pure novelty, but a fun one to end on.

How I Actually Fixed It (Build the Email Differently)

So in the first article, I showed you the problem… my newsletter was getting clipped by Gmail because the HTML was too big. Now let me show you how I actually fixed it. And the fix wasn’t “write less.” It was building the email a completely different way.

Here’s what I was doing before, and I’d bet a lot of you are doing the same thing.

I built the entire newsletter inside FluentCRM, using its visual block editor (which is basically Gutenberg, the same editor WordPress uses for posts). Drag a block, drop in some text, add a button, a divider, a couple columns… nice and visual. Easy.

The template I had built with FluentCRM’s editor looked just fine. And each week, I just Duplicate last week’s issue and change out the content and build the new week’s issue.

The problem is what happens after you hit send.

As the email is actually being processed and sent by FluentCRM, it is turning that block-based email into email-safe HTML… and email HTML is an ugly, ancient beast. Every block becomes a little pile of nested tables with styling stamped onto every element. It is VERY bloated… and makes it all too easy to pop over the 102KB without knowing it.

This isn’t a FluentCRM bug. They’re trying to solve a very real issue with how your email looks. Making emails appear correctly in all of the various email programs out there is not an easy task… and a lot of the things we can do on a website just don’t work in email.

That said, I’ll be honest. I think FluentCRM could do a better job at how it produces this code. The code is quite inefficient… and they could definitely make this better. Because, basically, the solution here is NOT to use their email editor. Here’s how I solve it…

Content first, layout second.

See, I used to create each campaign inside of FluentCRM – then post it to the archives in a custom post type on the website. Now… I am writing the newsletter within WordPress first. In other words, creating the content first for the website. THEN, running it through a template of my own creation that turns it into a nice, pretty email. Then, dropping that HTML into FluentCRM.

In my case, I used Claude AI to reverse engineer my weekly newsletter look and feel. Using Claude, I created my own template which contains all of the repeatable elements, but using MUCH cleaner HTML. And it contains placeholders for where the content is dropped in. I built a Claude skill that will then pull the content for me each week, assemble the final newsletter, and drop it into FluentCRM for me.

The cool thing about this approach, too, is that certain things can be automated even easier. For example, the “In Case You Missed It” section for links to recent content can now be fully automated. Couldn’t do that before.

The result is a finished email that’s a fraction of the size. Same look. Same sections. Just without the mountain of code that was quietly getting me clipped.

FluentCRM (and most decent email tools) will let you send a raw HTML email… meaning you hand it the finished HTML directly instead of building inside its editor. So I take my clean, templated email and drop it into FluentCRM as raw HTML. Well, actually, Claude does it for me. 😎 FluentCRM still does what it’s great at… sending, list management, tracking… but it’s no longer the thing building the email. That job moved upstream, to a process I control.

If going this route seems a little nerdy to ya, you can also use a dedicated email editor like Stripo. You design your email there, export clean HTML, and paste that into FluentCRM as a raw HTML campaign.

Either road gets you to the same place: the email is built somewhere lean, and FluentCRM just sends it.

Now, before I wrap up here, a reminder once again…

Everything here mainly applies if you are creating actual newsletters. Your typical text email that most people send to their list regularly isn’t at risk of hitting 102KB. Even if you type those emails right into FluentCRM, it’s fine. Yeah, the code being generated is bloated, but it doesn’t matter. It is only when you start trying to prep meaty emails – like this one – that you run the risk of screwing up your open rates.

Hope that helps!