One Two Three Send

Author: onetwothreeadmin

SEO meta descriptions: how Google decides when to rewrite yours
You spend fifteen minutes crafting the perfect meta description. Compelling hook, clear value prop, exactly 155 characters. You publish, check the SERP a day later, and Google’s showing something completely different—usually a sentence pulled from halfway down the page.

This isn’t a bug. Google rewrites meta descriptions roughly 63% of the time, according to data from Ahrefs and Moz. For some queries, that number climbs above 90%. The algorithm decides your hand-written snippet isn’t relevant enough for the searcher’s intent, so it generates one on the fly.

Here’s what triggers a rewrite, how to audit your own descriptions, and when you should stop trying to control them.

What makes Google ignore your meta description

Google doesn’t rewrite randomly. Four patterns account for most overrides:
- Query mismatch. If someone searches “WordPress caching plugin comparison 2026” and your meta description says “Learn how caching works,” Google will extract a sentence that mentions plugin names instead.
- Length problems. Descriptions under 50 characters or over 160 often get replaced. Google’s target is roughly 155–160 characters on desktop, 120 on mobile.
- Keyword stuffing. If your description repeats the same phrase three times, Google treats it as spam and pulls cleaner copy from your page.
- Better content exists on-page. If a sentence in your article body matches the query better than your meta description, Google uses that instead—even if your meta tag is well-written.
The last one catches most operators off guard. You can write a technically perfect meta description and still get overridden because paragraph three has a more direct answer to the query.

How to check which descriptions Google is actually showing

Your CMS shows what you wrote. Google Search Console shows what Google displays. Here’s the workflow:

Open Search Console, go to Performance, filter by page, and pick a URL. Click through to see the queries that triggered impressions. Now search Google for those exact queries in an incognito window. Compare what you see in the SERP to what’s in your meta tag.

If they match, you’re fine. If Google’s showing something else, screenshot both versions and note the query. Do this for your top 20 landing pages. You’ll spot patterns—certain pages get rewritten constantly, others never do.

Tools like Screaming Frog and Sitebulb can crawl your site and flag missing or short meta descriptions, but they can’t tell you what Google actually shows. Only Search Console + manual checks reveal that.

When to rewrite your meta tag vs. when to let it go

If Google rewrites your description for a high-volume query and the new version is worse—vague, truncated mid-sentence, or missing your CTA—fix your meta tag to better match the query. Add the exact phrase searchers use. Make the benefit more explicit.

But if Google’s rewrite is better—more specific, more compelling, higher click-through rate in Search Console—leave it alone. Your job isn’t to force Google to use your text. Your job is to get clicks. If the algorithm’s doing that better than you, let it work.

One non-obvious move: if Google keeps pulling the same sentence from your article for multiple queries, edit your meta description to match that sentence. You’re not fighting the rewrite—you’re aligning with what Google already decided was the best snippet. This often stops the override because now both sources say the same thing.

The one case where you should always write a custom description

Landing pages with no body copy—sales pages, squeeze pages, product pages with mostly images—need a meta description. Google has nothing else to pull from, so it’ll either use your tag or show “No information available.” That’s a 0% click-through rate.

For these pages, write the description like ad copy: one clear benefit, one implied outcome, no fluff. Test it in Search Console after two weeks. If Google still rewrites it, your page probably needs more on-page text.

If you’re running a content site with 500+ posts, auditing every meta description isn’t realistic. Start with your top 20 landing pages by traffic, fix the ones where Google’s rewrite hurts performance, and let the rest run. The algorithm’s better at this than most of us want to admit.

Want more SEO breakdowns like this? Subscribe to One Two Three Send—one operator-focused article every day, no fluff, no course upsells.
18 September 2026
Affiliate link cloaking: what happens when platforms change redirect rules
Photo: Fuzheado via Wikimedia Commons (CC0)

Affiliate link cloaking—redirecting yoursite.com/recommends/tool to partner.com/?ref=yourID—works until it doesn’t. And when it stops, you often won’t know until commissions disappear.

Platform redirect policy changes happen quietly. Amazon updated theirs in early 2025, requiring tag= parameters to appear in the original click, not after a 301. Pinterest changed how it crawls redirects in late 2024, treating multi-hop chains as suspicious. TikTok’s in-app browser now strips certain query parameters on the second redirect.

Most affiliate dashboards don’t tell you why a click didn’t convert. They show impressions, clicks, and sales—but the gap between click and sale stays opaque. If your cloaked link triggers a policy violation, the click registers, the redirect happens, but the attribution dies.

What redirect chains actually look like

A typical cloaked affiliate link creates at least two hops:
- Hop 1: Reader clicks yoursite.com/recommends/tool
- Hop 2: Your server issues a 301 or 302 to partner.com/?ref=yourID
- Hop 3 (sometimes): Partner platform redirects again to the actual product page
Each hop adds latency—30 to 150 milliseconds depending on server location and DNS lookup. More importantly, each hop is a point where attribution can break. If the affiliate network expects the referrer header to match your domain, but a browser extension or VPN strips it mid-chain, the sale won’t attribute.

