Author: onetwothreeadmin

  • Google Search Console’s Discover report: hidden traffic you’re missing

    Google Search Console’s Discover report: hidden traffic you’re missing

    Most solo operators check Google Search Console for keyword rankings and click-through rates. They skim the Performance report, maybe filter by a few landing pages, then move on. Meanwhile, there’s a second traffic source sitting in the same dashboard that most people never open: the Discover report.

    Google Discover is the feed that appears when you open a new tab on Chrome mobile or swipe right on Android home screens. It’s algorithmic, personalised, and—when it picks up your content—capable of sending thousands of visits in a single day. Unlike search traffic, you don’t rank for it. Google decides what to show based on user behaviour, topic velocity, and content freshness.

    If you’ve never checked your Discover report, you’re flying blind on a traffic source that could already be working for you—or that you’re one article away from unlocking.

    Where to find it and what it shows

    In Google Search Console, the Discover report lives under the main navigation, separate from the Performance tab. If you don’t see it, that means Google hasn’t logged any Discover impressions for your site in the last 16 months. That’s not a failure—it just means your content hasn’t triggered the algorithm yet, or your audience demographic skews desktop-heavy.

    If the report is there, you’ll see impressions and clicks broken down by URL and date. Unlike search traffic, there are no keywords. Discover doesn’t work that way. Users don’t query; Google surfaces content it thinks they’ll engage with based on past behaviour and trending topics.

    The chart will show spikes—sometimes dramatic ones. A single article can go from zero Discover impressions to 40,000 in 48 hours, then drop back to nothing. That’s normal. Discover traffic is bursty and short-lived, unlike the steady climb of organic search.

    What triggers Discover traffic

    Google hasn’t published a scoring rubric, but patterns emerge when you compare performing URLs. Discover favours:

    • Recency. Articles published or updated in the last 72 hours perform better. Evergreen content rarely appears unless it’s tied to a breaking news hook.
    • High-quality images. Google explicitly recommends large images (at least 1200px wide). Articles without featured images or with low-resolution thumbnails get filtered out.
    • Topics with momentum. If a subject is trending across the web—new product launches, regulatory changes, viral discourse—Discover amplifies it. Niche topics with low search volume can still perform if the zeitgeist is right.
    • Engagement signals. If users who do see your content in Discover click, read, and don’t bounce immediately, Google shows it to more people. If they swipe past, it dies.

    Crucially, Discover doesn’t care about your domain authority or backlink profile the way search does. A two-month-old site can land in Discover if the content and timing align. That makes it one of the few Google traffic sources where new operators compete on roughly equal footing.

    How to use the data

    If you are getting Discover traffic, the report tells you which topics and formats resonate outside of search intent. Compare your top Discover URLs to your top search URLs. If they don’t overlap, you’ve found a content wedge: topics that people engage with when surfaced passively, even if they’re not actively searching for them.

    Check the date pattern. If your Discover traffic clusters around publication day and fades within a week, that’s a signal to publish more frequently in that topic area. Discover rewards freshness, so a higher cadence gives you more at-bats.

    If a specific article spiked, look at what made it timely. Did you tie it to a news event? A product launch? A meme cycle? Discover isn’t a place for evergreen SEO content—it’s a feed, and feeds thrive on the new.

    One non-obvious move: if you’re seeing Discover impressions but low click-through, your image or headline isn’t pulling its weight. Discover users scroll fast. Your thumbnail needs to stop the thumb, and your headline needs to justify the tap. Test different featured images and headline styles in future posts. Discover traffic is free A/B testing for visual appeal.

    What it means if you’re not in Discover yet

    Most content sites won’t see Discover traffic, and that’s fine. It’s not a requirement for a healthy business. But if you’re publishing timely, visual content in areas where people have passive interest—tech releases, industry news, cultural commentary—it’s worth optimising for.

    The barrier to entry is lower than you think: add large images, publish when a topic is moving, and make sure your site is mobile-friendly. Google’s more likely to surface you in Discover if your content works well on the platform where Discover lives—phones.

    If you want to see whether you’re close, check your Search Console Discover report monthly. Even a handful of impressions means Google is testing you in the feed. If those impressions convert to clicks, the algorithm may start showing you more often.

    Want sharper insights on traffic, tools, and online-business operations? Subscribe to One Two Three Send and get one focused article like this in your inbox every week.

  • Pinterest’s API limits and when your automation will break

    Pinterest’s API limits and when your automation will break

    Pinterest automation feels like free traffic on autopilot—until your scheduler stops working, your pins vanish from the queue, and you’re staring at a 429 error you don’t understand.

    Most operators treat Pinterest like any other social platform: connect a tool, load up a queue, walk away. But Pinterest’s API has hard limits that aren’t advertised in the onboarding flow, and hitting them doesn’t just pause your posts—it can flag your account, break your integrations, and cost you weeks of momentum.

    Here’s what actually happens when you automate Pinterest, where the boundaries are, and when you should schedule manually instead.

    What Pinterest’s API actually restricts

    Pinterest doesn’t publish exact rate limits for third-party tools, but the practical threshold sits around 30–50 API calls per hour for most standard-tier apps. That sounds generous until you realize what counts as a call:

    • Creating a pin
    • Editing a pin description or board assignment
    • Checking pin status or analytics
    • Fetching board lists
    • Validating image URLs

    If you’re using Tailwind, Buffer, or any scheduler that pre-validates images and checks boards before posting, you’re burning 3–5 API calls per scheduled pin—even if it hasn’t published yet. A 30-pin weekly queue can hit the hourly cap before a single post goes live.

    When you cross the threshold, Pinterest returns a 429 “Too Many Requests” error. Most tools retry automatically, which triggers more API calls, which extends the lockout. You won’t get an email. Your posts just stop.

    Where automation breaks down (and doesn’t recover gracefully)

    The worst part isn’t the rate limit—it’s how poorly most tools handle it.

    Tailwind will retry failed pins for 24 hours, burning API calls on each attempt. If you’re near the limit, those retries can block your entire queue for days. There’s no user-facing dashboard that shows you’re rate-limited; pins just show as “pending” indefinitely.

    Buffer pauses the Pinterest connection entirely after repeated 429s, but doesn’t always notify you. You’ll discover it when you check your analytics and realize nothing posted for a week.

    Zapier and Make (formerly Integromat) treat Pinterest API errors as temporary failures and retry aggressively—up to the task limit of your plan. If you’re auto-pinning from an RSS feed or Airtable, a single rate-limit event can consume your entire monthly task allowance in 48 hours.

    None of these tools let you see your API usage in real time. You’re flying blind until something breaks.

    What works: batch scheduling and off-peak windows

    If you’re committed to automation, the fix isn’t a better tool—it’s a tighter schedule.

    Spread your pins across the week instead of loading a 50-pin queue on Monday morning. Pinterest’s API limits reset hourly, so spacing posts 90–120 minutes apart keeps you under the threshold even if your tool pre-validates aggressively.

    Schedule pins during off-peak hours—early morning or late evening in your tool’s server timezone (usually US Pacific). Fewer concurrent users means fewer shared API requests hitting Pinterest’s backend, and you’re less likely to get lumped into a rate-limited batch.

    Turn off auto-retry in tools that support it. Tailwind lets you disable automatic rescheduling under Settings → Publishing. Buffer doesn’t, which is why I stopped using it for Pinterest entirely.

    If you’re using Zapier, add a delay step of 5–10 minutes between trigger and Pinterest action. It won’t eliminate rate limits, but it reduces the chance of bunching requests during high-traffic windows.

    When to skip automation and schedule manually

    Automation makes sense if you’re pinning 10–15 times per week and your content library is stable. But if you’re in any of these scenarios, manual scheduling is faster and more reliable:

    • You’re launching a new board or product line and need to pin 20+ items in 48 hours
    • You’re running a seasonal promo and need same-day pin edits
    • Your Pinterest account is under 6 months old (newer accounts have tighter API limits during the trust-building phase)
    • You’re using a free-tier automation tool that shares API quota across all users

    Pinterest’s native scheduler is clunky, but it doesn’t count against API limits and posts immediately—no validation lag, no retry loops. For high-volume bursts, it’s the only reliable option.

    One tool that handles this better

    If you’re scheduling more than 20 pins per week and need automation, Publer is the only tool I’ve found that surfaces API errors in the dashboard and lets you set custom retry intervals. It’s not an affiliate relationship—it’s just the only scheduler that treats Pinterest’s API limits as a design constraint instead of an edge case.

    Pricing starts at $12/month for 10 social accounts, including Pinterest, and the free tier supports 10 scheduled posts. Not enough for most operators, but enough to test whether your posting cadence will trigger rate limits before you commit to a paid plan.

    If you’re already locked into Tailwind or Buffer, the workaround is simple: cut your weekly queue in half, double your posting intervals, and check your scheduled posts 24 hours after loading them. If anything shows “pending” past the scheduled time, you’ve hit the limit.

    Want more breakdowns like this? Subscribe to One Two Three Send for tool deep-dives, workflow fixes, and the operational details other newsletters skip.

  • ConvertKit’s creator network: how it works and what it actually costs

    ConvertKit’s creator network: how it works and what it actually costs

    ConvertKit’s Creator Network is a cross-promotion engine built directly into the platform. Turn it on, and ConvertKit will recommend your newsletter to readers of similar publications—and recommend others’ newsletters to yours. It’s framed as free, mutual growth. No ad spend, no landing pages, just algorithmic matchmaking between creators.

    The pitch is compelling, especially if you’re early and desperate for subscribers. But the mechanics are more nuanced than the dashboard toggle suggests, and the costs—while not monetary—are real.

    How the network actually works

    When you enable the Creator Network, ConvertKit starts showing recommendation cards to your subscribers. These appear in two places: in a dedicated email ConvertKit sends on your behalf, or embedded at the bottom of your broadcasts if you use their default templates.

    The recommendations are algorithmic. ConvertKit looks at your content tags, subscriber behavior, and engagement patterns, then surfaces newsletters it thinks your readers will like. You don’t choose who gets recommended to your list. ConvertKit does.

    In exchange, your newsletter gets recommended to other creators’ audiences under the same logic. You’re both publisher and advertiser, simultaneously.

    ConvertKit takes a 50% cut of the exposure. If 100 of your subscribers see a recommendation card, ConvertKit will show your newsletter to roughly 50 subscribers on someone else’s list. The ratio isn’t strict, but it’s the general exchange rate.

    What it costs you (and it’s not money)

    The Creator Network is free in dollars, but expensive in control and attention.

    You’re giving ConvertKit permission to email your list. If you enable the standalone recommendation emails, ConvertKit will send a message to your subscribers that you didn’t write, on a cadence you don’t control, promoting newsletters you didn’t vet. Your readers don’t distinguish between “ConvertKit sent this” and “my newsletter sent this.” It’s your sender name. It’s your brand. You own the confusion and the unsubscribes.

    You’re training readers to expect content you didn’t create. Even if you only use in-broadcast embeds, you’re conditioning your audience to scroll past house ads. That’s fine if your newsletter is purely a growth vehicle. It’s corrosive if your newsletter is a trust engine or a product funnel.

    You’re sharing your best readers with competitors. ConvertKit recommends based on engagement. That means your most active subscribers—the ones who open, click, and convert—are exactly the ones being shown other newsletters. You’re not cross-promoting to lurkers. You’re offering your most valuable segment to someone else.

    You have no veto power. You can’t blacklist competitors. You can’t filter by monetization model or editorial quality. If ConvertKit’s algorithm decides a newsletter is similar enough, it gets shown. You’re trusting the platform’s taste and incentives to align with yours.

    When it makes sense to turn it on

    The Creator Network works best in three scenarios:

    If you’re pre-monetization and pure subscriber count is your only goal, the trade-off is reasonable. You’re swapping attention for attention, and you don’t yet have a business model to protect.

    If your newsletter is in a tightly-defined niche where most other creators are collaborators, not competitors—think local news, hyperlocal events, or hobby communities—cross-promotion strengthens the ecosystem instead of fragmenting it.

    If you’re already doing manual cross-promotions and finding it exhausting, the Creator Network automates the same dynamic. You lose control, but you gain scale and consistency.

    The non-obvious tip: use it as a discovery tool, not a growth tool

    Here’s what ConvertKit doesn’t advertise: you can enable the Creator Network, see which newsletters get recommended to your audience, then reach out to those creators directly for a manual swap or partnership.

    Turn on the network for a month. Watch the analytics. Identify which recommendations your readers actually engage with. Then disable it, email those creators, and negotiate terms you control: co-branded emails, shared lead magnets, or affiliate partnerships.

    You get the signal without the long-term cost. ConvertKit’s algorithm becomes market research, not your growth strategy.

    Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools and tactics that actually move online businesses forward. No fluff, no sponsored takes—just honest operator-to-operator breakdowns.

  • ConvertKit’s broadcast scheduling vs. send-time optimisation

    ConvertKit’s broadcast scheduling vs. send-time optimisation

    ConvertKit gives you two ways to schedule a broadcast: pick a fixed time, or let the platform choose based on each subscriber’s past behavior. The second option—send-time optimisation—sounds smarter. It usually isn’t.

    Most solo operators turn on send-time optimisation assuming it’s a free win. Sometimes it is. More often, it fragments your send window, dilutes your traffic spike, and makes your analytics harder to read. Here’s how to decide which method fits your business model.

    Fixed scheduling: what you’re actually choosing

    When you schedule a broadcast for 9:00 AM Eastern, every subscriber gets it at 9:00 AM Eastern. Simple. Predictable. Your entire list receives the email within a few minutes, your traffic spike is concentrated, and your open rate settles within an hour.

    This matters if you’re driving traffic to a live event, a product launch with a deadline, or a piece of content where early engagement (comments, shares, replies) creates momentum. If fifty people hit your article in the first ten minutes, your server logs show a spike, your social proof builds fast, and your analytics are clean.

    Fixed scheduling also makes troubleshooting easier. If your open rate tanks, you know exactly when the send happened and can cross-reference it with deliverability logs, spam complaints, or external factors (a news event, a holiday, a platform outage).

    Send-time optimisation: what ConvertKit is actually doing

    When you enable send-time optimisation, ConvertKit looks at each subscriber’s past open behavior and schedules delivery for the hour they’re statistically most likely to open. Someone who always opens at 6:00 AM gets it at 6:00 AM. Someone who opens at 11:00 PM gets it at 11:00 PM.

    Your send window stretches across 24 hours. Your traffic arrives in a slow trickle instead of a sharp spike. Your open rate might climb a few percentage points—or it might stay flat, because the algorithm is working with limited data and guessing based on past behavior that may not predict future attention.

    The feature works best if you have a large list (10,000+ subscribers), consistent send history (at least six months), and content that isn’t time-sensitive. A Sunday essay, a weekly roundup, or an evergreen tutorial can arrive anytime and still deliver value. A flash sale, a webinar reminder, or a breaking-news commentary cannot.

    When send-time optimisation backfires

    If you’re running a small list (under 2,000 subscribers), ConvertKit doesn’t have enough data to meaningfully optimise. The algorithm falls back to rough estimates, and you’re spreading your send across 24 hours for no measurable gain.

    If you’re tracking referral traffic in Google Analytics, a 24-hour send window makes attribution messy. Your traffic graph looks flat instead of spiked, and it’s harder to isolate which traffic came from the email versus organic search, social, or other sources.

    If you’re selling something with urgency—early-bird pricing, limited inventory, a countdown timer—send-time optimisation means some subscribers see the offer twelve hours after others. That’s not personalisation. That’s a coordination failure.

    The non-obvious tip: test it by segment, not by broadcast

    Don’t enable send-time optimisation across your entire account. Instead, create two segments: one for engaged subscribers (opened at least three of your last ten emails), one for cold subscribers (opened fewer than three). Send the engaged segment at a fixed time. Send the cold segment with send-time optimisation.

    Your engaged readers already open reliably. They don’t need algorithmic coddling—they need consistency. Your cold subscribers might benefit from a delivery time that aligns with their past (limited) engagement. If send-time optimisation lifts their open rate by even two percentage points, you’ve re-engaged a slice of your list without sacrificing the predictability your core audience expects.

    Run this for a month. Compare open rates, click rates, and unsubscribe rates across both segments. If the cold segment shows improvement, keep it. If the difference is negligible (under three percentage points), revert to fixed scheduling and simplify your workflow.

    ConvertKit’s documentation sells send-time optimisation as a set-it-and-forget-it win. It’s not. It’s a trade-off: you sacrifice timing control and traffic concentration in exchange for a potential (but not guaranteed) uptick in open rate. For most solo operators, fixed scheduling is faster to manage, easier to analyse, and just as effective.

    Want more tactical breakdowns like this? Subscribe to One Two Three Send and get one operator-focused deep dive every day.

  • Klaviyo’s conditional split: when to branch flows and when to stay linear

    Klaviyo’s conditional split: when to branch flows and when to stay linear

    Klaviyo’s conditional split is the feature that separates operators who automate thoughtfully from those who automate chaotically. It lets you fork an email flow into multiple paths based on subscriber behavior, profile data, or event properties. Someone clicked your product link? Send them a discount. They didn’t? Wait three days and try a different angle.

    The promise is elegant: personalized sequences that adapt in real time. The risk is building flows so complex you can’t debug them when something breaks—or worse, when nothing breaks but revenue stays flat because you optimized for cleverness instead of outcomes.

    Here’s how the feature actually works, when it makes you money, and when it just makes your flow chart look impressive.

    How conditional splits work in Klaviyo

    A conditional split evaluates one or more conditions at the moment a subscriber reaches that point in the flow. You define the logic: Has opened an email in this flow, Has clicked a specific link, Profile property equals X, Has placed an order since entering this flow, and dozens more.

    Klaviyo checks the condition, then routes the subscriber down the Yes path or the No path. Each branch can contain more emails, delays, and additional splits. You can nest splits inside splits, though your future self will hate you for it.

    The split happens once, at evaluation time. If someone clicks a link five minutes after they pass the split, they don’t jump branches retroactively. Timing matters.

    Klaviyo evaluates splits server-side, so there’s no delay or tracking pixel required—it’s reading from your account data in real time. That’s why splits based on opens are less reliable than splits based on clicks or purchases. Opens depend on image loading and Apple’s Mail Privacy Protection has made that signal noisier every year.

    When a split improves outcomes

    Conditional splits pay off when the two branches lead to meaningfully different next actions—and when you have enough volume to make both paths worth maintaining.

    Post-purchase flows. Split based on product category or price tier. Someone who bought a $20 ebook gets content-focused emails. Someone who bought a $2,000 course gets onboarding check-ins and a Slack invite. The optimal next email is genuinely different.

    Abandoned cart recovery. Split after the first reminder based on whether they’ve returned to the site. If they came back but didn’t buy, you know they’re warm—send a discount or a FAQ. If they haven’t returned, try social proof or a different product angle.

    Lead magnet sequences. Split based on link clicks to gauge interest. Someone who clicked your case study link three times is ready for a sales email. Someone who hasn’t clicked anything gets more educational content before you ask for the sale.

    The pattern: you’re splitting when behavior signals a different level of intent, and each path has a distinct strategic goal.

    When a split just adds complexity

    Splits fail when you’re branching for the sake of branching—or when the two paths aren’t different enough to justify the overhead.

    Splitting on opens. Open rates are unreliable signals now. Apple MPP pre-loads images for many users, so an “open” might mean they read every word or it might mean their phone cached the email while they slept. Clicks and purchases are real actions. Opens are proxy data. If you’re splitting on opens, you’re optimizing for noise.

    Too many paths too early. A five-way split after the welcome email means you’re maintaining five parallel sequences. Unless each path has a clear conversion goal and you’re sending enough volume to measure performance in each branch, you’re fracturing your learning. Simpler flows ship faster and break less.

    Splitting when a tag would work. If the goal is just to segment people for future campaigns, add a tag and keep the flow linear. Splits are for in-flow decisions. Tags are for long-term segmentation. Mixing the two leads to flows that are half automation, half CRM, and fully unreadable six months later.

    One non-obvious tip: test the No path first

    Most operators build the Yes path—the engaged, high-intent path—first, because it’s more exciting. That’s backward.

    The No path is where most of your subscribers will go, especially early in a flow when intent is uncertain. If your No path is a dead end or a lazy fallback, you’re leaving money on the table at scale.

    Build the No path as if it’s the default experience, because it is. Make it a real sequence with real value. Then build the Yes path as the exception for people who signal higher intent. Your flow will convert better and you’ll spend less time wondering why 80% of your subscribers are getting the “backup” experience.

    If you’re running email flows that do more than broadcast, Klaviyo’s conditional split is eventually unavoidable. Just make sure every branch you add is solving a real problem—not just making your flowchart look like a decision tree from a textbook.

    What’s the most complex flow you’ve built—and did it actually outperform the simple version? Reply and let us know. We’re collecting operator stories for an upcoming piece on when automation goes too far.

  • Why subscriber count is the worst metric to optimise for

    Why subscriber count is the worst metric to optimise for

    Every newsletter operator watches the same number: total subscribers. It ticks up after a good Twitter thread, jumps when someone shares your work, and becomes the first thing you check each morning. The number feels like progress. It looks like traction. And optimising for it will quietly ruin your business.

    Subscriber count is a vanity metric dressed up as a business metric. It measures accumulation, not value. It rewards growth tactics that attract the wrong people, encourages content that pleases algorithms instead of readers, and creates a list full of people who will never pay you, never share your work, and never open another email.

    The operators building sustainable businesses have stopped chasing total subscribers. They’ve switched to metrics that actually predict revenue, retention, and referrals. Here’s why subscriber count fails—and what to track instead.

    Subscriber count rewards the wrong acquisition channels

    When your goal is adding subscribers, every tactic that grows the list looks smart. Viral Twitter threads that attract drive-by signups. Lead magnets designed to game SEO traffic. Free course giveaways that pull in freebie-seekers. Pop-ups with no context about what you actually send.

    These tactics work—if “work” means inflating a number. But the subscribers they attract have no relationship with you, no investment in your topic, and no intention of sticking around. Your 30-day open rate tells the real story: half of them are already gone.

    Compare that to subscribers who find you through a piece of cornerstone content, a trusted referral, or consistent presence in a niche community. They arrive slower. They don’t create the dopamine hit of a 300-signup day. But they open, they click, they reply, and they buy.

    Optimising for total subscribers makes you prioritise channels that scale fast over channels that convert well. You end up with a list that looks impressive in a Twitter bio and performs like a ghost town in your analytics.

    It hides the metric that actually matters: engaged subscriber density

    The number that predicts your revenue isn’t how many people are on your list. It’s how many people on your list actually care.

    If you have 10,000 subscribers and 1,200 of them open regularly, your engaged base is 12%. If you have 1,500 subscribers and 900 of them open regularly, your engaged base is 60%. The second list will out-earn the first every time—through sponsorships, course sales, affiliate clicks, or paid subscriptions.

    Sponsors don’t pay for total subscribers. They pay for opens, clicks, and conversions. A 5,000-person list with a 45% open rate is worth more than a 25,000-person list with an 18% open rate. The second list costs you more to send, tanks your deliverability, and dilutes every message you write.

    Engaged subscriber density is the metric that matters. It’s the percentage of your list that still wants to hear from you. And the fastest way to destroy it is to optimise for total growth without caring who shows up.

    It makes you write for strangers instead of your actual audience

    When subscriber count is your goal, you start writing for the people who might subscribe, not the people who already did. Your content shifts toward broad, safe, SEO-friendly topics that attract clicks but don’t build trust. You avoid sharp opinions because they might alienate potential subscribers. You write introductions for people who will never make it past the first paragraph.

    Your actual subscribers—the ones who opened your last six emails—notice. The work feels less specific, less useful, less like it was written for them. They start skimming. Then skipping. Then unsubscribing, but only after months of quietly disengaging.

    The operators with the highest retention rates write like their list is a tight community, not a leaky funnel. They assume familiarity. They reference past emails. They use insider shorthand. New subscribers either catch up or leave—and that’s fine, because the people who stay are worth ten times more than the people who bounce.

    What to track instead

    If subscriber count is out, what’s in? Three metrics that actually correlate with a sustainable business:

    30-day engaged subscribers. How many people opened or clicked in the last 30 days. This is your real audience. Everyone else is payload.

    Subscriber lifetime value (LTV). Average revenue per subscriber over their entire time on your list. A small list with high LTV beats a large list with low LTV every time.

    Referral rate. What percentage of new subscribers came from existing subscribers sharing your work or forwarding an email. High referral rate means you’re attracting people who actually fit. Low referral rate means you’re dependent on cold acquisition that never warms up.

    These three metrics tell you if you’re building a business or just inflating a number. They don’t feel as satisfying to share in a launch tweet. They don’t give you the sugar rush of a big signup day. But they’re the difference between a list that makes $200/month and a list that makes $20,000/month at the same size.

    Stop checking total subscribers. Start checking who’s still listening.

    What’s one metric you’ve stopped tracking because it didn’t actually move your business forward? Hit reply and let me know—I’ll feature the best answers in a future issue.

  • The host that fixed our site at 11pm on a Sunday

    The host that fixed our site at 11pm on a Sunday

    TL;DR. BigScoots is a managed-WordPress host with the kind of proactive support most hosts only put in their marketing copy. We use them on every site we run.

    What is BigScoots?

    BigScoots is a US-based managed WordPress and managed VPS host. They’ve been around since 2010 — old enough to know what they’re doing, small enough that the support team actually knows your site by name.

    The pitch is simple: hosting that’s genuinely fast, with a 24/7 team that fixes problems you didn’t even know you had.

    What makes them different from every other “managed WordPress” host?

    Most managed hosts compete on a feature checklist — sites, storage, CDN, staging, backups. BigScoots checks those boxes too, but the real differentiator is proactive support. They watch your site, push performance fixes you didn’t ask for, and respond to problems before you notice them.

    Real things they’ve done for us without being asked:

    • Pushed a server-side caching tweak that took a slow page from 1.6 s to 280 ms.
    • Migrated a site from another host overnight, end-to-end on their side, zero downtime.
    • Fixed a broken plugin update at 11 pm on a Sunday — within 12 minutes of the alert firing.

    Why we recommend it for newsletter operators

    If you’re sending a newsletter from WordPress, every minute the site is down is a minute your subscribers see a broken signup form, a dead referral link, or an empty archive. The cost of bad hosting isn’t the $10 you save — it’s lost trust with the audience you spent years building.

    BigScoots is more expensive than budget hosts. It’s worth it.

    Bottom line

    If you’re new to WordPress and wondering where to host your first newsletter site, BigScoots is the easy answer. If you’re tired of fighting with cheap hosting that breaks every other week, it’s the upgrade. One of those decisions you make once and never have to revisit.

    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.

  • Notion’s AI autofill: when to use it and when it ruins your data

    Notion’s AI autofill: when to use it and when it ruins your data

    Notion added AI autofill to databases in late 2023, and it’s one of those features that looks brilliant in a demo but quietly wrecks your workflow if you don’t understand what it’s actually doing.

    The pitch is simple: Notion watches how you fill in database properties, then offers to complete the rest for you using pattern recognition and its AI model. It’s meant to save time on repetitive data entry—content calendars, client trackers, product roadmaps, that sort of thing.

    But autofill doesn’t just speed things up. It also makes assumptions. And when those assumptions are wrong, you end up with corrupted records that take longer to fix than if you’d entered everything manually.

    How autofill actually works

    Notion’s autofill pulls from three sources: the structure of your database, the content already in other rows, and its underlying language model’s general knowledge.

    If you’re filling in a content calendar and you’ve already logged five blog posts with categories like “SEO,” “monetisation,” and “hosting,” autofill will suggest categories for new rows based on the title or notes you’ve entered. If you type “How to optimise WordPress caching” into a new row, it’ll probably suggest “hosting” as the category.

    That’s useful when your database is consistent and your naming conventions are tight. It falls apart when your data is messy, when you use the same words to mean different things, or when you’re tracking anything that requires context Notion doesn’t have.

    The AI doesn’t understand your business. It understands patterns in text. If your database has irregular naming, overlapping categories, or nuanced distinctions that matter to you but aren’t obvious from the text, autofill will guess wrong more often than it guesses right.

    When to use it

    Autofill works best in databases with:

    • Repetitive, predictable patterns. Client intake forms, meeting notes, content calendars where the categories are stable and the naming is consistent.
    • Low stakes. If a wrong guess costs you five seconds to fix, autofill saves time. If it silently corrupts a financial tracker or product spec, it’s not worth the risk.
    • Text-heavy fields with obvious relationships. If you’re logging blog titles and Notion can reliably infer the category from the title, autofill will probably get it right 80% of the time. That’s a good trade.

    I use it for content idea backlogs where speed matters more than precision. I don’t use it for anything tied to revenue, client work, or product specs.

    When it ruins your data

    Autofill becomes a liability when:

    • Your database has overlapping or evolving categories. If “monetisation” sometimes means sponsorships and sometimes means courses, autofill will pick one arbitrarily and you won’t notice until weeks later.
    • You’re tracking anything with subtle distinctions. Client status (“warm lead” vs. “active conversation”), product stages (“spec’d” vs. “in development”), or anything where the difference matters but isn’t obvious from the row’s title or description.
    • Multiple people use the same database. Autofill learns from everyone’s input. If one person uses loose naming and another is strict, the AI will average out their habits and suggest garbage to both.

    I’ve seen operators lose entire afternoons cleaning up autofill mistakes in client trackers because Notion confidently filled in the wrong pipeline stage for 30 rows and no one noticed until invoices didn’t match expectations.

    How to control it

    You can toggle autofill per database. Open any database, click the ••• menu in the top right, then look for Autofill properties. Turn it off globally or disable it for specific properties.

    If you keep it on, spot-check the first 10–20 rows after Notion starts making suggestions. If it’s getting things wrong more than 20% of the time, turn it off for that property or that database.

    And if you’re working with a team, set a naming convention first. Autofill isn’t a substitute for clean data—it’s a shortcut that only works when your data is already consistent.

    One non-obvious tip: if you’re using autofill in a content calendar, create a separate “AI suggestion” property and let Notion fill that instead of overwriting your canonical category field. You can review suggestions in bulk, accept the good ones, and ignore the rest without risking your source of truth.

    Got a Notion workflow that’s slowing you down? Reply and tell me what you’re tracking—I’ll cover database setups and automation tricks in a future issue.

  • WordPress CDN settings: what actually needs to be cached

    WordPress CDN settings: what actually needs to be cached

    Content delivery networks promise faster page loads and lower server bills. But most WordPress operators flip the switch and trust the defaults—only to find checkout pages breaking, comment forms failing, or member dashboards showing stale data.

    The problem isn’t the CDN. It’s that most presets treat every WordPress site like a static blog. If you run anything interactive—memberships, WooCommerce, course platforms, paywalled content—you need to explicitly tell your CDN what not to cache.

    What should always be cached

    Start with the easy wins. These asset types are static, rarely change, and benefit most from edge caching:

    • Images, CSS, JavaScript — anything in /wp-content/uploads/, /wp-content/themes/, and /wp-content/plugins/ with file extensions like .jpg, .png, .css, .js, .woff2.
    • Publicly visible post and page content — the rendered HTML of non-logged-in pages. Cache for 1–4 hours if you publish frequently, 24 hours if you don’t.
    • RSS and Atom feeds — most readers poll these hourly. Cache for 30–60 minutes.

    Set a Cache-Control: public, max-age=3600 header for these. Most managed WordPress hosts and CDN plugins handle this automatically.

    What should never be cached

    These paths and query strings serve user-specific or time-sensitive data. Caching them breaks functionality or leaks private information:

    • /wp-admin/ and /wp-login.php — the dashboard and login screen. Always bypass.
    • Any URL with a query string containing ?add-to-cart=, ?edd_action=, ?nocache, or session tokens — these trigger actions or personalised views.
    • Checkout, cart, account, and membership pages — if you’re using WooCommerce, Easy Digital Downloads, MemberPress, or similar, create explicit CDN rules to bypass these slugs.
    • Comment forms and AJAX endpoints/wp-comments-post.php and /wp-admin/admin-ajax.php must be dynamic.
    • Any page that reads cookies for logged-in state — if a page checks wordpress_logged_in_* cookies to show different content, don’t cache it.

    Most CDNs let you define cache bypass rules by URL path, query string, or cookie name. Use all three.

    The logged-in user problem

    WordPress sets a wordpress_logged_in_* cookie when someone signs in. If your CDN caches pages that check this cookie, logged-in users see cached, logged-out content—or worse, other users’ dashboards.

    The fix: configure your CDN to bypass cache entirely when any wordpress_logged_in_ cookie is present. Most managed hosts (Kinsta, WP Engine, Flywheel) do this by default. If you’re on a VPS or using Cloudflare, you’ll need to add this rule manually.

    If you run a membership site or paywalled newsletter archive, test this before launch. Log in, visit a member-only page, then open an incognito window and visit the same URL. If you see the same content, your CDN is leaking.

    The one setting that fixes most problems

    Most CDN misconfigurations come down to query strings. By default, many CDNs treat example.com/page and example.com/page?utm_source=twitter as different URLs—and cache both separately.

    This fragments your cache, wastes memory, and reduces hit rates. The fix: strip query strings before caching, unless the query string affects content (like ?p=123 or ?s=search).

    In Cloudflare, this is called “Query String Sort.” In Fastly, it’s “query string handling.” In WP Rocket or W3 Total Cache, it’s “ignore query strings.”

    Whitelist the query strings that do matter—typically p, page_id, s, and preview_id—and strip everything else.

    Testing your config

    After you set cache rules, test three scenarios:

    • Logged-out visitor — Pages should load from cache. Check response headers for X-Cache: HIT or CF-Cache-Status: HIT.
    • Logged-in user — Pages should not cache. Look for X-Cache: BYPASS or CF-Cache-Status: DYNAMIC.
    • Checkout or form submission — These must always be dynamic. If they cache, payments and signups will fail.

    Use your browser’s network inspector or a tool like WebPageTest to inspect headers. If you see HIT on a logged-in page, tighten your cookie rules.

    Most CDN problems aren’t speed problems—they’re config problems. Get these rules right once, and your site will be both faster and more reliable.

    Want more infrastructure deep-dives like this? Subscribe to One Two Three Send and get one operator-focused article every day—no fluff, no filler.

  • Stripe’s tax automation: how it works and when to turn it on

    Stripe’s tax automation: how it works and when to turn it on

    If you’re selling digital products, courses, or memberships, you’ve probably stared at Stripe’s Tax settings and wondered whether clicking “enable” would solve your compliance headaches or create new ones.

    Stripe Tax is a feature that calculates, collects, and (optionally) files sales tax, VAT, and GST on your transactions. It’s built into Stripe, so there’s no separate integration to maintain. But it’s not free, and it’s not always the right move.

    Here’s how it actually works, what it costs, and when you should turn it on—or leave it off.

    What Stripe Tax actually does

    Stripe Tax hooks into your payment flow and calculates the correct tax rate based on your customer’s location and what you’re selling. It supports over 40 countries and automatically updates rates when local laws change.

    When a customer checks out, Stripe adds the appropriate tax to the transaction total. That tax gets collected alongside the payment, and Stripe holds it separately from your payout balance.

    If you enable the filing service (called Stripe Tax Registration and Filing), Stripe will register your business in the jurisdictions where you hit economic nexus thresholds, file returns on your behalf, and remit the tax directly to the tax authorities.

    It covers VAT in the EU, UK, and other countries, GST in Australia, Canada, New Zealand, and Singapore, plus sales tax across U.S. states. It does not cover income tax, withholding tax, or import duties.

    Pricing: the cost structure you need to know

    Stripe Tax costs 0.5% of the transaction amount, capped at $5.00 per transaction. So on a $50 product sale, you pay 25 cents. On a $2,000 annual membership, you pay $5.00.

    That fee is charged on top of Stripe’s standard payment processing fees (typically 2.9% + 30¢ for card transactions).

    If you opt into the registration and filing service, Stripe charges an additional monthly fee per jurisdiction where they file on your behalf. In the U.S., that’s $50 per state per month. For VAT in the EU, it’s typically bundled under a single OSS (One-Stop Shop) registration, which costs around $100–$200/month depending on your setup.

    For a solo operator selling a $29/month membership in five U.S. states, you’re looking at $250/month in filing fees alone—before accounting for the 0.5% per-transaction charge.

    When to turn it on

    Stripe Tax makes sense in three scenarios.

    First: You’ve crossed economic nexus thresholds in multiple jurisdictions and you’re already required to collect and remit tax. If you’re manually tracking rates and filing returns, the 0.5% fee is likely cheaper than paying an accountant to do it—especially if your transaction volume is high and your average order value is low.

    Second: You’re selling globally and dealing with VAT in the EU or UK. The rates vary by country, change frequently, and the compliance burden is real. Stripe Tax’s automatic rate updates and OSS filing support can save you hours every quarter.

    Third: You’re scaling fast and don’t want tax compliance to become a bottleneck. If you’re adding new products, entering new markets, or growing past $100K in annual revenue, turning on Stripe Tax early means one less thing to audit later.

    When to skip it (or wait)

    If you’re just starting out and your revenue is under $50K/year, you probably don’t need it yet. Most U.S. states have economic nexus thresholds around $100K in sales or 200 transactions per year. Until you hit those numbers, you’re not required to collect tax in those states.

    If you’re only selling in your home state or a single jurisdiction, the 0.5% fee is a convenience charge for something you could handle with a spreadsheet and a quarterly check to your state revenue department.

    And if your average transaction value is very high—say, $5,000+ for a consulting package or enterprise license—the capped $5 fee per transaction adds up quickly. You might be better off working with a tax professional who charges a flat monthly retainer.

    One non-obvious tip: test it in test mode first

    Stripe Tax has a full-featured test mode. Before you enable it in production, create a test checkout with your actual product prices and simulate transactions from different locations—California, Texas, Germany, Australia.

    Check the tax amounts Stripe calculates. Compare them against your state or country’s published rates. Make sure the line items on the receipt match what your customers will expect to see.

    This is especially important if you’re using Stripe Checkout or Payment Links, where the tax line appears automatically. If your pricing page says “$99” but checkout shows “$108.17,” and your customer wasn’t expecting that, you’ll lose the sale. Better to know now and adjust your messaging.

    If you’re running a content-driven business and want more deep dives like this—on tools, infrastructure, and the mechanics of online revenue—subscribe to One Two Three Send. Every week, you’ll get one operator-to-operator breakdown of something that actually moves the needle.