One Two Three Send

Author: onetwothreeadmin

  • Zapier’s multi-step Zap delay and why your automations break

    Zapier’s multi-step Zap delay and why your automations break

    Zapier’s delay step looks simple: pause a workflow for X minutes, then continue. But when you chain delays with webhooks, conditional paths, or APIs that expect near-instant responses, you introduce failure points that don’t show up in test runs.

    Most operators add delays to throttle API calls, spread out emails, or wait for external services to process data. The problem is that Zapier’s delay doesn’t pause the entire workflow—it queues the remaining steps and hands control back to Zapier’s scheduler. If your upstream service times out, if your conditional logic depends on fresh data, or if a webhook expects a synchronous reply, your Zap fails silently or produces stale results.

    How Zapier’s delay step actually works

    When you insert a delay, Zapier splits your workflow into two parts: everything before the delay runs immediately, and everything after gets added to a queue with a timestamp. Zapier’s scheduler picks it up when the delay expires.

    This design works fine for simple workflows—trigger on new row, wait 10 minutes, send email. But it breaks when:

    • Webhooks expect a synchronous response. If your trigger is a webhook and your sending service times out before the delay expires, the upstream app logs a failure even though your Zap eventually runs.
    • Conditional logic depends on real-time data. If you delay after a trigger, then check a condition based on a field that might change (order status, inventory count, user role), the data Zapier queried at trigger time may be stale by the time the delayed steps run.
    • Third-party APIs rate-limit by time window, not by call count. Adding a 5-minute delay between steps doesn’t help if the API measures rate limits in rolling 60-second windows. You’ll still hit the limit if multiple Zaps fire in the same minute.

    When delays cause silent failures

    Zapier’s task history shows a delay step as successful if it queues correctly. The failure happens downstream, often in a later step that depends on timing or fresh data.

    Example: You trigger a Zap when a Stripe payment succeeds, delay 15 minutes, then check if the customer completed onboarding in your app. If the customer completes onboarding in minute 10, your conditional check at minute 15 sees the updated status and proceeds. But if they complete it in minute 2, your check still waits until minute 15—and if your onboarding flow sent them a conflicting email in the meantime, they get duplicate or contradictory messages.

    Another common break: delaying before a lookup step. If you trigger on a new CRM contact, delay 30 minutes, then look up their company in another system, the lookup uses the contact ID from the original trigger. If that contact was merged or deleted in the CRM during the delay, the lookup fails or returns null.

    Alternatives that don’t break timing-dependent workflows

    If you need to throttle API calls, use Zapier’s built-in rate limiting in your action step settings instead of a delay. This queues tasks at the action level without splitting the workflow.

    If you need to wait for external state to change, replace the delay with a polling trigger or a webhook callback. For example, instead of delaying 10 minutes then checking order status, set up a separate Zap triggered by an order status change event.

    If you need to spread out emails to avoid looking spammy, move the delay logic into your email tool. Most ESPs let you schedule sends or add random delays per recipient—Postmark and Brevo both support this natively for transactional campaigns.

    If you’re delaying to give a human time to review something, use a dedicated approval tool like Slack’s workflow builder or a form submission as the next trigger, rather than a blind time delay.

    When delays actually work

    Delays are safe when:

    • The trigger is asynchronous (new row in a spreadsheet, new file in Dropbox) and doesn’t expect a response.
    • No downstream step depends on real-time data or external state that might change.
    • You’re delaying to satisfy a minimum wait time (e.g., wait 5 minutes before sending a follow-up), not to synchronise with another process.

    If your workflow fits those criteria, delays work fine. If you’re using delays to work around rate limits, timing dependencies, or state synchronisation, you’re patching over a design problem.

    Before you add a delay step, ask: what am I actually waiting for? If the answer is “for something to happen,” use an event trigger. If it’s “to avoid hitting a rate limit,” configure rate limiting at the action level. If it’s “to make the timing feel human,” move the delay into the tool that sends the output.

    Got a Zapier workflow that breaks intermittently? Reply with the failure pattern—I’ll cover debugging strategies in a future issue.

    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.

  • WordPress performance plugins double your server load—here’s why

    WordPress performance plugins double your server load—here’s why

    Installing a WordPress performance plugin feels like the responsible thing to do. Your PageSpeed score is stuck in the 60s, your hosting dashboard shows CPU spikes, and every SEO guide tells you to optimize. So you install WP Rocket, W3 Total Cache, or Autoptimize, flip a few switches, and assume the problem is solved.

    Then your server load doubles.

    This isn’t a edge case. Performance plugins introduce their own overhead—database writes for cache keys, background processes to minify assets, recurring tasks to preload pages—and many operators never realize the plugin meant to speed things up is now the bottleneck.

    What performance plugins actually do

    Most WordPress performance plugins tackle three jobs: page caching, asset minification, and delivery optimization (lazy loading, CDN integration, font preloading). Each of these requires the plugin to intercept requests, rewrite HTML on the fly, or generate new files.

    Page caching works by saving a static HTML version of each page to disk or object cache, then serving that cached copy instead of rebuilding the page from the database every time. Asset minification combines and compresses CSS and JavaScript files. Delivery optimization defers or delays non-critical resources.

    The problem: all of these tasks add new processes. A caching plugin has to check whether a cached version exists, determine if it’s stale, regenerate it if needed, and manage cache invalidation when you publish new content. Minification plugins parse your CSS and JS on every change, write new files to disk, and track dependencies. Lazy-loading scripts inject JavaScript that monitors scroll position and loads images dynamically.

    If your site was already near its resource limit, these new tasks push you over. You’re now running two systems: WordPress and the performance layer, each competing for CPU and memory.

    Where the overhead hides

    The most common culprit is automatic cache preloading. Many caching plugins offer a “preload” option that crawls your entire site in the background, generating cached versions of every page. Sounds efficient—until you realize it’s firing dozens or hundreds of requests against your own server, often during peak traffic hours.

    On a site with 200 pages, preloading can mean 200 simultaneous PHP processes trying to render pages. If your host limits you to 20 concurrent PHP workers, you’ve just locked out real visitors while the plugin talks to itself.

    Database writes are another hidden cost. Some caching plugins write cache metadata to the WordPress database: expiration timestamps, cache keys, file paths. If you’re generating thousands of cached variations (different pages, mobile vs. desktop, logged-in vs. logged-out), you’re writing thousands of database rows. Those writes slow down every other query on your site.

    Asset minification can backfire if it runs on every page load instead of only when files change. Plugins that regenerate minified CSS and JS on the fly—rather than saving the output and reusing it—burn CPU on repetitive work. If your theme or page builder outputs inline styles, the plugin may re-minify the same code hundreds of times per day.

    How to audit the damage

    Start with your hosting dashboard. Most managed WordPress hosts (BigScoots, Kinsta, WP Engine) show CPU and memory graphs. Look for spikes that align with plugin activation or cache preload schedules.

    Next, check database query counts. Install the Query Monitor plugin, load a few pages, and compare query volume before and after activating your performance plugin. If queries increase by 20 or more, the plugin is reading or writing cache metadata on every request.

    Check background processes with a cron monitor. WP Crontrol is a free plugin that lists all scheduled tasks. Look for jobs labeled “cache preload,” “minify regenerate,” or “optimize images.” If they run every hour and your site has 500+ pages, you’re hammering your server for minimal gain.

    Finally, test actual page speed with and without the plugin. Use WebPageTest or GTmetrix to measure Time to First Byte (TTFB) and Largest Contentful Paint (LCP) with the plugin active, then deactivate it and test again. If TTFB increases with the plugin enabled, it’s doing more harm than good.

    What to do instead

    Start by offloading work your server shouldn’t be doing. Use a CDN (Cloudflare, BunnyCDN) to serve static assets—images, CSS, JS—without touching your origin server. Enable Cloudflare’s automatic minification and Brotli compression so you’re not running those tasks in PHP.

    If you need page caching, choose a plugin that writes to disk (not the database) and doesn’t preload unless you explicitly trigger it. WP Super Cache and Cache Enabler both write flat HTML files and stay out of the database. Disable mobile-specific caching unless you’re serving completely different markup to mobile users—responsive design means one cached version works for everyone.

    Skip asset minification unless you’re loading 15+ CSS or JS files per page. Modern HTTP/2 hosting handles multiple small files efficiently, and the CPU cost of minification often outweighs the bandwidth savings. If you do minify, use a build tool (Webpack, Vite) during development so the minified files are static—never generated at runtime.

    For image optimization, use a service like ShortPixel or Imagify that processes images once and stores the result, rather than a plugin that optimizes on every request. Set it to manual mode and run it after uploading new images, not automatically.

    Most importantly: only add a performance plugin if you’ve measured the problem first. If your TTFB is already under 600ms and LCP is under 2 seconds, you don’t need caching. If your total page weight is under 1MB, you don’t need aggressive minification. Add complexity only when the data proves you need it.

    Reply with the hosting setup or performance plugin you’re running—I’ll feature operator setups and server configs in a future issue.

  • SEO keyword clustering tools overfit your content plan

    SEO keyword clustering tools overfit your content plan

    Keyword clustering tools promise to turn a thousand-keyword export into a tidy content calendar. You feed them a CSV from Ahrefs or Semrush, they group similar terms by algorithmic proximity, and you walk away with twenty “clusters” instead of a thousand loose threads.

    The problem: most clustering algorithms optimize for semantic similarity, not what people actually want when they search. Two keywords can live in the same cluster and serve completely different intents. Publishing one piece to “cover” both leaves you with a Frankenstein post that ranks for neither.

    How clustering tools decide what goes together

    Most tools use one of three methods: SERP overlap (keywords that share top-10 URLs), n-gram matching (keywords that share word sequences), or semantic embedding (vector-space models trained on language corpora).

    SERP overlap sounds reliable—if Google ranks the same pages for two queries, those queries must want the same answer. But SERP overlap breaks down when a single authoritative domain ranks broadly. A site like Wirecutter or NerdWallet can rank for “best budget laptop” and “laptop under $500” on the same listicle, even though one query wants a buying guide and the other wants SKU-level specs and stock alerts.

    N-gram clustering groups by shared phrases. “WordPress security plugin,” “WordPress security best practices,” and “WordPress security checklist” all land in the same bucket. In reality, the first wants a product comparison, the second wants a tutorial, and the third wants a PDF download or interactive tool.

    Semantic models improve on pure string-matching, but they still cluster by topical closeness, not by what the searcher expects to do with the content. “How to start a newsletter” and “newsletter platform comparison” live close in vector space. One needs a guide; the other needs a grid of pricing and feature checks.

    When clustering helps and when it hides intent mismatches

    Clustering works well for informational queries with stable SERP structure. If you’re writing explainers in a narrow niche—say, Kubernetes configuration or tax-loss harvesting—and the top results for your cluster all follow the same format, you’re safe consolidating.

    It falls apart when:

    • Your cluster mixes commercial and informational intent (“CRM software” + “what is a CRM”)
    • Your cluster spans beginner and advanced variants (“what is DNS” + “DNS propagation troubleshooting”)
    • Your cluster includes branded and generic queries (“Mailchimp pricing” + “email marketing pricing”)

    These mismatches don’t always surface in the tool’s UI. You see a cluster labeled “email marketing” with eighteen keywords and an aggregate search volume of 12,400. You write one 2,500-word guide. Six months later, you rank on page two for everything and page one for nothing.

    The fix: manual intent audits before you commit to one piece

    Before you merge a cluster into a single content brief, open five to eight top-ranking URLs for each keyword in the group. Look for format divergence:

    • Are half the results listicles and half long-form tutorials?
    • Do some results lead with a product table and others with conceptual definitions?
    • Do the URLs for one keyword average 800 words and another average 3,200?

    If the answer to any of those is yes, split the cluster. Write separate pieces or separate sections under distinct H1s on different URLs.

    This adds fifteen minutes of manual work per cluster, but it prevents the costlier mistake: publishing once, watching rankings stall, and reverse-engineering intent six months later when you finally audit why the post underperformed.

    Tools worth the manual layer

    If you’re committed to clustering as a workflow step, prioritize tools that expose SERP overlap and let you inspect the shared URLs. Keyword Insights and Surfer SEO’s clustering modules both show which URLs anchor each cluster. That visibility lets you spot the Wirecutter problem before you consolidate.

    Ahrefs’ “Parent Topic” feature sidesteps clustering entirely—it shows you the single URL Google ranks for a group of keywords, then tells you what that URL’s primary target keyword is. That’s often more useful than an algorithmic grouping, especially if you’re working in a competitive vertical where a few domains dominate the SERP.

    No tool eliminates the need to read. Clustering speeds up bucketing; it doesn’t replace intent diagnosis.

    One Two Three Send covers the tooling and tactics that solo operators actually use to build content businesses. If this kind of breakdown helps, subscribe here—one operator-focused article every morning, no fluff.

  • Newsletters drain deliverability faster than they build trust

    Newsletters drain deliverability faster than they build trust

    Most newsletter operators believe that more touchpoints build more trust. Send twice a week instead of once. Add a Sunday bonus. Launch a daily tip series. The logic sounds reasonable: more contact equals more familiarity, and familiarity drives conversions.

    But that logic ignores the infrastructure layer underneath every newsletter: deliverability.

    The truth is that increasing send frequency without corresponding engagement gains doesn’t build trust—it destroys your sender reputation, tanks inbox placement, and turns your entire archive into spam fodder. You’re not building authority. You’re training inbox algorithms to ignore you.

    How send frequency damages sender reputation

    Email service providers track your sender reputation using a combination of signals: open rates, spam complaints, bounce rates, and engagement velocity. When you double your send frequency, you need to double your engaged audience to maintain the same reputation score.

    Here’s what actually happens: you send twice as often, but your open rate drops by 30–40% because subscriber attention is finite. Your most engaged readers might open both emails, but your median subscriber opens one or neither. Your overall engagement rate falls. ISPs interpret that drop as a signal that your content is less relevant, and they adjust inbox placement accordingly.

    The math is unforgiving. If you send once a week to 10,000 subscribers with a 40% open rate, that’s 4,000 engaged readers per send. Switch to twice a week with a 28% open rate (a realistic drop), and you’re down to 2,800 engaged readers per send—5,600 per week total. You’re sending twice as much for a 40% gain in absolute engagement, but your per-send reputation score is now 30% lower.

    Gmail and Outlook don’t care about your weekly totals. They care about per-campaign signals.

    The engagement cliff

    Once your sender reputation drops below a certain threshold, inbox placement collapses non-linearly. You don’t gradually slide from inbox to promotions tab. You fall off a cliff into spam folders, and recovery takes months of disciplined list hygiene and reduced sending.

    I’ve watched this happen to operators who went from weekly to daily sends without testing the transition. Within six weeks, their inbox placement rate dropped from 92% to under 60%. Their open rates fell further because fewer people saw the emails in the first place. The feedback loop is vicious: worse placement drives lower engagement, which drives worse placement.

    The operators who recovered did so by cutting send frequency in half, removing unengaged subscribers, and rebuilding slowly over 90 days. Some never fully recovered their original inbox rates.

    When frequency works—and when it doesn’t

    High send frequency works in exactly one scenario: when you have an audience that actively wants daily or near-daily content, and you can prove it with engagement data.

    If you’re running a news digest, a stock-tip service, or a highly segmented course drip, frequent sends can work—because your audience expects them and opens them. But even then, you need to monitor per-campaign open rates religiously and cut frequency the moment engagement drops.

    For the rest of us—commentary writers, niche educators, solo operators building authority in a specific domain—frequency is a tax on reputation. Your subscribers don’t need to hear from you three times a week. They need to hear from you when you have something worth saying, and they need to open the email when it arrives.

    One high-quality send per week with a 45% open rate will build more trust and deliver better long-term results than three mediocre sends per week with a 22% open rate. The total engaged-reader count might look similar in a spreadsheet, but the infrastructure consequences are not.

    What to do instead

    If you’re tempted to increase frequency, test it properly. Segment a portion of your list and send them the higher-cadence version for 30 days. Track per-campaign open rates, spam complaints, and unsubscribe rates. Compare those numbers to your control group.

    If engagement holds or improves, roll out the change slowly. If engagement drops even slightly, revert immediately. A 10% drop in per-send open rate today becomes a 40% drop in inbox placement six months from now.

    And if you’re already sending frequently and seeing declining engagement, the fix is simple but painful: send less. Cut your frequency in half, improve your content quality, and give your sender reputation time to recover. It’s not exciting, but it works.

    Want to dig into deliverability mechanics and list-health strategies? Reply to this email with your biggest inbox-placement question—we’ll cover it in a future issue.

    The operators who win the long game aren’t the ones who send the most. They’re the ones who still land in the inbox after two years.

  • Plausible vs. Fathom vs. Simple Analytics: which privacy-first tool to pick

    Plausible vs. Fathom vs. Simple Analytics: which privacy-first tool to pick

    Privacy-first analytics platforms sell themselves on the same pitch: no cookies, no GDPR banners, fast scripts, and clean dashboards. Plausible, Fathom, and Simple Analytics dominate the category, but they differ in meaningful ways once you’re past the landing page.

    If you run a content-driven business and you’re tired of Google Analytics bloat—or you need to ditch cookie banners without losing visitor insight—here’s what each tool does well, where it falls short, and who should pick which.

    Pricing and visitor thresholds

    All three charge based on monthly pageviews, but the tiers and caps differ.

    Plausible starts at $9/month for up to 10,000 pageviews. You pay $19/month for 100,000 views, $29/month for 200,000, and pricing scales from there. If you exceed your plan, Plausible emails a warning and asks you to upgrade—it doesn’t cut off tracking.

    Fathom starts at $15/month for 100,000 pageviews. The entry tier is higher, which means if you’re sub-50,000 views per month, you’re overpaying compared to Plausible. Fathom counts by pageviews across all sites on your account, so multi-site operators hit limits faster.

    Simple Analytics starts at €19/month (roughly $20 USD) for 100,000 pageviews. Pricing is similar to Fathom but billed in euros. Simple Analytics offers a “business” tier that includes mini-websites—embedded public dashboards you can share without login—which the other two don’t bundle at the base level.

    If you’re under 50,000 pageviews per month, Plausible wins on cost. Above that threshold, all three converge, and the decision shifts to features and interface preference.

    Feature differences that matter

    All three tools show you top pages, referrers, devices, browsers, and countries. The gaps appear when you need goals, funnels, or custom dimensions.

    Plausible supports custom event goals at no extra cost. You can track button clicks, form submissions, or file downloads by adding a JavaScript snippet or using their API. Plausible also offers a custom properties feature that lets you attach metadata to events—useful if you want to track blog post category performance or product variant clicks. The dashboard is fast, and the filter UI is clean. Plausible is open-source and offers a self-hosted option if you want to run it on your own infrastructure.

    Fathom keeps the interface even simpler. Custom events exist, but Fathom doesn’t support event metadata or properties—you get event names and counts, nothing more granular. That’s fine if you’re tracking basic conversions (newsletter signups, link clicks), but limiting if you need segmentation. Fathom’s uptime monitoring feature sends you alerts if your site goes down, which is a nice bundled extra the others lack. Fathom is closed-source and cloud-only.

    Simple Analytics falls between the two. It supports events and metadata, similar to Plausible. Simple Analytics also has a built-in automated events feature that tracks outbound links and file downloads without manual setup. The dashboard lets you create multiple views and share them publicly via mini-websites, which is useful if you want to show traffic stats to sponsors or partners. Simple Analytics is open-source like Plausible, but its self-hosted version requires more technical setup.

    Script size and page speed impact

    All three advertise sub-1KB scripts. In practice, Plausible’s script is around 1KB, Fathom’s is 1.4KB, and Simple Analytics is 3KB. The difference is marginal—none will tank your Core Web Vitals—but if you’re optimizing aggressively, Plausible has the smallest footprint.

    All three scripts are proxy-friendly, meaning you can serve them from your own domain to avoid ad blockers. Plausible and Fathom document this clearly; Simple Analytics requires a bit more config work.

    Who should pick which

    Pick Plausible if you’re under 50,000 pageviews per month, you want custom event properties, or you value open-source software and self-hosting optionality. Plausible’s pricing scales cleanly as you grow, and the event tracking flexibility covers most operator needs without requiring a migration later.

    Pick Fathom if you want the simplest possible dashboard, you’re already above 100,000 pageviews, and you value the uptime monitoring extra. Fathom’s lack of event metadata keeps the interface uncluttered, which some operators prefer. It’s also the most polished UI of the three—if aesthetics matter to your daily workflow, Fathom feels the most refined.

    Pick Simple Analytics if you need public dashboard sharing (for sponsors, clients, or transparency pages), you want automated event tracking without manual setup, or you’re already comfortable with euro billing. Simple Analytics sits in the middle on features and pricing, which makes it a safe default if you’re unsure.

    One thing all three miss

    None of these tools track individual user journeys or session replays. If you need to see how a single visitor navigated your site—or you want heatmaps—you’ll need a separate tool or a hybrid setup. That’s by design: privacy-first analytics don’t fingerprint users. But it’s a tradeoff worth naming if you’re migrating from Google Analytics and expect session-level data.

    If you’re running a newsletter or content site and you just need clean traffic numbers without the compliance headache, any of these three will work. The decision comes down to pageview volume, whether you need event metadata, and how much you care about dashboard aesthetics.

    Want more tool breakdowns like this? Reply and tell us which category to compare next—we’ll prioritize reader requests.

  • AI content rewriters lose SEO context after three paragraphs

    AI content rewriters lose SEO context after three paragraphs

    AI rewriting tools promise to refresh old content, adapt pieces for different audiences, or polish drafts into publishable posts. In practice, most lose the thread after a few hundred words—and take your search rankings with them.

    The problem isn’t that the output reads poorly. It’s that the rewritten version drifts from the search intent and semantic context that made the original rankable. You end up with smoother prose that Google understands less clearly than the draft you fed in.

    Why context collapse happens

    Large language models process text in chunks, typically 512 to 2,048 tokens depending on the tool. When you ask Claude, ChatGPT, or a dedicated rewriter to rework a 1,500-word article, the model receives the full document but applies transformations paragraph by paragraph or section by section.

    Early paragraphs get rewritten with the full document in short-term memory. By the time the model reaches paragraph eight or nine, it’s prioritising local coherence—making each sentence flow from the last—over global semantic alignment with your target keyword and the questions that keyword implies.

    The model doesn’t forget your instructions. It just weighs them against an increasing pile of local context. Synonym substitution, sentence restructuring, and tone shifts compound. A post that ranked for “WordPress CDN setup” becomes a post about “content delivery configuration for WordPress sites”—technically accurate, lower search overlap.

    What you lose in the rewrite

    Three things degrade faster than readability:

    • Keyword density and placement. If your original placed the target phrase in the first 100 words, the H2, and the conclusion, the rewrite scatters it or replaces it with near-synonyms that don’t carry the same search volume.
    • Semantic clustering. Google’s algorithms look for related terms that confirm topic relevance—”DNS,” “origin server,” “cache purge” in a CDN article. Rewriters often swap these for vaguer language or drop them entirely in favour of smoother transitions.
    • Internal link anchor context. If you linked to a related post with anchor text like “WordPress object caching,” the rewrite might turn that into “another caching method” or a generic “learn more,” weakening the semantic signal between pages.

    You can recover readability by editing. You can’t easily recover ranking momentum once Google recrawls a diluted version and adjusts your position.

    When rewriting works anyway

    Short-form content survives AI rewrites better. A 400-word product description or email gives the model less room to drift. The entire piece fits comfortably in the context window, and the model can hold your intent steady from open to close.

    Rewriting also works when you’re not targeting search traffic. If you’re adapting a blog post into a LinkedIn update, a newsletter section, or a Twitter thread, semantic SEO doesn’t matter. Clarity and platform fit do. The model’s tendency to simplify and tighten becomes an asset.

    And if you’re refreshing content that never ranked well in the first place, you have little to lose. A rewrite that shifts keyword focus might accidentally improve relevance for a better query.

    How to preserve SEO during AI rewrites

    The most reliable fix is to rewrite in smaller sections and provide keyword guardrails in every prompt. Don’t send the full article and ask for a rewrite. Send the introduction, specify your target keyword and two related terms, then move to the next section.

    Explicit instructions help: “Rewrite this section. Keep the phrase ‘WordPress CDN setup’ in the first sentence. Retain all mentions of ‘origin server,’ ‘DNS,’ and ‘cache purge.’ Improve readability without changing technical terminology.”

    After the rewrite, run both versions through a keyword density checker or a semantic SEO tool like Surfer or Clearscope. Compare term frequency for your target keyword and the top twenty related phrases. If the rewrite drops five or more high-value terms, flag those paragraphs and restore the language manually.

    Some operators skip AI rewriting for ranking content entirely. They use the model to generate alternate introductions or tighten conclusions, but leave the body untouched. It’s slower than a one-click rewrite, but it doesn’t trade rankings for polish.

    If you’ve run AI rewrites on posts that used to rank and seen traffic drop in the weeks after republishing, this is likely why. The content didn’t get worse—it just stopped answering the question Google thought it answered before.

    Have a question about using AI tools without breaking what already works? Reply to this email—I read every message and often turn answers into future posts.

    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.

  • Lemon Squeezy’s fraud detection blocks real customers—here’s the fix

    Lemon Squeezy’s fraud detection blocks real customers—here’s the fix

    Lemon Squeezy’s fraud detection system killed three sales for me in April before I knew what was happening. The customers reached out directly—confused emails asking why their cards kept declining. All three had legitimate payment methods. All three were buying a $29 digital product. None triggered a chargeback or refund request afterward, because I manually invoiced them through PayPal.

    The problem wasn’t their cards. It was Lemon Squeezy’s fraud filters doing exactly what they’re designed to do: err on the side of caution. For platforms processing payments on your behalf, that caution protects their merchant account more than your conversion rate.

    What triggers Lemon Squeezy’s fraud blocks

    Lemon Squeezy uses a combination of IP geolocation, payment method origin, purchase velocity, and device fingerprinting to assess fraud risk. The system runs automatically—no manual review, no appeals process during checkout.

    The most common false positives come from:

    • VPN usage. Customers routing through privacy tools often show mismatched IP and billing addresses. Lemon Squeezy’s system flags this as high-risk, especially if the VPN exit node is in a country with elevated fraud rates.
    • Prepaid and virtual cards. Privacy.com cards, Revolut disposable numbers, and similar services trigger blocks more often than traditional bank-issued credit cards. The BIN (bank identification number) lookup tags them as higher risk.
    • Cross-border purchases. A customer in the Philippines buying from a U.S.-based seller with a card issued in Singapore will hit multiple friction points. The system doesn’t distinguish between legitimate digital nomads and card testers.
    • High cart values from new accounts. First-time buyers attempting purchases above $100 face stricter scrutiny. If you sell courses, bundles, or annual subscriptions, expect more declines than someone selling $9 templates.

    You won’t see most of these blocks in your dashboard. Lemon Squeezy logs them as “payment failed” without distinguishing fraud declines from insufficient-funds errors. The customer sees a generic “transaction could not be completed” message and often assumes their card is the problem.

    How this compares to Gumroad and Stripe

    Gumroad uses a similar merchant-of-record model and faces the same false-positive tradeoff. Operators report roughly 2–4% of legitimate transactions blocked, with higher rates for international sales. Gumroad’s support will manually review and whitelist customers, but only after the sale fails and you open a ticket.

    Stripe, when you’re using it as a direct integration (not through a platform), gives you more control. You can adjust Radar’s fraud threshold, whitelist specific countries or card types, and review flagged transactions before they’re declined. The tradeoff: you’re responsible for chargebacks. Platforms like Lemon Squeezy absorb that risk, which is why their filters are tighter.

    For solo operators selling digital products under $50, Lemon Squeezy’s fraud protection saves more money than it costs—until your audience skews international or privacy-conscious. Then the math flips.

    What you can do when a real customer gets blocked

    Lemon Squeezy doesn’t offer a way to pre-approve customers or adjust fraud thresholds. Your options are reactive:

    Manual invoicing. If a customer emails you after a decline, send a PayPal invoice or Stripe payment link directly. You’ll eat the higher transaction fee (PayPal charges 3.49% + $0.49 for invoices vs. Lemon Squeezy’s flat 5% + $0.50), but you’ll close the sale. I’ve done this eleven times in the past six months.

    Alternative checkout links. Some operators set up a secondary Gumroad or Stripe Checkout flow for customers who can’t complete payment on Lemon Squeezy. You’ll maintain two product listings and reconcile sales across platforms, but it catches 60–70% of declined buyers who bother to ask for an alternative.

    Support ticket on their behalf. Email Lemon Squeezy support with the customer’s email, approximate purchase time, and product. They’ll review the transaction log and can manually process the payment. Turnaround averages 12–24 hours, which means you’ve likely lost the impulse buyer.

    None of these solutions scale if you’re processing hundreds of transactions per week. At that volume, 2% false positives means multiple support emails daily and manual invoicing overhead that cancels out the convenience of using a merchant-of-record platform.

    When to switch platforms

    If more than 5% of your inbound support is payment-decline related, and you’ve confirmed the customers have valid payment methods, Lemon Squeezy’s fraud filters are costing you more than they’re saving. Track this for 30 days—log every “my card was declined” email and compare it to total transactions.

    For audiences in North America and Western Europe paying with standard credit cards, Lemon Squeezy works cleanly. For SaaS products, courses, or communities with global reach—especially if you’re attracting privacy-focused buyers or digital nomads—you’ll spend too much time recovering legitimate sales that should have converted automatically.

    The alternative is taking on fraud risk yourself with a direct Stripe integration, which means dealing with chargebacks, sales tax collection, and VAT compliance. That’s not a trivial tradeoff for a solo operator, but it’s the only way to control your own fraud thresholds.

    Hit reply if you’ve lost sales to fraud filters on any platform—I’m tracking patterns across Lemon Squeezy, Gumroad, and Paddle for a deeper comparison next month.

  • Sponsorship rate cards overpromise reach—here’s what to show instead

    Sponsorship rate cards overpromise reach—here’s what to show instead

    Sponsorship rate cards for newsletters typically lead with total subscriber count. It’s the biggest number you have, and brands shopping for placement want to see scale. The problem: that number is almost always misleading, and experienced media buyers know it.

    If you’re pitching sponsors with a PDF that says “12,000 subscribers — $400 per placement,” you’re either underpricing engaged readers or overcharging for a list padded with inactive emails. Either way, you’re losing deals or leaving money on the table.

    Here’s what works better, and what sponsors actually care about when they’re deciding whether to wire you money.

    Lead with opens, not list size

    A 10,000-subscriber list with a 45% open rate delivers more eyeballs than a 25,000-subscriber list with an 18% open rate. The math is simple: 4,500 opens versus 4,500 opens. But the first operator charges less because they think list size is the metric that matters.

    Sponsors don’t pay for email addresses. They pay for attention. If your last six issues averaged 3,200 opens, say that upfront. Break it down by 30-day cohorts if your list has grown recently—showing that your May signups open at 52% while your January signups open at 38% proves you’re adding quality subscribers, not buying lists or running giveaway spam.

    Include unique open rates, not total opens. If someone opens your email three times, that’s still one person. Most ESPs report both; sponsors want the unique number.

    Show click-through on past sponsorships

    If you’ve run sponsorships before, share anonymized click data. Not click-through rate as a percentage—absolute clicks. “Last sponsor placement generated 210 clicks to their landing page” tells a buyer exactly what they’re getting. Add context: was it a text link, a dedicated section, or a full takeover? Did you write the copy or did they?

    If the sponsor converted 8% of those clicks into trial signups, and you know that because they told you, put it in the deck. Third-party validation is worth more than your own claims about engagement.

    Don’t have sponsorship data yet? Show clicks on your own content. Pick your three most recent issues, pull the top-clicked link from each, and report the numbers. If your audience clicks through to your blog, affiliate links, or product pages at a 6–9% rate, they’ll click sponsor links too.

    Segment pricing by placement type

    A single rate card with one price assumes all placements are equal. They’re not. A dedicated email where you write a 400-word case study about the sponsor’s product is worth more than a three-line text link in your footer. A mid-email callout box with a headline, 100 words, and a button is somewhere in between.

    Offer at least two tiers. Name them clearly: “Featured partner” and “Classified mention,” or “Primary sponsor” and “Supporting link.” Price them 3x to 5x apart. If your supporting link is $200, your featured placement should be $600–$1,000, depending on your open rate and niche.

    Sponsors with bigger budgets will pick the expensive option because it’s clear what they’re getting. Sponsors testing your list for the first time will pick the cheap option, then upgrade after they see results.

    Drop the subscriber count—or bury it

    If your open rate is strong, lead with opens and clicks. Put total subscriber count in the third or fourth line, or leave it out entirely. It’s not a secret—sponsors can ask—but it’s not your strongest signal.

    If your list is below 2,000 subscribers, don’t apologize for it. Instead, frame your pricing around cost per click or cost per open. “$300 gets you 180 clicks” is a clear value proposition. A brand spending $1.67 per click on Google Ads will happily pay you $300 for the same result with a warmer audience.

    One operator I know runs a 1,400-subscriber list in the podcast production niche. She charges $250 per sponsor mention and delivers 80–100 clicks per placement. Her cost per click is under $3, and her sponsors re-book every quarter because her audience converts. She doesn’t mention list size in her pitch deck at all.

    Update your rate card every quarter

    Your open rate drifts. Your list grows. Sponsors who booked you six months ago paid a price based on old data. If your opens are up 15% since January, your rate card should reflect that.

    Don’t freeze pricing just because a sponsor might complain. Grandfather existing sponsors at their original rate for one renewal, then move them to current pricing. New sponsors pay the current rate immediately.

    If your engagement is falling, don’t raise rates. Fix your content first, then revisit sponsorship pricing once your numbers recover. Charging more for worse performance is how you lose sponsors permanently.

    Want to compare how other operators price sponsorships? Reply with your open rate and niche—we’ll feature anonymized benchmarks in a future issue.

  • Social media schedulers charge per account—here’s the math

    Social media schedulers charge per account—here’s the math

    Social media scheduling tools advertise starter plans at $10–$15 per month. That number holds only if you post to a single platform. Add Twitter, LinkedIn, Instagram, and a Facebook page, and the same tool bills you $40–$60 monthly—or forces you into a higher tier.

    The pricing structure isn’t hidden, but it’s rarely surfaced until you hit the connect-account screen. For solo operators running content-driven businesses across multiple channels, per-account billing turns an affordable utility into a recurring line item that rivals your hosting or email costs.

    How per-account pricing works across platforms

    Most scheduling tools define an “account” or “channel” as a single social profile. One Twitter account, one LinkedIn personal profile, one Instagram business account, one Facebook page—each counts separately.

    Buffer’s free tier allows three channels. The $6/month Essentials plan gives you one channel. To schedule across four platforms, you need the Team plan at $12/month per channel—$48 monthly for four accounts.

    Hootsuite’s Professional plan starts at $99/month for ten social accounts. If you manage fewer profiles, you’re still paying the base rate; there’s no cheaper tier that scales down.

    Later (focused on visual platforms) offers one social set per user on the Starter plan at $25/month. A “set” includes one profile per platform—Instagram, Facebook, Twitter, LinkedIn, TikTok, Pinterest, and YouTube. That’s better for multi-platform operators, but you’re locked into the bundle even if you only use three.

    Publer breaks the pattern slightly: the free tier supports one account per platform (up to three total), and paid plans at $12/month allow multiple accounts per platform for up to ten total social profiles. For an operator running personal and business accounts across Twitter, LinkedIn, and Instagram, that’s six profiles under one plan.

    When per-account pricing costs more than the tool’s value

    If your business generates revenue directly from social traffic—affiliate clicks, newsletter signups, course sales—the $50/month cost is defensible. But many solo operators schedule content as brand presence, not primary acquisition. In that case, you’re paying $600 annually to post three times per week across four channels.

    Compare that to native scheduling: Twitter, LinkedIn, Facebook, and Instagram all offer free post-scheduling inside their apps. The trade-off is context-switching and no unified calendar view, but the cost difference is $600 per year.

    For operators running a single content pillar across platforms—republishing the same blog post summary or newsletter link—per-account billing penalises efficiency. You’re doing less work (one piece of content, four destinations), but paying more than someone who writes custom posts for a single channel.

    How to audit whether you’re overpaying

    Pull up your scheduling tool’s billing page and count connected accounts. Then check your analytics for the last 90 days. For each social profile, calculate:

    • Monthly cost allocated to that profile (total bill divided by number of accounts)
    • Clicks or conversions attributed to that profile
    • Cost per click or cost per conversion

    If a profile costs $12/month and sends 30 clicks, you’re paying $0.40 per click before counting the time to create and schedule the post. If those clicks convert at 2%, you’re paying $20 per conversion from that channel.

    That math doesn’t mean the channel is bad—it means you should compare the cost to other acquisition channels (SEO content, paid ads, email) to decide whether the scheduling tool is worth keeping for that profile.

    Cheaper alternatives and when to switch

    If you’re overpaying for profiles that generate little return, three paths cut costs:

    Consolidate platforms. Drop the social profile with the weakest return. If Facebook sends five clicks per month and costs $12 in allocated scheduler fees, disconnect it and reallocate that budget.

    Switch to a per-user tool. Platforms like Publer or Buffer’s higher tiers charge per user, not per account, up to a cap. If you’re a solo operator, one seat with ten account slots costs less than per-account billing for four profiles.

    Use native scheduling. For low-frequency posting (once or twice per week), native tools cost nothing and require only a few extra minutes per session. Save the unified dashboard for high-volume operations where time savings justify the expense.

    One operator I know switched from Hootsuite ($99/month) to Publer ($12/month) and native LinkedIn scheduling for her personal profile. She posted to six accounts before; now she posts to five and saves $87 monthly. The profile she dropped—Pinterest—had sent 12 clicks in six months.

    Want more breakdowns like this? Reply with the tool or pricing structure you’d like examined next. We’ll pull the numbers and show you where the cost hides.

    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.

  • WordPress object caching: what it fixes and when to skip it

    WordPress object caching: what it fixes and when to skip it

    Object caching is one of those WordPress optimizations everyone talks about but few operators actually understand. The idea is simple: instead of hitting the database every time someone loads a page, WordPress stores frequently accessed data—posts, user info, theme settings—in memory. When the same data is requested again, it’s served from RAM instead of MySQL.

    That sounds like a win. And for many sites, it is. But object caching introduces moving parts—another service to monitor, another thing that can fail—and if your traffic or query load doesn’t justify it, you’re adding complexity for marginal gain.

    What object caching actually does

    Out of the box, WordPress uses a non-persistent object cache. That means data is stored in PHP memory for the duration of a single page load, then discarded. If the next visitor requests the same page, WordPress queries the database all over again.

    A persistent object cache—typically Redis or Memcached—stores that data in memory across page loads. When WordPress asks for a post’s metadata or a list of recent comments, the cache serves it instantly. No database round trip.

    This makes the biggest difference on sites with:

    • High concurrent traffic (50+ visitors at once)
    • Complex database queries (custom post types, meta fields, WooCommerce)
    • Plugins that query the database on every page load (membership tools, dynamic content widgets)

    If your site doesn’t fit those profiles, object caching won’t do much. A static homepage with 20 posts and light traffic won’t see a speed boost—you’re already fast enough.

    When to skip it

    Object caching adds a dependency. If Redis goes down, your site slows to a crawl—or breaks entirely, depending on how your host configured the fallback. Managed WordPress hosts like BigScoots typically handle this gracefully, but if you’re self-managing a VPS, you need monitoring in place.

    You also need to flush the cache deliberately when you update content. Most caching plugins handle this automatically, but edge cases exist: custom fields updated via WP-CLI, direct database edits, or theme changes can leave stale data in Redis for hours.

    Skip object caching if:

    • Your traffic is under 10,000 page views per month
    • Your average page load is already under 1 second (check your server response time in Google Search Console or Pingdom)
    • You’re running a static site generator or headless setup (the database isn’t the bottleneck)

    In those scenarios, you’ll get more value from a CDN, image optimization, or trimming down plugins. Object caching is overkill.

    How to set it up (if you need it)

    Most managed WordPress hosts offer Redis or Memcached as a one-click add-on. If you’re on a VPS, you’ll need to install Redis via SSH, then add a PHP extension and a WordPress plugin to connect the two.

    The most common plugin is Redis Object Cache by Till Krüss. It’s free, actively maintained, and shows you cache hits versus misses in the WordPress admin. If your hit rate is below 80%, something’s misconfigured—either the cache isn’t being populated correctly, or your queries aren’t cacheable.

    After enabling object caching, test these scenarios:

    • Load your homepage twice in quick succession. The second load should be faster.
    • Publish a new post and confirm it appears immediately (not after a manual cache flush).
    • Check your server’s memory usage. Redis should sit around 50–100 MB for a typical site. If it’s ballooning past 500 MB, your cache isn’t expiring old data.

    One non-obvious tip

    Not all database queries should be cached. User-specific data—cart contents, login states, personalized recommendations—needs to stay dynamic. If you cache those, you’ll serve the wrong content to the wrong people.

    Most caching plugins exclude these by default, but custom plugins don’t always play nice. If you’re seeing logged-in users get logged-out views, or vice versa, check your cache exclusions. You may need to add specific query keys or user roles to a denylist.

    The other gotcha: WordPress transients. These are temporary database entries that plugins use to store short-lived data—API responses, rate-limit counters, import progress. If your object cache is working, transients get stored in Redis instead of MySQL. That’s faster, but it also means transients disappear when you flush the cache. If a plugin relies on a transient sticking around, flushing can break it mid-operation.

    Check your transient usage with a plugin like Transients Manager. If you see hundreds of expired transients piling up, something’s writing to the cache inefficiently.

    Want more infrastructure breakdowns like this? Reply and tell us what hosting or performance topic to tackle next—or subscribe to catch every Tuesday tutorial.

Powered by
►
Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.
None
►
Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.
None
►
Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.
None
►
Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.
None
Powered by