Link management plugins like Pretty Links, ThirstyAffiliates, and Lasso handle the redirect, but they can’t control what happens after the hand-off. If Amazon decides your redirect pattern looks like a masked URL shortener, it won’t tell your plugin—it just stops crediting conversions.

When platforms change the rules

Three recent examples that broke established cloaking setups:

Amazon Associates began enforcing stricter referrer validation in Q1 2025. Links that redirect through a non-whitelisted domain now require the associate tag in the first URL, not the final destination. If your cloak is yoursite.com/amazon/product and it redirects to amazon.com/dp/B08XYZ?tag=yourID, Amazon may not credit it unless tag=yourID appears in the cloaked URL itself—which defeats the purpose of cloaking.

Impact Radius and ShareASale both tightened multi-hop detection in 2024. Links that pass through more than two redirects before landing on the merchant site trigger fraud flags. If you’re using a link shortener and a cloak and the merchant uses its own redirect layer, you’ve hit three hops—and the click may not count.

Social platform in-app browsers are the silent killer. TikTok, Instagram, and LinkedIn all use custom WebView browsers that strip or modify query parameters unpredictably. A cloaked link that works fine in Chrome may lose its affiliate ID when opened inside the TikTok app. You won’t see an error—the link just opens without attribution.

What to monitor and when to adapt

Most operators only notice redirect problems when monthly commissions drop without a corresponding traffic dip. By then, you’ve lost weeks of sales.

Set up a monthly check:
- Compare click-through rate to conversion rate in your affiliate dashboard. If CTR holds steady but conversions drop 20%+, suspect redirect breakage.
- Test your cloaked links in incognito mode across browsers and devices. Open them in the TikTok app, Instagram in-app browser, and LinkedIn mobile. Check the final URL in the address bar—does your affiliate ID survive?
- Run a redirect chain audit using a tool like Redirect Path (browser extension) or the command-line tool curl -I. Count the hops. Three or more is a red flag.
If you discover a broken chain, you have two options: simplify the redirect or switch to direct affiliate links with branded slugs (e.g., yoursite.com/go/tool that’s visible but still trackable). Some operators now use branded short domains—recs.yourname.com/tool—to keep links clean without full cloaking.

One more thing: if you’re driving significant affiliate revenue—over $2,000/month from a single program—ask your affiliate manager if your redirect setup is compliant. Most will tell you. Some will whitelist your domain to bypass restrictive filters. It’s worth the email.

Got a redirect mystery or a link setup that stopped working? Reply to this email—I’ll dig into it for a future piece.
17 September 2026
Patreon vs. Ko-fi vs. Buy Me a Coffee: who gets paid faster

Photo: American Truth Project via Wikimedia Commons (Public domain)

If you’re running a content business on fan contributions, the three weeks between earning $500 and having it in your bank account can be the difference between making payroll and missing it.
Patreon, Ko-fi, and Buy Me a Coffee all let audiences send you money, but their payout schedules, fee structures, and hold policies differ enough that choosing the wrong one can cost you hundreds of dollars in delay or processing costs every month.
Here’s how each platform actually works when it comes to getting your money.
Patreon: monthly batching with a five-day hold
Patreon batches member payments on the first of every month (or on your custom billing date if you’re on their legacy per-creation model). Once those payments clear, Patreon holds the funds for five business days before initiating a payout to your bank account.
That means if you earn $1,200 from 40 patrons on October 1, you’ll see the money in your account around October 8–10, depending on your bank’s processing time.
Patreon takes 5% to 12% depending on your plan tier (Lite, Pro, or Premium), plus payment processing fees of roughly 2.9% + $0.30 per transaction. If you’re on the Lite plan at 5%, you’re netting about $1,026 from that $1,200—assuming all payments succeed.
Failed payments get retried automatically for up to a week, but if a patron’s card declines and doesn’t recover, you don’t get paid for that month. Patreon doesn’t front you the money.
Ko-fi: instant payout option, but only on Premium
Ko-fi offers two modes: free and Premium ($108/year as of September 2026).
On the free plan, Ko-fi holds payments for up to 30 days before releasing them to your PayPal or Stripe account. That’s a full billing cycle—longer than Patreon.
On the Premium plan, you unlock instant payouts. Supporters’ payments land in your connected Stripe or PayPal account within minutes, and you control when to transfer that balance to your bank. For most operators, that’s a 2-day ACH transfer via Stripe or a same-day PayPal withdraw (for a 1.5% fee).
Ko-fi takes 0% platform fee on Premium. You pay only Stripe or PayPal’s standard processing fees: roughly 2.9% + $0.30 per transaction. That same $1,200 month nets you about $1,161 after processing, assuming 40 × $30 one-time tips.
The catch: if you’re using Ko-fi’s monthly membership feature (their Patreon alternative), payouts are still monthly, not instant—even on Premium.
Buy Me a Coffee: weekly or monthly, depending on volume
Buy Me a Coffee operates on a hybrid schedule. Small accounts (under $1,000/month) get paid monthly, around the 10th of the following month. Larger accounts graduate to weekly payouts once you cross that threshold consistently.
There’s no platform fee—Buy Me a Coffee takes 5% only on tips sent through their iOS or Android apps (to cover Apple/Google’s 30% cut). Web-based tips are fee-free aside from payment processing at 2.9% + $0.30.
If you earn $1,200 in September via the web, you’ll receive roughly $1,161 around October 10. If you’ve crossed into weekly payouts, you’d get four transfers of ~$290 each, landing every Friday.
One quirk: Buy Me a Coffee holds payouts for 7 days on your first three transactions as a new account, regardless of volume. After that, the monthly or weekly schedule kicks in.
Which one to pick
If you need cash flow predictability and can absorb a five-day delay, Patreon works well for membership models with recurring monthly supporters. The fee structure is higher, but the audience expects to support creators there, and discovery features can drive new patrons.
If you want instant access to funds and you’re okay paying $108/year, Ko-fi Premium is the fastest route—especially for one-time tips or project-based funding. Monthly memberships still batch, though.
If you’re just starting out or you don’t want to pay an annual fee, Buy Me a Coffee splits the difference. You’ll wait longer initially, but once you hit weekly payouts, you’re getting money almost as fast as Ko-fi without the subscription cost.
All three platforms work. The one that fits depends on whether you value speed, cost, or audience expectations more. If you’re choosing between them, model out your monthly volume, multiply by each platform’s effective fee rate, and map your cash flow needs against their payout schedules. The right answer shows itself in a spreadsheet.
Which platform do you use, and has payout timing ever caused you a problem? Hit reply—I’d like to hear whether operators are switching platforms for cash flow reasons or sticking with what their audience already knows.

