One Two Three Send

Author: onetwothreeadmin

  • Workflow automation breaks when you automate the wrong tasks

    Workflow automation breaks when you automate the wrong tasks

    Automation promises leverage: build once, run forever. But most operators automate the wrong parts of their workflow and end up maintaining complex systems that create more work than they save.

    The pattern shows up everywhere. You build a Zapier chain to auto-tag newsletter subscribers based on link clicks, but the logic requires weekly updates as your content strategy shifts. You set up auto-posting for social media, but you spend thirty minutes each morning reviewing the queue to make sure nothing looks tone-deaf. You create templated email responses, but every message still needs five minutes of customization.

    You’ve automated tasks that require judgment, and now you’re babysitting robots.

    Repetition vs. decision-making

    The clearest line in workflow automation separates repetitive execution from decision-making. Repetitive tasks have fixed inputs and predictable outputs. Decision-making tasks require context, comparison, or subjective evaluation.

    Good automation candidates: sending a welcome email when someone subscribes, posting a blog link to Twitter fifteen minutes after publish, copying form submissions into a spreadsheet, generating weekly traffic reports, resizing images to specific dimensions.

    Bad automation candidates: deciding which blog post to write next, choosing whether a subscriber should receive the advanced or beginner nurture sequence, determining if a social post needs a content warning, writing personalized outreach emails, selecting which analytics metrics matter this month.

    The bad candidates aren’t impossible to automate—tools exist for all of them—but the automation requires constant tuning. You end up spending more time adjusting the system than you would just doing the task manually.

    Volume thresholds matter

    A task doesn’t need automation just because it’s repetitive. It needs automation when the repetition happens frequently enough that manual execution creates meaningful friction.

    Posting your newsletter link to three social channels once a week takes ninety seconds. Building and maintaining a Zapier workflow to do it automatically saves you six minutes per month and costs $20 on the starter plan if you’re already at your task limit. The math doesn’t work unless you’re publishing daily or managing multiple publications.

    Real automation wins happen at volume. If you’re processing fifty Typeform submissions per week, auto-copying them to Airtable makes sense. If you’re getting five, open the form and copy-paste. If you’re sending three sponsor invoices per month, write them manually. If you’re sending thirty, template the hell out of them and connect Stripe to your CRM.

    The break-even point sits somewhere between five and twenty repetitions per week, depending on task complexity and your comfort with automation tools. Below that threshold, you’re optimizing for elegance, not efficiency.

    Maintenance cost is invisible until it isn’t

    Every automation you build accumulates technical debt. APIs change. Platforms deprecate endpoints. Your own business model shifts and the workflow that made sense six months ago now routes leads to a landing page you deleted.

    I’ve seen operators running Zapier accounts with forty active Zaps, half of which haven’t triggered in sixty days. They’re paying for automation insurance—workflows built for edge cases that never scaled—but they can’t delete them because they’re not sure what will break.

    The maintenance cost shows up in three places: debugging time when something stops working, cognitive overhead remembering what each workflow does, and opportunity cost from paths you didn’t explore because the current system was “good enough.”

    A working rule: if you haven’t touched an automation in ninety days and it’s not mission-critical (welcome emails, payment receipts, backup jobs), delete it. You’ll rebuild it faster than you think if you actually need it again, and you’ll rebuild it better because you’ll know more about what you actually need.

    What to automate right now

    Start with pure data movement: form to spreadsheet, spreadsheet to email, email to task manager, new post to social channel. These workflows have no decision layer. They take structured input and copy it somewhere else without transformation.

    Then move to scheduled reporting: weekly traffic summaries, monthly revenue roll-ups, daily backup confirmations. Anything that pulls existing data into a readable format on a fixed calendar.

    Stop before you automate anything that requires you to review output before it goes live. The review step is the real task. The automation is just a draft generator, and draft generators are only valuable if they’re faster than doing it yourself.

    If you’re spending more than ten minutes per week adjusting an automation, you’ve automated a decision, not a task. Turn it off and do the work manually until the decision becomes repetitive enough to codify.

    One Two Three Send runs on a mix of automatic and manual workflows. Some things—like this newsletter hitting your inbox—are fully automated. Others, like choosing what to write about, will never be. If you want more breakdowns of what works and what doesn’t in small-scale online operations, subscribe here.

  • Memberful vs. Patreon vs. Ghost: which membership platform to pick

    If you’re building a paid membership or subscription offering, you’ve probably narrowed your shortlist to Memberful, Patreon, or Ghost. All three can collect recurring payments and gate content. All three integrate with Stripe. But the differences in control, pricing structure, and long-term flexibility matter more than the feature checklists suggest.

    Here’s what each platform does well, where it falls short, and who should pick which.

    Memberful: WordPress integration and full subscriber ownership

    Memberful positions itself as the membership layer for WordPress sites. You install a plugin, connect your Stripe account, and sell access to posts, pages, or downloadable resources. Subscribers log in via your domain. You own the customer relationship and the email list outright.

    Pricing: Memberful takes 4.9% of gross revenue after Stripe’s cut, with no flat monthly fee until you cross $10,000/month in revenue—then it’s a negotiated enterprise plan. If you’re earning $500/month, you’re paying roughly $25 to Memberful plus Stripe’s 2.9% + $0.30 per transaction.

    Pros: Full design control if you’re comfortable with WordPress themes. No platform lock-in—your subscriber data lives in your own database. You can export and migrate without losing payment history. Memberful also integrates with ConvertKit, Mailchimp, and other ESPs, so your membership list can feed your newsletter automation.

    Cons: You’re responsible for hosting, SSL certificates, plugin conflicts, and WordPress updates. If your site goes down, signups stop. There’s no built-in community forum or mobile app. Memberful is a checkout system, not a content platform.

    Best for: Operators who already run a WordPress site, want to retain full subscriber ownership, and don’t mind managing infrastructure. If you’re selling premium articles, courses, or downloadable resources alongside free content, Memberful fits cleanly.

    Patreon: built-in audience and discovery, but steep fees

    Patreon offers a hosted membership page, payment processing, and access to its internal discovery feed. Creators publish posts in tiers, offer perks like early access or behind-the-scenes content, and optionally run Discord communities or live streams.

    Pricing: Patreon’s Lite plan takes 5% of monthly income. The Pro plan (8%) adds analytics, custom member tiers, and promotional tools. The Premium plan (12%) includes priority support and team accounts. Stripe fees stack on top, so you’re paying 7.9% to 14.9% total on every transaction.

    Pros: Zero setup friction. You don’t host anything. Patreon’s algorithm surfaces your page to potential members browsing categories, which can drive cold discovery if you’re in a popular niche like podcasting, gaming, or comics. The mobile app keeps members engaged. Patreon also handles VAT/sales tax compliance automatically.

    Cons: Patreon owns the subscriber relationship. You can’t export payment history or migrate members to another platform without asking them to re-subscribe. The 12% fee on the Premium tier becomes expensive fast—if you’re earning $5,000/month, you’re handing Patreon $600 plus Stripe’s cut. The platform also tilts heavily toward creative communities; if you’re running a business newsletter or SaaS content site, the branding feels off.

    Best for: Creators who prioritize ease of launch over ownership, operate in visual or entertainment niches, and want access to Patreon’s built-in audience. If you’re starting from zero followers and need discovery, the trade-off makes sense early on.

    Ghost: publishing platform with membership baked in

    Ghost is an open-source CMS designed for publishers. It includes newsletter delivery, membership tiers, and native Stripe integration. You can self-host or pay for Ghost’s managed hosting, which starts at $9/month for up to 500 members.

    Pricing: Ghost’s managed hosting scales with member count. The Starter plan ($9/month) covers 500 members and 1,000 emails. The Creator plan ($31/month) handles 1,000 members and 10,000 emails. The Team plan ($63/month) supports 2,500 members and 25,000 emails. Beyond that, you’re on custom enterprise pricing. Ghost takes no percentage of your revenue—you pay only Stripe’s standard fees.

    Pros: Flat monthly pricing with no revenue cut. You own your member data and can self-host if you want full control. Ghost’s editor is fast, its newsletter delivery is solid, and you can run free and paid tiers from a single install. The platform ships with built-in SEO tools, analytics, and member segmentation.

    Cons: Ghost is a full CMS, not a plugin. If you’re already running WordPress, switching to Ghost means migrating your entire site or running two separate properties. The theming system is less flexible than WordPress—customization requires Handlebars templates and some JavaScript. Ghost also lacks community features like forums or comments without third-party integrations.

    Best for: Publishers and newsletter operators who want a clean, opinionated platform and don’t need WordPress’s plugin ecosystem. If you’re launching a new paid publication from scratch or consolidating a blog and newsletter into one system, Ghost makes sense. If you already have 10,000 WordPress posts, migration pain outweighs the benefits.

    Which one to pick

    If you already run WordPress and want to add membership without changing infrastructure, use Memberful. If you’re a creator in a visual niche and need discovery more than ownership, start with Patreon and plan to migrate later. If you’re building a subscription publication from the ground up and want predictable costs, Ghost wins.

    None of these platforms locks you in forever, but switching costs time and risks churn. Pick based on where you are now and where you’ll be in twelve months, not just the feature grid.

    Running a membership or paid newsletter? Reply and tell us which platform you picked—and what you wish you’d known before launching.

  • ConvertKit subscriber scoring: what it tracks and when to ignore it

    ConvertKit assigns every subscriber an engagement score between 0 and 100. The platform updates it automatically based on opens, clicks, and reply activity. The idea: surface your most engaged readers so you can treat them differently—early product access, exclusive content, or tighter segmentation.

    Most operators never look at it. Those who do often misread what the number actually represents.

    How the scoring algorithm works

    ConvertKit’s engagement score weighs three behaviors:

    • Email opens — tracked via pixel load; weighted heaviest in the first 48 hours after send
    • Link clicks — any tracked link in any broadcast or sequence; weighted more than opens
    • Replies — direct email replies to your sends; highest weight, but rare for most lists

    The score decays over time. A subscriber who opened every email in January but none in February will drop from 95 to the mid-60s by March. ConvertKit doesn’t publish the exact decay curve, but testing suggests it’s roughly 5–8 points per month of inactivity.

    Scores update within 24 hours of each tracked action. You can’t adjust the weighting, turn off specific signals, or reset a score manually.

    What the score misses

    Engagement scoring sounds useful until you realize what it ignores:

    Forwarded opens. If a subscriber forwards your email to a colleague who opens it, ConvertKit counts that as the original subscriber’s engagement—even though they didn’t read it themselves. High score, zero intent.

    RSS-to-email and read-later apps. Subscribers using Feedbin, Instapaper, or similar aggregators trigger opens without clicking through. Their scores stay artificially high even if they never visit your site.

    Purchase behavior. A subscriber who buys your course but never opens marketing emails will score low. ConvertKit doesn’t integrate Stripe or payment data into the engagement algorithm, so your best customers often rank in the bottom quartile.

    Time on site. If someone clicks your link, spends eleven minutes reading, and shares it on Twitter, ConvertKit logs one click. Same score as someone who clicked by accident and bounced in two seconds.

    When to use scoring—and when to build your own segments

    Engagement scoring works well for one thing: suppressing low-intent subscribers before a product launch. If you’re announcing a paid offering and want to avoid spam complaints, excluding everyone below a score of 40 cuts deadweight without manual list pruning.

    It’s also decent for identifying who to re-engage. Subscribers in the 20–50 range aren’t completely cold; a targeted win-back sequence often pulls them back up.

    Where it fails: prioritizing high-value actions. If you run a paid newsletter, a sponsorship-driven site, or sell products, engagement score won’t tell you who actually pays. You need custom segments:

    • Tag subscribers on purchase (via Zapier or ConvertKit’s Stripe integration)
    • Tag clicks on specific high-intent links—pricing pages, checkout, affiliate offers
    • Tag manual replies or survey completions

    Then filter by tags, not score. A subscriber tagged “Paid 2026” with a score of 30 is worth infinitely more than someone scored 95 who’s never clicked a buy button.

    The non-obvious tip: use scoring to find accidental unsubscribes

    Here’s the move most operators miss: filter for unsubscribed contacts with scores above 70.

    ConvertKit lets you view engagement scores even after someone unsubscribes. If a highly engaged reader opts out, there’s a decent chance it was accidental—they meant to unsubscribe from a different list, or clicked the wrong link on mobile.

    Export that segment monthly. Email them directly (outside ConvertKit, one-to-one) with a plain-text note: “Noticed you unsubscribed but were opening every email—just checking that was intentional. If not, here’s the re-subscribe link.”

    Conversion rate on that outreach runs around 15–20%. You’re not spamming; you’re catching UI mistakes before the reader forgets your site exists.

    Want sharper segmentation strategies that actually tie to revenue? Subscribe to One Two Three Send for weekly breakdowns of the tools, tactics, and pricing details that matter when you’re running a content business solo.

    Engagement scoring isn’t useless—it’s just not the complete picture ConvertKit’s UI implies. Treat it as one signal among many, and build your own segments around the actions that actually predict revenue.

  • SEO content briefs bloat into project-management theatre

    SEO content briefs bloat into project-management theatre

    The average SEO content brief now runs twelve pages. It includes competitor analysis tables, semantic keyword clusters, readability targets, word-count ranges, internal linking maps, and a mood board no writer asked for.

    Most of it gets ignored. The rest slows down production without improving rankings.

    If you’re running a content operation—whether you’re writing yourself or managing freelancers—the brief has become a bottleneck dressed up as rigour. It’s time to strip it back.

    What actually belongs in a content brief

    A useful brief answers three questions: what’s the searcher trying to do, what format wins the SERP right now, and what angle are we taking that the top five results aren’t?

    That’s it. You don’t need a target word count—Google doesn’t rank by length. You don’t need a list of twenty secondary keywords—writers stuff them awkwardly or ignore them entirely. You don’t need competitor content scored on eight dimensions—your writer isn’t going to read all that before they start drafting.

    Here’s what works:

    • Search intent in one sentence. “Someone searching this wants to compare hosting providers by uptime and support quality, not price.”
    • Current SERP format. “Top five results are all comparison tables with pro/con lists. No listicles, no ultimate guides.”
    • Our unique angle. “We’re focusing on support response times during outages—none of the ranking pages mention that.”
    • Must-include points. Three to five bullet points. Not twenty.
    • Internal link targets. Two or three related posts to link to, with anchor text suggestions.

    If your brief is longer than one page, you’re writing documentation, not direction.

    Why bloated briefs survive

    The twelve-page brief exists because it looks like strategy. It reassures stakeholders. It justifies billable hours. It makes the content process feel scientific.

    But search engines don’t reward process—they reward usefulness. A 3,000-word article built from a one-page brief can outrank a 5,000-word piece that took three days to brief and another two to write.

    Bloated briefs also create a false sense of control. If you specify readability scores, heading density, and keyword placement down to the paragraph, you think you’re de-risking the content. In practice, you’re just making writers slower and less confident.

    Good writers need context and constraints, not instructions. If you’re hiring someone who needs a twelve-page brief to write a comparison post, you’ve hired the wrong person.

    What to do instead

    Start with a keyword and a one-sentence intent statement. Open an incognito window, search the term, and note the format of the top five organic results. Write down what they all cover, then write down what none of them cover.

    That gap is your angle. That’s the brief.

    If you’re working with freelancers, send them the keyword, the intent sentence, the SERP format, your angle, and three to five must-cover points. If they come back with questions, answer them in Slack or email—don’t pre-emptively document every edge case.

    Track what works. After thirty pieces, you’ll know whether your writers need more direction on structure, internal linking, or research depth. Adjust the template based on actual patterns, not imagined risk.

    When detail matters

    There are cases where a longer brief makes sense. If you’re writing a technical guide that requires SME input—say, a comparison of WordPress caching plugins with benchmark data—you’ll need more scaffolding. If you’re briefing a writer in a field they don’t know well, you might include definitions or background links.

    But even then, the brief should be a resource, not a script. The writer should be able to ignore half of it and still produce something that ranks.

    If your content operation is producing fewer than two pieces per writer per week, look at your briefs first. Chances are you’re spending more time on planning theatre than on publishing.

    What’s in your content briefs right now? Reply and let me know what you’ve cut—or what you’re still hanging onto that probably doesn’t need to be there.

  • WordPress database backups fail silently—here’s what to check

    Most solo operators discover their WordPress backup plugin failed the moment they need to restore something. By then, weeks or months of content, subscriber data, or order history are gone.

    Silent backup failures happen more often than platform dashboards admit. Plugins report green checkmarks while actual backups sit incomplete, corrupt, or missing entirely. This guide walks through the specific checks that catch failures before they cost you.

    Why WordPress backups fail without throwing errors

    Backup plugins rely on server resources—CPU, memory, execution time—that shared hosting environments throttle aggressively. When a backup job hits a limit, the process dies mid-export. The plugin logs a start time, assumes success, and moves on.

    Three common culprits:

    • PHP max_execution_time caps kill long-running database exports, especially on sites above 500 MB. The plugin times out before writing the full SQL dump.
    • Remote storage API failures break silently when Google Drive, Dropbox, or S3 tokens expire or hit rate limits. The plugin creates a local file but never uploads it.
    • Database table corruption during export causes incomplete dumps. The plugin writes a file, but restoring it fails because critical tables are missing rows.

    Most backup dashboards show “last backup: 2 hours ago” without validating file integrity or confirming the remote copy exists.

    Manual checks that catch silent failures

    Run these four checks monthly, or after any plugin/theme update that changes your database schema.

    1. Verify remote storage actually received the file. Log into your Dropbox, Google Drive, or S3 bucket. Sort by date modified. Confirm the most recent .zip or .sql file timestamp matches your plugin’s “last backup” log. File size should match or exceed previous backups unless you deleted content.

    2. Download and unzip the backup locally. Corrupt archives throw errors when you try to extract them. If the .zip opens but the database .sql file inside is under 1 MB on a site with years of posts, the export likely truncated.

    3. Scan the SQL dump for table completeness. Open the .sql file in a text editor. Search for CREATE TABLE statements. You should see wp_posts, wp_postmeta, wp_users, wp_options, and any custom tables your plugins add. Missing tables mean the backup won’t restore your site to its current state.

    4. Check plugin error logs, not dashboards. Most backup plugins write verbose logs to /wp-content/uploads/backups/ or similar. Look for lines containing “timeout,” “memory,” “curl error,” or “failed to write.” These warnings rarely surface in the admin UI.

    Fixing the three most common failure modes

    Execution timeouts: Increase max_execution_time in your php.ini or .htaccess, or split backups into separate database and file jobs. Plugins like UpdraftPlus let you run database and media exports independently, each staying under time limits.

    Remote storage auth failures: Reauthorize API connections every 90 days. Google Drive tokens expire; Dropbox app permissions get revoked during security audits. Test remote upload manually after reauthorizing.

    Database corruption: Run wp db repair via WP-CLI, or use phpMyAdmin’s repair function on tables flagged in error logs. Schedule this quarterly if you run high-traffic membership or e-commerce sites that hammer the database.

    When to test a full restore

    Backups you’ve never restored are backups you don’t actually have. Spin up a local environment or staging server once per quarter and restore your most recent backup end-to-end. Time the process. Note what breaks.

    Common restore gotchas: hardcoded domain URLs in serialized post meta, missing .htaccess rules, and plugins that store config outside the database (API keys in wp-config.php). Document the manual steps required so you’re not figuring them out during an outage.

    If restoring takes longer than 30 minutes or requires more than three manual fixes, your backup strategy isn’t production-ready. Simplify your plugin stack or move to managed WordPress hosting that handles backups at the server level.

    Set a calendar reminder right now: first Sunday of every month, download your latest backup and verify the SQL file opens and lists your tables. It takes four minutes and catches 90% of silent failures before they matter.

    What’s your backup horror story? Hit reply—we’re collecting operator war stories for a future piece on disaster recovery workflows that actually work under pressure.

  • Monetisation attribution dies in multi-touch funnels

    Monetisation attribution dies in multi-touch funnels

    You run a sponsored issue, push an affiliate link on social, mention a product in your archive, and three weeks later someone buys. Your analytics platform credits the sale to “direct traffic” or the last click before checkout. You have no idea which channel actually worked.

    This isn’t a tracking-pixel problem. It’s a structural flaw in how most solo operators measure revenue when the buyer journey spans email, social, organic search, and word-of-mouth over days or weeks.

    Single-touch attribution—first click or last click—works when the path is short. It collapses when your funnel has five steps, three platforms, and a fourteen-day consideration window. And if you’re running a content business, that’s the norm, not the exception.

    Why last-click attribution lies

    Most analytics tools default to last-click: the final referrer before conversion gets full credit. If someone clicks your affiliate link in a newsletter, browses for ten minutes, leaves, then Googles the product name two days later and buys via organic search, Google gets the sale. Your newsletter sees nothing.

    Stripe’s payment links don’t carry session history. Gumroad’s dashboard shows referrer data, but only for the session that completed checkout. ConvertKit and Beehiiv track link clicks, but those events live in separate databases from your revenue analytics. Unless you stitch them manually, the attribution breaks at the platform boundary.

    First-click attribution has the opposite problem: it over-credits discovery and ignores the nurture work. If someone found you via a Reddit comment six months ago, subscribed, read forty emails, then bought after a single product mention, Reddit gets full credit. The forty emails that built trust? Invisible.

    Multi-touch models operators actually use

    Enterprise marketing teams run algorithmic attribution—machine learning models that weight every touchpoint. Solo operators don’t have the data volume or engineering budget for that. But three simpler models work without custom code:

    Linear attribution: Split credit equally across all known touchpoints. If someone clicked three emails, visited your site twice via organic search, and converted via a social link, each touchpoint gets 20%. This assumes every step mattered equally, which is wrong, but it’s better than crediting one channel with 100%.

    Time-decay attribution: Give more weight to recent interactions. Touchpoints closer to conversion get higher percentages. A click seven days before purchase counts less than a click seven hours before. This mirrors how buying intent escalates, but it still undervalues early discovery.

    Position-based (U-shaped) attribution: Credit 40% to first touch, 40% to last touch, and split the remaining 20% across middle interactions. This rewards both discovery and conversion while acknowledging the nurture steps. It’s the model I see most operators settle on after trying the others.

    How to track multi-touch revenue without enterprise tools

    You don’t need Segment or a six-figure contract with HubSpot. You need three things: consistent UTM tagging, a spreadsheet or lightweight database, and a workflow that logs touchpoints before checkout.

    Tag every outbound link with UTM parameters that include source, medium, and campaign. Your newsletter links get ?utm_source=newsletter&utm_medium=email&utm_campaign=2026-06-06. Social posts get ?utm_source=twitter&utm_medium=social. Affiliate mentions get a unique campaign slug. Apply this everywhere, every time.

    Use a tool that logs those UTM parameters at the session level. Google Analytics 4 can do this if you set up custom dimensions for first and last UTM source. Plausible Analytics stores referrer data in its event stream. Fathom Analytics offers custom event properties. All three let you export CSVs with timestamp, session ID, and UTM values.

    At checkout, append a hidden field or order note that captures the customer’s email or a hashed session ID. In Stripe, use metadata fields. In Gumroad, add a custom field to the checkout form. In WooCommerce, log UTM data to the order meta table with a lightweight plugin or custom function.

    Once a week, export your revenue data and your session logs. Match customer email or session ID across both. Map out the sequence of touchpoints that led to each purchase. Assign attribution percentages using whichever model you chose. Update a running tally of channel performance.

    This workflow takes about ninety minutes a week for a business doing twenty to fifty transactions a month. It’s manual, but it’s accurate enough to shift budget and effort toward the channels that actually drive revenue.

    What breaks and when to simplify

    Multi-device journeys wreck this system. If someone reads your newsletter on mobile, researches on desktop, and buys on tablet, session IDs won’t match unless they log in. Email hashing helps, but only if you collect it at multiple touchpoints.

    Word-of-mouth and dark social—shares via Slack, WhatsApp, direct messages—show up as direct traffic. You can’t track them without unique links for every share, which isn’t realistic. Accept that 20–30% of your revenue will stay unattributed.

    If your average sale is under $30 and you’re doing fewer than ten transactions a week, the juice isn’t worth the squeeze. Stick with last-click and focus on growing volume instead of optimising attribution. Multi-touch matters when you’re allocating real money across channels or deciding which content to double down on.

    Want more breakdowns of what works and what breaks in online-business operations? Subscribe to One Two Three Send and get one focused article like this in your inbox every week.

    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 CDN purge failures cost you traffic—here’s why

    WordPress CDN purge failures cost you traffic—here’s why

    You publish a time-sensitive post, hit save, and assume it’s live everywhere. But CDN cache purge doesn’t always work the way you think—and when it fails silently, you’re serving stale content to the readers who matter most.

    This isn’t a theoretical edge case. CDN purge failures happen daily across WordPress sites, especially when you’re running caching layers, security plugins, or multi-region delivery. The result: your homepage shows yesterday’s headline, your pricing page displays the old offer, and Google crawls a version of your post that’s missing the updated title tag.

    Here’s what actually happens when you hit publish, why purge requests fail, and how to verify your content is live before you share it.

    What happens when you publish a WordPress post

    When you click “Publish” in WordPress, several cache layers need to clear:

    • Object cache (Redis or Memcached, if enabled)
    • Page cache (WP Rocket, W3 Total Cache, LiteSpeed Cache)
    • CDN edge cache (Cloudflare, Bunny CDN, StackPath)
    • Browser cache (controlled by headers, not purge requests)

    Your caching plugin is supposed to send a purge request to the CDN when content changes. But purge requests are API calls—and API calls fail. The CDN might time out, the plugin might send the wrong URL format, or your firewall might block the purge webhook.

    The worst part: most purge failures are silent. WordPress doesn’t throw an error. The CDN logs the request but doesn’t retry. You think the post is live, but edge servers in London, Sydney, and Singapore are still serving the cached version for another hour.

    Why CDN purge requests fail

    URL mismatch between WordPress and the CDN. If your WordPress site uses http:// internally but your CDN serves https://, the purge request targets the wrong URL. Same problem if you’re using www. in one place and not the other. The CDN gets a purge request for a URL it doesn’t recognize, shrugs, and moves on.

    Wildcard purge disabled or misconfigured. Some CDN plans—especially free tiers—limit wildcard purges. If you update a post that appears on your homepage, archive pages, and RSS feed, you need to purge all of those URLs. If your plugin tries to purge /blog/* but your CDN only allows exact-match purges, nothing clears.

    Rate limiting on the CDN API. Cloudflare’s free plan allows 1,200 purge requests per day. That sounds like a lot until you’re editing a post multiple times, auto-saving drafts, and triggering purge requests on every revision. Hit the limit, and your next purge fails silently.

    Caching plugins that don’t talk to your CDN. Not every WordPress cache plugin supports every CDN. WP Rocket has built-in Cloudflare integration. LiteSpeed Cache works natively with LiteSpeed servers. But if you’re using a generic cache plugin with a smaller CDN, you might need a separate purge plugin—or manual API calls.

    How to verify your content is actually live

    Don’t trust the WordPress admin. Check the edge.

    The fastest way: open an incognito window and load your post URL. If you see the old version, the cache hasn’t cleared. But that only checks your edge location. If you’re in New York and your readers are in Berlin, you’re not seeing what they see.

    Better: use a CDN cache checker. Tools like RedBot or KeyCDN’s cache checker let you test specific URLs and see cache headers from multiple locations. Look for X-Cache: HIT or CF-Cache-Status: HIT in the response headers. If the Age: header shows a value higher than a few seconds after you published, you’re serving stale content.

    If you’re running Cloudflare, check the dashboard under Caching → Configuration → Purge Cache. You can manually purge individual URLs or the entire cache. If you do this every time you publish, your plugin isn’t working.

    How to fix purge failures before they cost you traffic

    Set your WordPress site URL to match your CDN exactly. Go to Settings → General and make sure WordPress Address (URL) and Site Address (URL) match the protocol and subdomain your CDN uses. If your CDN serves https://www.yoursite.com, both fields should say that. No exceptions.

    Enable wildcard purges or use cache tags. If your CDN supports cache tags (Cloudflare’s Cache-Tag header, Fastly’s Surrogate-Key), configure your caching plugin to tag pages by post ID, category, and archive type. When you update a post, purge by tag instead of URL. This clears every page that references that post, not just the post itself.

    Monitor purge success in your CDN logs. Cloudflare, Bunny, and most CDNs log purge requests. Check the logs weekly. If you see 4xx or 5xx responses, your purge requests are failing. Fix the integration before it compounds.

    Use a staging environment to test purge behavior. Before you publish a high-stakes post—launch announcement, pricing change, time-sensitive news—test the purge flow on staging. Publish the post, wait 30 seconds, check the live URL. If staging purges correctly, production should too. If not, you know before the post goes live.

    If you’re on a host that handles CDN integration for you—BigScoots and other managed WordPress hosts often do—verify that their purge automation covers all the URLs you care about. Ask support which cache layers clear automatically and which require manual intervention.

    When to bypass CDN cache entirely

    Some pages should never be cached at the edge: checkout pages, account dashboards, anything behind a login. Use cache bypass rules in your CDN config to exclude those URLs from edge caching entirely. That way, purge failures can’t hurt conversion flows.

    For time-sensitive content—live event updates, breaking news, flash sales—set a short TTL (60 seconds or less) instead of relying on purge. The CDN will refresh automatically, and you won’t lose traffic if a purge request fails.

    CDN purge isn’t fire-and-forget infrastructure. It’s an API call that fails more often than you think. The operators who verify purge success before sharing a post are the ones whose readers see the right content at the right time.

    Got a caching setup that’s failed you before? Reply and tell us what broke—we’ll cover it in a future issue.

  • Publer’s Auto-Posting Queue: How Priority Slots Work and When to Use Them

    Publer’s Auto-Posting Queue: How Priority Slots Work and When to Use Them

    Publer‘s auto-posting queue doesn’t work like a simple calendar. When you schedule posts across multiple social accounts for the same time slot, the platform uses a priority system to decide what publishes first—and if you don’t configure it correctly, your most important content can get stuck behind low-priority filler.

    This matters when you’re juggling LinkedIn, Twitter, Instagram, and Facebook from a single dashboard. Each network has different API rate limits and posting windows. Understanding how Publer‘s queue prioritizes posts means the difference between coordinated launches and staggered, inconsistent publishing.

    How the Priority Queue Actually Works

    When you schedule multiple posts for the same timestamp, Publer doesn’t publish them simultaneously. It queues them according to three factors: account priority, post type, and API availability.

    Account priority is the setting most operators miss. In your workspace settings, each connected social account has a priority value from 1 to 10. When two posts compete for the same slot, Publer publishes the higher-priority account first. Default priority is 5 for all accounts, which means new users get effectively random ordering.

    Post type matters because different formats take different amounts of time to process. A text-only tweet publishes in under a second. A carousel post with eight images to Instagram takes 15–30 seconds because Publer has to upload media, wait for Instagram’s processing, then attach metadata. If you schedule both at 9:00 AM, the tweet goes live at 9:00:02 and the carousel lands closer to 9:00:35.

    API availability is the wildcard. LinkedIn’s API occasionally throttles requests during peak hours (weekday mornings in US time zones). Facebook’s API can reject posts if your page has recent policy warnings. When Publer hits a rate limit or error, it pauses that account’s queue for 60 seconds and moves to the next priority account. Your post still publishes—it’s just late.

    When to Adjust Priority Settings

    Most solo operators should set LinkedIn to priority 8 or 9, Twitter to 7, and Instagram to 6. LinkedIn drives the most referral traffic for B2B content businesses, so it should publish first when time slots overlap. Twitter comes next because it’s time-sensitive; a tweet posted 45 seconds late misses the algorithmic window for early engagement. Instagram posts have longer shelf lives and benefit less from split-second timing.

    If you’re running coordinated launches—a new course, a product drop, a newsletter issue—set all accounts to the same priority and stagger your scheduled times by two minutes. This forces sequential publishing and prevents API collisions. Schedule LinkedIn for 9:00 AM, Twitter for 9:02 AM, Instagram for 9:04 AM. You’ll see consistent publish times and avoid the queue lottery.

    For daily content that isn’t launch-critical, leave priorities at default and use Publer’s “optimal timing” suggestion feature. It analyzes your audience activity and shifts posts into lower-traffic API windows, which reduces queue conflicts organically.

    The Non-Obvious Tip: Use Priority Slots for Backup Accounts

    Here’s what most people miss: you can connect duplicate accounts with different priority levels to create a fallback system. Connect your primary Twitter account at priority 8, then connect a secondary Twitter account (a brand backup or personal account) at priority 3.

    Schedule the same post to both accounts. If your primary account hits a rate limit, suspension, or API error, Publer skips it and publishes to the backup account automatically. You don’t lose the time slot, and your content still goes live. This setup is especially useful for affiliate promotions or time-sensitive announcements where missing a window costs real money.

    The trade-off: duplicate posts count against your Publer plan limits. The $12/month plan includes 50 scheduled posts across all accounts. If you’re doubling up for redundancy, you hit that cap faster. Upgrade to the $29/month tier for 300 posts, or reserve backup posting for high-value content only.

    What Breaks and How to Fix It

    Publer’s queue log lives under Analytics > Post History. If a post doesn’t publish on time, the log shows the delay reason: API error, media processing timeout, or account priority conflict. Check this weekly, especially if you’re managing client accounts or running paid campaigns.

    The most common failure mode: Instagram carousel posts scheduled during API maintenance windows (usually Sunday mornings, 2–4 AM Pacific). Instagram’s API goes read-only during maintenance, and Publer can’t upload media. Your post fails silently unless you enable push notifications for publishing errors. Turn those on in Settings > Notifications > Publishing Alerts.

    If you’re publishing to Facebook Pages, verify your page token hasn’t expired. Facebook tokens reset every 60 days, and Publer doesn’t always surface the error clearly. You’ll see posts stuck in “Pending” status in the queue, but the error log just says “Authentication failed.” Reconnect your Facebook account in Settings > Social Accounts > Facebook > Reconnect, and past posts will retry automatically.

    Want to see more tool breakdowns like this? Reply with the platform or feature you want dissected next—we’ll add it to the rotation.

    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.

  • AI writing assistants lose your brand voice after 10,000 words

    AI writing assistants lose your brand voice after 10,000 words

    You feed Claude or ChatGPT your style guide, brand voice doc, and three sample articles. The first draft comes back clean. The fifth is still coherent. By draft twelve, you’re rewriting entire sections because the output sounds like a SaaS landing page written by committee.

    The problem isn’t the model. It’s context decay—and most solo operators don’t notice it until they’re deep into a content sprint.

    How context windows actually behave in production

    Modern AI assistants advertise context windows between 100,000 and 200,000 tokens. That sounds massive. In practice, a 2,000-word article with formatting consumes roughly 3,000 tokens. A detailed style guide adds another 1,500. Add three reference articles, a content brief, and iterative edits, and you’re at 15,000 tokens before you hit “generate.”

    The issue isn’t hitting the hard limit. It’s recency bias. AI models weight recent inputs more heavily than older ones. Your brand voice document, uploaded at the start of the session, fades in influence as the conversation grows. By message twenty, the model is prioritizing your last three corrections over the foundational voice rules you set up front.

    This isn’t speculation. Run the same prompt in a fresh session and in a thread with fifteen prior exchanges. The tone, sentence structure, and word choice drift measurably. The fresh session respects your style guide. The deep thread defaults to generic clarity.

    Where the breakdown happens

    Three scenarios accelerate context decay:

    Iterative editing. You ask for a rewrite of paragraph four. Then paragraph seven. Then a punchier intro. Each edit adds tokens. The model starts optimizing for your edits rather than your original brief. If your edits are vague (“make it snappier”), the output drifts toward the model’s base training—usually bland, corporate prose.

    Multi-article sessions. You’re batching content. Article one turns out great. Article two is fine. Article three reads like it was written by a different person. The model is still referencing article one’s context, but it’s now buried under 20,000 tokens of intermediate work. Your style guide is functionally invisible.

    Supplemental instructions mid-thread. You realize the model isn’t using contractions, so you add a note: “Use contractions. Write like a person.” That instruction applies to the current output, but it doesn’t retroactively fix the earlier drift. Worse, it competes with your original style guide, which may have said something more nuanced.

    How to architect around it

    The fix isn’t to abandon AI writing tools. It’s to structure your workflow so the model never has to remember too much at once.

    Start fresh for each piece. Don’t reuse threads across articles. A new session costs you thirty seconds of setup but guarantees your brand voice sits at the top of the context stack. If you’re batching content, open a new chat per article. Yes, you’ll paste your style guide multiple times. That redundancy is weight, not waste.

    Anchor instructions at both ends. Put your core voice rules in the first message and repeat the two most important points in your content brief. Example: if your style guide says “no jargon” and “lead with specifics,” embed those phrases in the article prompt itself. Repetition reinforces priority in the model’s attention mechanism.

    Use system prompts where available. Claude lets you set a system prompt that persists across a conversation. ChatGPT offers custom instructions. Both sit outside the regular context window and don’t decay. Load your brand voice there. Keep it under 300 words—short, imperative statements work better than discursive guidelines.

    Separate editing from generation. If you’re deep into revisions and the tone starts slipping, don’t keep editing in the same thread. Copy the draft into a fresh session, paste your style guide, and ask for a single-pass cleanup. The model will treat your draft as raw input and apply the voice rules uniformly, rather than layering fixes onto fixes.

    What this means for content operations

    If you’re publishing once a week, context decay is invisible. If you’re running a content engine—daily newsletters, multi-author blogs, high-volume SEO plays—it’s the difference between consistent voice and a patchwork of tones.

    The operators who scale AI writing successfully treat it like a stateless function. Each invocation gets the same inputs. No conversation persists long enough to drift. Workflows that rely on “the model will remember” break at volume.

    Track this in your own work. Open your last five AI-generated drafts. Read them in sequence. If draft five sounds meaningfully different from draft one—and you didn’t change your instructions—you’re watching context decay in action.

    One Two Three Send covers the tools and workflows that power solo operations. If you’re running content at scale, subscribe for weekly breakdowns of what works, what breaks, and what costs you time when no one’s watching.

    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.

  • Traffic attribution breaks when you rely on a single UTM parameter

    Traffic attribution breaks when you rely on a single UTM parameter

    You slap a ?utm_source=twitter on a link, post it, and watch Google Analytics log the visits. Job done. Except when you want to know which tweet drove traffic, or whether the thread performed better than the standalone post, you’re looking at an aggregate number that tells you nothing.

    Single-parameter UTM tagging is the norm because it’s fast. But it collapses every variation of a campaign into one bucket. When you run the same link across multiple posts, test different copy, or repost content weeks later, you lose the ability to see what actually worked.

    Why one parameter isn’t enough

    UTM parameters exist in sets: source, medium, campaign, term, and content. Most operators use only source, sometimes medium. That’s enough to tell you traffic came from Twitter or your newsletter, but it won’t help you answer:

    • Did the morning post outperform the evening one?
    • Which subject line variation drove more clicks?
    • Is this week’s guest post pulling better than last month’s?

    Without campaign and content tags, you’re aggregating everything from a source into one line item. If you’re running any kind of test—creative, timing, format—you’re flying blind.

    What to track in each parameter

    Here’s a structure that scales without getting obsessive:

    utm_source: The platform. twitter, linkedin, newsletter, reddit. Keep it consistent. Don’t use Twitter one week and twitter the next—analytics tools are case-sensitive and will split them into separate sources.

    utm_medium: The format or channel type. social, email, paid, organic. This groups sources into broader buckets and makes cross-channel comparisons possible.

    utm_campaign: The specific push or theme. product-launch-june, weekly-roundup-24, black-friday-2026. This is your container for everything related to one coordinated effort.

    utm_content: The variable you’re testing or the specific placement. thread-version-a, header-link, ps-cta. This is where you differentiate two posts in the same campaign.

    Example: You’re running a product launch. You post on Twitter three times over two days—morning thread, afternoon standalone, evening reply-guy style. Tag them:

    • ?utm_source=twitter&utm_medium=social&utm_campaign=product-launch-june&utm_content=morning-thread
    • ?utm_source=twitter&utm_medium=social&utm_campaign=product-launch-june&utm_content=afternoon-standalone
    • ?utm_source=twitter&utm_medium=social&utm_campaign=product-launch-june&utm_content=evening-reply

    Now your analytics show not just that Twitter drove 150 visits, but that the morning thread drove 90, the afternoon post drove 40, and the evening reply drove 20. You know what to repeat.

    Common mistakes that break tracking

    Inconsistent naming. utm_source=Twitter and utm_source=twitter appear as two separate sources. Pick lowercase-with-hyphens and stick to it. Same goes for campaigns: launch_june and launch-june are different.

    Overloading utm_content. Don’t stuff timestamps, user IDs, or session tokens into this field. It’s for human-readable variants, not programmatic tracking. If you need per-user attribution, use a separate query parameter and log it server-side.

    Tagging internal links. Don’t add UTM parameters to links between pages on your own site unless you’re running a specific cross-domain campaign. It resets the session and attributes internal navigation as a new traffic source, which destroys your funnel data.

    Not documenting your taxonomy. Six months from now, you won’t remember whether utm_campaign=june-launch or utm_campaign=product-launch-june was the one you used. Keep a spreadsheet or a Notion page with every active campaign and its naming convention.

    When to simplify

    If you’re posting a link once and never again, a single utm_source is fine. If you’re sharing a static resource—like a media kit or a one-time freebie—you don’t need campaign-level granularity.

    But the moment you’re testing anything—post timing, copy, format, audience segment—you need at least three parameters: source, campaign, and content.

    Traffic attribution only works when you can compare apples to apples. A single UTM parameter turns every variation into the same apple. Add two more, and you’ll finally see what’s working.

    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 solo operators.

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