17 September 2026
AI image generation rate limits: how platforms meter your requests

Photo by Markus Winkler on Unsplash

If you’ve ever hit “generate” on an AI image tool and been told to wait, you’ve run into rate limiting. Unlike text-based AI tools that count tokens, image platforms meter your usage in jobs, concurrent requests, or GPU minutes—and each platform does it differently.
Understanding how these limits work matters when you’re producing social assets, course graphics, or thumbnail variants at scale. Pick the wrong plan or workflow, and you’ll spend more time waiting than creating.
How the major platforms meter image generation
Midjourney uses a job-based system. Each image generation—whether it’s an initial prompt, an upscale, or a variation—counts as one job. On the Basic plan ($10/month), you get roughly 200 jobs. The Standard plan ($30/month) gives you around 900 jobs. Jobs reset monthly, and there’s no daily sub-limit.
What catches people: every action is a job. If you generate a 4-image grid, that’s one job. But upscaling one of those images? Another job. Running four variations? Four more jobs. A single concept exploration can burn through 10–15 jobs easily.
DALL·E 3 (via ChatGPT Plus or API) works differently. ChatGPT Plus subscribers get approximately 50 generations per day, with a rolling three-hour window that refills partially. The API charges per image: $0.040 for standard 1024×1024 images, $0.080 for HD quality. There’s no monthly job pool—just a spend limit you set yourself.
The daily cap resets, but it’s not a hard midnight cutoff. If you generate 30 images at 2pm, you’ll regain some capacity by 5pm, but you won’t have a full 50 again until the next day. For burst work, the API is more predictable.
Stable Diffusion via Stability AI’s API charges by resolution and step count. A 512×512 image at 50 steps costs roughly $0.002. A 1024×1024 at 150 steps costs around $0.01. You’re billed per request, and there’s a concurrent request limit—typically 3–5 simultaneous generations on the base tier.
Self-hosting removes metering entirely, but you’re paying for GPU time instead. A RunPod instance with an A40 GPU runs about $0.69/hour. If you’re generating 100+ images a week, the math starts favoring a rented instance.
What actually counts against your limit
Most platforms count failed generations. If you submit a prompt that violates content policy or produces an error, that still burns a request on DALL·E and Midjourney. Stable Diffusion API charges only on successful renders, but the concurrent slot is still occupied during the failed attempt.
Variations and edits always count. Midjourney’s “vary (subtle)” and “vary (strong)” buttons each consume a job. DALL·E’s inpainting and outpainting features count as new generations. If you’re iterating on a concept, your effective cost-per-final-image is much higher than the sticker price suggests.
Private generations count the same as public ones on Midjourney. Switching to Stealth Mode (available on Pro and Mega plans) hides your images from the community gallery, but it doesn’t reduce job consumption.
Non-obvious ways to stretch your quota
Batch your prompt experiments in text tools first. Instead of burning five Midjourney jobs testing prompt variations, run those prompts through Claude or ChatGPT and ask it to predict which will produce the closest result to your description. It’s not perfect, but it cuts exploratory waste by 40–50% in practice.
Use lower-cost platforms for rough drafts. Generate concept sketches with Stable Diffusion’s cheaper 512×512 output, then move to DALL·E or Midjourney only for final assets. A $10 Stability AI credit balance generates roughly 500 draft images—enough to validate directions before committing premium jobs.
Leverage Midjourney’s remix mode strategically. When you enable remix, you can alter the prompt during a variation request. This lets you test two variables in one additional job instead of two separate jobs. Example: generate a base image of “minimalist product photo,” then remix the variation to “minimalist product photo, warm lighting.” You’ve tested lighting in one extra job instead of starting fresh.
On DALL·E, queue requests just before the rolling window refills. If you know you used 30 generations at 9am, set a reminder for noon. You’ll have partial capacity back, and you can spread your work across two windows instead of waiting until tomorrow.
Which metering model fits your workflow
If you produce high-volume, low-iteration work—like generating 50 unique social quote cards from a template prompt—Stable Diffusion API or a self-hosted instance wins. You’re not iterating much, so per-image cost matters more than job flexibility.
If you do exploratory creative work with lots of variations—like developing a visual brand identity—Midjourney’s Standard plan offers better value than DALL·E’s daily cap. You’ll burn through 50 DALL·E images in two concept directions; Midjourney’s 900 jobs let you explore five or six directions deeply.
If you generate sporadically—maybe 10–20 images a month for blog headers—ChatGPT Plus at $20/month gives you DALL·E access plus the text model. You won’t hit the daily cap, and you avoid paying for unused job pools.
Want to compare AI tool costs for your specific workload? Reply with your monthly image volume and primary use case—we’ll break down which platform meters most favorably for your situation.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

17 September 2026
Beehiiv’s Boost network: how the referral exchange actually works

Photo: Johan Schiff/Miljöpartiet de gröna via Wikimedia Commons (CC0)

Beehiiv‘s Boost network is a built-in recommendation marketplace that lets newsletter operators cross-promote with each other—without cold outreach or manual swaps. You list your newsletter, set a cost-per-subscribe bid, and Beehiiv surfaces your publication in other creators’ recommendation slots.
It’s not a magic growth lever, but it is one of the few platform features that actually drives net-new subscribers without requiring you to build an audience somewhere else first. Here’s how it works under the hood, when it makes sense to use, and the one setting that changes your entire cost structure.
How Boost recommendations surface
When a reader subscribes to a Beehiiv newsletter, the confirmation page can display a grid of recommended publications. If the operator has enabled Boost, some of those slots are filled by paid recommendations from other newsletters in the network. Beehiiv runs an auction: the highest bidder for that audience segment wins the slot.
You don’t pay per impression. You pay per verified subscribe—meaning someone clicked your recommendation, entered their email, and confirmed (if double opt-in is required). Beehiiv tracks this end-to-end and charges your account balance once the subscriber is verified.
The minimum bid is typically $1.00 per subscriber, but competitive niches (business, finance, tech) often see effective bids closer to $2.00–$4.00. You set a daily budget cap and a maximum cost-per-acquisition, and Beehiiv pauses your campaign when either limit is hit.
Who it works for (and who it doesn’t)
Boost makes the most sense if you’re already monetising subscribers and know your lifetime value. If a subscriber is worth $8 to you over six months—through ads, affiliate commissions, or paid upgrades—then paying $3 to acquire them is sustainable. If you’re pre-revenue and treating growth as a pure attention play, Boost becomes expensive quickly.
It also works better for generalist or accessible topics. A newsletter about «productivity for remote workers» will find more available impression inventory than one about «Rust async runtime internals.» Beehiiv’s network skews toward business, creator economy, and lifestyle content; if your niche is narrow, you’ll spend more per subscriber or exhaust available inventory fast.
One major limitation: you can’t target by topic with surgical precision. Beehiiv offers basic category filters (business, tech, health, etc.), but you can’t specify «only show my SaaS newsletter to readers who subscribe to other B2B SaaS newsletters.» The algorithm learns over time which placements convert, but early campaigns are broad.
The setting most operators miss: subscriber quality filters
Buried in the Boost campaign setup is a toggle called Premium Placements. When enabled, Beehiiv only shows your newsletter on confirmation pages for publications with strong engagement metrics—typically above 40% open rate and low unsubscribe rates.
This cuts your available inventory by roughly half, but the subscribers you acquire tend to stick. In practice, turning this on increases your cost-per-subscribe by 20–30%, but reduces 30-day churn by nearly the same margin. If you’re optimising for retained subscribers rather than raw list growth, it’s worth the trade.
Most operators leave it off by default because Beehiiv doesn’t surface it prominently during onboarding. It’s in the campaign settings under Advanced Options, and the UI doesn’t explain the churn impact—just that it “prioritises high-quality placements.”
When to pause (or skip entirely)
Boost isn’t a substitute for organic growth. If you don’t have a clear monetisation model or you’re still testing content-market fit, paying $2–$4 per subscriber usually doesn’t pencil out. It works when you’ve already validated that your content converts and retains, and you’re ready to add paid acquisition as a supplement to organic channels.
It also doesn’t replace SEO, social, or referral loops. Boost subscribers arrive cold—they know nothing about you except a two-sentence pitch and a thumbnail. If your onboarding sequence isn’t strong, they churn fast. Operators who succeed with Boost typically have a welcome series that delivers immediate value and sets clear expectations within the first three emails.
One other watch-out: Beehiiv’s auction pricing can spike during high-inventory periods (end of quarter, January resolution season). If your campaign suddenly doubles in cost-per-subscribe, check whether you’re bidding during a demand surge and consider pausing until costs normalise.
Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools and tactics that actually move the needle for online operators. One email, no fluff, every Sunday.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

16 September 2026
Social listening tools miss DMs—and that’s where deals close

Photo by Brett Jordan on Unsplash

Social listening tools promise to track every mention of your brand, product, or content across platforms. They scan Twitter, Reddit, LinkedIn, and Facebook for keywords, hashtags, and @-mentions. They generate sentiment scores, alert you to spikes, and bundle everything into dashboards.
But they all share the same blind spot: direct messages.
For solo operators and small teams running online businesses, that’s a problem. Public mentions generate vanity metrics. Private messages generate revenue.
Why DMs don’t show up in listening tools
Social listening platforms rely on public APIs. Twitter’s API (now X) surfaces tweets, replies, and quote tweets. LinkedIn’s API pulls posts and comments. Reddit’s API indexes threads and comments. None of them expose private messages to third-party tools.
That’s by design. Platforms treat DMs as protected user data. Even if you own the account, listening tools can’t access your inbox programmatically without violating terms of service or requiring OAuth flows that most platforms explicitly block for monitoring use cases.
The result: your listening dashboard shows someone tweeting “anyone tried [your product]?” but misses the four people who saw that tweet and DMed you directly to ask for pricing, implementation help, or a referral discount.
Where high-intent conversations actually happen
Public posts are low-commitment. A reply costs nothing. A DM signals intent.
In practice, operators see this split constantly. Someone posts a question about email platforms on Twitter. Three people reply with generic recommendations. Two people DM the original poster with affiliate links, case studies, or offers to walk them through setup.
The same pattern plays out on LinkedIn. A founder posts about switching WordPress hosts. Public comments suggest the usual suspects—Kinsta, WP Engine, Flywheel. The DMs contain referral codes, migration checklists, and invitations to compare pricing over a call.
Reddit’s even more skewed. Public threads attract drive-by advice. DMs attract buyers who don’t want their purchase intent visible in their comment history.
If you’re only monitoring public mentions, you’re seeing the low-value half of the conversation.
What solo operators do instead
The operators who catch these conversations don’t rely on listening tools. They build lightweight manual systems.
Inbox tagging. Most platforms let you tag or label DM threads. Create tags for “inbound lead,” “product question,” “referral ask,” and “support escalation.” Tag conversations as they arrive. Export or review tags weekly to spot patterns.
Saved reply templates. Twitter, LinkedIn, and Instagram all support saved replies or message templates. Write three to five templates for common DM types: pricing inquiries, feature questions, migration offers, affiliate pitches. Deploy them in under 30 seconds. Track which ones convert.
Publer and similar cross-network tools let you manage DMs across platforms in a unified inbox, but they don’t auto-tag or analyze sentiment. You still review manually—just faster.
CRM logging for high-value threads. If a DM conversation runs longer than three exchanges or involves a dollar figure, log it in your CRM. Most operators use Notion, Airtable, or a simple spreadsheet. Columns: platform, username, topic, status, next action, value. Update it once a week.
This isn’t elegant. It doesn’t scale to enterprise volume. But for solo operators handling 10 to 50 DM conversations a month, it works better than a listening tool that never sees the inbox.
When listening tools still matter
Public monitoring still has value. If you’re launching a product, tracking brand mentions across Reddit and Twitter catches early feedback, bug reports, and comparison threads you wouldn’t see otherwise. If you’re building in public, listening tools surface who’s quoting your updates, where your content gets shared, and which topics generate the most discussion.
But don’t mistake mention volume for lead volume. The operators who close deals in DMs aren’t the ones with the most @-mentions. They’re the ones who reply to public posts and check their message requests twice a day.
If your listening tool shows 50 mentions this month and zero conversions, the conversions probably happened in DMs you never saw.
What’s working for you? Reply to this email if you’ve built a system for tracking DM-based leads—we’ll feature anonymized workflows in a future breakdown.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

16 September 2026
WordPress object cache: what it stores and when to purge it
Photo: Matinbeigi via Wikimedia Commons (CC BY-SA 4.0)

Most WordPress performance guides tell you to enable object caching. Few explain what it actually caches—or when clearing it causes more problems than it solves.

Object caching sits between WordPress and your database. When a plugin or theme requests data—post metadata, user details, term relationships—WordPress checks the cache first. If the data exists in memory, the database query never runs. If not, WordPress queries the database, stores the result, and serves it from cache on the next request.

This matters more as your site grows. A single page load on a membership site might trigger 200+ database queries. Object caching can cut that to under 50.

What object cache actually stores

Object cache doesn’t store rendered HTML. It stores discrete pieces of data WordPress requests repeatedly:
- Post metadata: custom fields, featured image IDs, post status
- Taxonomy terms: categories, tags, and custom taxonomies assigned to posts
- User data: roles, capabilities, profile fields
- Options table entries: site settings, plugin configurations
- Transients: time-limited data stored by plugins (API responses, remote file checks)
Page caching—what most CDNs and caching plugins do—stores the final HTML output. Object caching operates one layer deeper, at the data-retrieval level. That’s why you often run both: page cache for anonymous visitors, object cache for logged-in users and admin requests.

Redis and Memcached are the two dominant backends. Redis persists data to disk and survives server restarts; Memcached lives entirely in RAM and flushes on reboot. For solo operators, Redis is the safer default. Most managed WordPress hosts offer it as a toggle in the dashboard.

When purging object cache breaks workflows

Flushing object cache is a common troubleshooting step. You update a plugin, something looks wrong, you clear all caches. That works—until it doesn’t.

Some plugins store non-regenerable data in transients. If you flush the cache mid-process, the plugin loses track of where it was. I’ve seen this break:
- Bulk import tools that cache progress state between batches
- OAuth tokens stored as transients (rare, but it happens)
- Membership plugins tracking trial eligibility windows
If a process starts behaving erratically after a cache flush, check whether the plugin documentation warns against it. WP-CLI’s wp cache flush is instant and irreversible—there’s no undo.

A safer alternative: flush selectively. Most object cache plugins let you clear specific cache groups (users, posts, terms) instead of nuking everything. WP Rocket and LiteSpeed Cache both expose group-level controls in their dashboards.

When object cache doesn’t help

Object caching speeds up repeated queries. If your site serves mostly anonymous traffic and you’re already using page caching, object cache adds minimal benefit—the page cache serves HTML before WordPress even boots.

It shines in three scenarios:
- Membership or user-specific content: logged-in users bypass page cache, but object cache still cuts database load
- High-traffic admin areas: dashboard requests hit the database hard; object cache reduces query time
- WooCommerce or other plugin-heavy builds: plugins query metadata constantly; caching eliminates redundant lookups
If you’re running a simple blog with static pages and no user accounts, object cache won’t make a perceptible difference. Your hosting plan’s resources matter more.

Configuration detail most hosts skip

Default object cache configurations use the same Redis or Memcached instance for every site on a multisite network. That means a cache flush on Site A also purges Site B’s data.

If you’re running multiple sites—even just a staging and production environment—set unique cache key prefixes. In Redis, that’s the WP_CACHE_KEY_SALT constant in wp-config.php:

define('WP_CACHE_KEY_SALT', 'mysite_prod');

This ensures staging flushes don’t touch production cache, and vice versa. Managed hosts sometimes set this automatically. If you’re on a VPS or managing your own stack, you configure it manually.

One more detail: object cache doesn’t replace database optimisation. If you’re running slow queries, caching only hides the symptom. Use Query Monitor to log what’s actually hitting the database, then optimise the queries or add indexes. Cache speeds up reads; it can’t fix inefficient writes or missing foreign keys.

Have a caching setup that doesn’t fit the standard advice? Reply and tell us what you’re running—we read every response.
16 September 2026
Content republishing: when syndicating old posts doubles traffic
Photo: Unknown authorUnknown author via Wikimedia Commons (Public domain)

A SaaS founder with 240 published articles on his company blog spent four hours in July republishing twelve older posts to Medium and LinkedIn. Over the next 60 days, those twelve pieces brought 4,800 new visitors back to his site—more than double the traffic those same posts generated in their original publication month two years earlier.
Content republishing isn’t just about squeezing extra mileage from old work. Done correctly, it’s a structured traffic channel that compounds over time. Here’s what the numbers look like when operators actually track it.
The baseline case: what republishing adds
An email course creator tracked her republishing efforts across six months. She selected posts that had already proven engagement on her own site—pieces with above-median time-on-page and at least five inbound links. She republished one post per week to Medium with canonical tags pointing back to the original.
Results over 180 days:
- 26 posts republished
- 11,200 Medium views total
- 840 click-throughs to her site (7.5% CTR)
- 62 new email subscribers attributed via UTM tags
Her own site analytics showed those 26 posts collectively earned 3,100 organic views in the same period. Republishing added roughly 27% net-new traffic to those specific pieces, with zero additional content creation.
Medium wasn’t the only channel. A WordPress consultant republished tutorial content to Dev.to and Hashnode. His technical how-to posts averaged 180 views on his own domain in their first 90 days. Republished to Dev.to, the same posts averaged 620 views in 90 days, plus 90 external clicks.
When syndication underperforms
Not every republishing effort pays off. A lifestyle blogger syndicated fifteen posts to LinkedIn articles over three months. Total engagement: 340 views across all fifteen pieces, 11 clicks back to her site. Her hypothesis: LinkedIn’s algorithm favors native short-form posts over long-form articles, and her audience wasn’t actively searching LinkedIn for her topic (sustainable fashion).
Platform-audience fit matters more than raw platform size. Another operator republished B2B content to Medium and saw almost no traction, then moved the same pieces to niche industry forums with RSS syndication partnerships. Forum syndication brought 10x more qualified traffic, despite the platforms having 1/50th Medium’s total user base.
Timing also degrades results. One operator waited four years to republish archive content. By then, several posts referenced deprecated tools and outdated pricing. Republished pieces with stale information earned 60% fewer views than posts republished within 12–18 months of original publication.
Mechanical details that change outcomes
Canonical tags are non-negotiable if you care about SEO. Every operator I reviewed who republished without canonical tags saw their original posts lose 15–40% of their organic Google traffic within 90 days as the republished version competed for the same keywords.
Platform-specific formatting makes a difference. A content strategist republished the same post to Medium and LinkedIn. On Medium, she kept the original post structure intact. On LinkedIn, she rewrote the intro and reformatted subheadings to match LinkedIn’s typical article style. The LinkedIn version earned 2.3x more views.
CTAs need adjustment. Operators who kept their original CTA (e.g., “subscribe to my newsletter”) saw lower engagement than those who tailored the CTA to each platform’s norms. On Medium, a CTA inviting readers to “read the full archive on my site” outperformed direct subscription asks by 40% in click-through rate.
Operator checklist for republishing
If you’re testing this as a traffic channel, start with these constraints:
- Republish only posts that already have traction—above-median traffic or engagement on your own site
- Choose platforms where your audience actually searches or browses (not just where they have accounts)
- Add canonical tags pointing to your original post
- Reformat intros and CTAs to match platform norms
- Track with UTM parameters so you know which pieces and platforms deliver
- Republish within 12–18 months of original publication, before tools or context become stale
One operator’s rule: if a post earned fewer than 50 organic views in its first six months, it’s not worth republishing. Syndication amplifies existing demand; it doesn’t create it from scratch.
Want more operator tactics like this? Subscribe to One Two Three Send for weekly breakdowns of what actually works in online-business tooling and strategy.
15 September 2026
Newsletter spam complaints: when 0.1% flags your entire domain
Photo by Brett Jordan on Unsplash

Most operators watch open rates and unsubscribes. Almost nobody watches spam complaint rate until their entire sending domain gets flagged.
A spam complaint happens when a recipient clicks “Report spam” or “Mark as junk” in their email client. That signal goes back to the inbox provider—Gmail, Outlook, Yahoo—and gets logged against your sending domain and IP address.
The threshold that matters: 0.1% complaint rate. That’s one complaint per thousand delivered emails. Cross that line consistently, and inbox providers start filtering your mail to spam for everyone, not just the people who complained.
How complaint rate differs from unsubscribe rate
Unsubscribes are visible to you. Someone clicks your footer link, your platform logs it, and they’re removed from your list. Complaint rate is mostly invisible.
When someone marks your email as spam, most inbox providers don’t tell you. Gmail’s postmaster tools show aggregate complaint data if you’ve set up domain authentication. Outlook offers JMRP and SNDS dashboards. Yahoo has a feedback loop you can register for. But unless you’ve configured these—and most solo operators haven’t—you’re flying blind.
Even worse: a complaint doesn’t automatically unsubscribe the recipient from your platform’s perspective. They’re still on your list. You keep sending. They keep marking as spam. Your complaint rate climbs.
Postmark surfaces complaint rate in the main dashboard because it affects deliverability faster than almost any other metric. If you’re on a shared sending platform without complaint monitoring, you’re trusting that the platform is watching it for you—and many don’t surface it until you’re already in trouble.
What drives complaints up
The most common cause isn’t content quality. It’s expectation mismatch.
Someone signed up for a lead magnet. You start sending a weekly newsletter. They don’t remember opting in, or they expected one email, not fifty. Instead of scrolling down to find the unsubscribe link, they click “Report spam.” It’s faster.
Older recipients and mobile users hit the spam button more often. On mobile, the unsubscribe link is small, sometimes hidden in a collapsed footer, and requires extra taps. The spam button is right there in the toolbar.
Other complaint drivers:
- Long gaps between sends. You send once, then nothing for three months, then resume. Recipients forget who you are.
- Sending to old lists. Addresses that haven’t engaged in a year are far more likely to complain when you re-appear.
- Misleading subject lines. Promising something the email doesn’t deliver makes people angry.
- No recognizable “From” name. If your sender name is a domain or an unfamiliar business name, recipients assume it’s spam.
What happens when you cross 0.1%
Inbox providers don’t warn you. They just start filtering.
Gmail moves your mail to spam for everyone, not just complainers. Outlook does the same, often within hours. Yahoo’s filters are aggressive—cross 0.2% and you’re done.
Fixing it takes weeks, not days. You need to:
- Stop sending to anyone who hasn’t engaged recently (90 days is a safe threshold).
- Improve your unsubscribe link visibility—put it at the top and the bottom.
- Send a re-engagement campaign to dormant subscribers and remove non-responders.
- Wait. Domain reputation recovers slowly. Complaint rate has to stay under 0.05% for two to four weeks before filtering eases.
Switching to a new sending domain doesn’t fix it if you’re taking the same list with you. The complaints follow the behavior, not just the domain.
Monitoring before it’s too late
Set up Google Postmaster Tools and Microsoft SNDS even if you’re on a managed platform. These give you domain-level complaint data that your ESP might not surface.
If your platform does show complaint rate—Postmark, Brevo, and MailerLite all do—check it weekly. Anything above 0.05% is a yellow flag. Above 0.08% and you need to act immediately.
The fastest fix: make your unsubscribe link impossible to miss. Put it in the first paragraph if you have to. A higher unsubscribe rate is infinitely better than a rising complaint rate, because unsubscribes don’t kill your domain.
If you’re seeing complaints climb and you don’t know why, look at your most recent sign-up source. Did you import a list? Run a giveaway that attracted freebie-seekers? Change your content format without warning? Complaint spikes almost always trace back to a list-quality issue in the prior 30 days.
Want operator tactics like this in your inbox? Subscribe to One Two Three Send for weekly deep-dives on the tools and platform mechanics that matter.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.
15 September 2026
Productivity automation retries: when tools replay failed steps

Photo by Jotform on Unsplash

Most automation platforms promise “automatic retries” when a step fails. What they don’t advertise is how differently each tool defines failure, how many times they’ll retry, and what happens to your data when a step succeeds on the third attempt but your downstream logic assumed it failed.
If you’re running payment workflows, lead capture, or anything that touches money or customer data, retry behavior isn’t a nice-to-have detail—it’s the difference between a duplicate charge and a satisfied customer.
What triggers a retry in the first place
Zapier retries on HTTP 429 (rate limit), 502, 503, and 504 errors. It does not retry on 4xx errors like 400 (bad request) or 401 (unauthorized), because those indicate a configuration problem, not a transient failure.
Make (formerly Integromat) retries on the same 5xx errors but adds exponential backoff—first retry after one minute, second after two, third after four. You can configure this in scenario settings, but the default is three attempts.
n8n retries on any HTTP error by default unless you explicitly disable it per node. This sounds safer, but it means a misconfigured API call will burn through retry attempts instead of failing fast and alerting you.
The problem: if your automation sends a Slack notification on step failure, and the API call succeeds on retry two, you’ve already notified your team that something broke. Now you’re debugging a phantom issue.
When retries create duplicate actions
Here’s the worst-case scenario: your automation charges a customer via Stripe, then adds them to your CRM. The Stripe call succeeds, but the CRM times out. The platform retries the entire workflow, not just the failed step.
Result: two Stripe charges.
Zapier avoids this by replaying only the failed step and everything downstream. If step three fails, steps one and two don’t re-run. But if you’ve built a linear workflow without idempotency checks—like “charge card, then email receipt”—a retry on the email step won’t re-charge, but a retry on the charge step will re-email.
Make handles this better with “commit points.” You can flag a module as non-retriable, which tells the platform to skip it on replay. Stripe charges should always be flagged this way.
n8n requires you to handle this manually. If you want idempotency, you need to add a conditional node that checks whether the Stripe charge already exists before creating a new one. It’s more work upfront, but it’s also the only way to be certain.
What “max retries” actually means
Zapier’s documentation says tasks retry “up to three times,” but that’s three retries per step. If you have a five-step Zap and step four fails, Zapier will attempt step four three times, then mark the entire run as failed. Steps one through three don’t re-run.
Make’s retry count applies to the entire scenario run. If you set max retries to three, the platform will replay the whole scenario three times if any module fails. This is why commit points matter—you don’t want non-idempotent actions replaying.
n8n’s retry logic is per-execution, but you control the interval. Default is immediate retry, then 1 minute, then 5 minutes. You can stretch this to hours if you’re integrating with an API that has daily rate limits.
How to design for retries without breaking things
First, separate state changes from notifications. Charge the card in step one, write the result to your database in step two, send the receipt in step three. If step three fails and retries, you’re only re-sending an email—not re-charging.
Second, add idempotency keys to any financial or inventory action. Stripe’s API accepts an idempotency_key parameter; if you retry with the same key, Stripe returns the original charge instead of creating a new one. Most payment processors support this.
Third, log every retry. Zapier’s task history shows retry attempts, but Make and n8n require you to add explicit logging nodes. Write the execution ID, timestamp, and step name to a Google Sheet or database. When something breaks three days later, you’ll know whether it was a transient failure or a config issue.
Fourth, set retry limits based on your SLA, not the platform default. If your workflow processes orders, three retries over six minutes might be fine. If you’re syncing live event registrations, you want zero retries and an instant alert.
Finally, test failure states manually. Pause your CRM’s API access mid-automation and watch what happens. Does the platform retry? Does it log the failure? Does your fallback notification fire? If you don’t know, you’re guessing.
Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools that run your business—and the edge cases their docs don’t mention.

15 September 2026

► Necessary Cookies Always Active

Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.

► Functional Cookies Remark

Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.

► Analytical Cookies Remark

Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.

► Advertisement Cookies Remark

Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.