One Two Three Send

Author: onetwothreeadmin

  • ConvertKit vs. MailerLite: which platform handles large lists better

    ConvertKit and MailerLite both market to solo operators and small teams, but they handle scale differently. If you’re choosing between them—or wondering when to migrate—the differences matter most once you cross 10,000 subscribers and again at 50,000.

    This isn’t about features in general. It’s about what changes when your list grows, where each platform’s architecture shows stress, and what you pay for the privilege.

    Pricing structure and list-size thresholds

    ConvertKit charges based on total subscribers across all lists and segments. As of November 2026, the Creator tier starts at $29/month for up to 1,000 subscribers, then moves to $49/month at 3,000, $79/month at 9,000, and $108/month at 15,000. Past 50,000 subscribers, you’re into custom pricing (ConvertKit pricing, checked November 2026).

    MailerLite uses the same subscriber-count model but undercuts ConvertKit significantly. The Growing Business plan runs $18/month for up to 1,000 subscribers, $36/month at 5,000, $60/month at 10,000, and $180/month at 50,000. Past 100,000, you request a quote (MailerLite pricing, checked November 2026).

    Both platforms count all subscribers once, even if they appear in multiple segments. Unsubscribes and deleted contacts drop off the count within 24 hours on MailerLite and immediately on ConvertKit.

    Segmentation speed and filter complexity

    ConvertKit’s visual automation builder and tagging system handle complex logic well, but segment recalculation slows as list size grows. If you build a segment using multiple date-based conditions and tag intersections, expect refresh times between two and ten minutes on lists above 25,000 subscribers. Segments update in near-real-time for smaller lists.

    MailerLite’s segmentation engine is faster at scale but less flexible. You can stack conditions—opened campaign X, clicked link Y, signed up before date Z—but advanced operators hit the 15-condition limit quickly. Recalculation on large segments takes under a minute in most cases, even above 50,000 subscribers, because MailerLite pre-indexes common filters like campaign engagement and signup date.

    One non-obvious difference: ConvertKit lets you nest sequences inside automations and trigger them from segment membership. MailerLite requires you to export the segment and manually upload it to a workflow, which adds friction if you’re running multi-step nurture campaigns based on behaviour.

    Delivery speed and send throttling

    Neither platform publicly documents per-account send rates, but operator experience shows the gap. ConvertKit typically delivers a broadcast to 50,000 subscribers within 20 to 40 minutes. MailerLite completes the same send in 10 to 20 minutes, because it queues campaigns differently and spreads load across more outbound IP pools.

    Both platforms throttle new accounts. If you migrate a large list and immediately send a broadcast, expect your first few campaigns to trickle out over 60 to 90 minutes regardless of platform. Throttling lifts after a few sends with normal engagement metrics.

    ConvertKit offers domain authentication (custom DKIM and return-path) on all paid plans. MailerLite includes it only on the Growing Business tier and above, so free and low-tier accounts share domain reputation with other users—a risk if you care about inbox placement.

    Who each platform suits

    ConvertKit makes sense if you sell digital products directly from email, need advanced automation branching, or rely heavily on creator-focused integrations (it connects natively to more course platforms and membership tools). The higher cost buys you flexibility in workflow design and better support documentation for complex sequences.

    MailerLite fits operators who prioritise cost over automation depth, send frequently to large lists, or run straightforward nurture sequences without heavy conditional logic. The interface is faster, the price scales better, and delivery speed matters if you’re running time-sensitive campaigns or coordinating sends with other channels.

    Neither platform handles true transactional email well—order confirmations, password resets, account alerts. For that, you still need a dedicated service like Postmark or a developer-focused API.

    Migration and export limits

    Both platforms let you export your full subscriber list as CSV at any time, with no gating or delay. ConvertKit includes custom field data and tag history in the export. MailerLite includes custom fields but not granular activity logs, so if you track detailed behaviour over time, export your campaign reports separately before migrating out.

    Importing into either platform is straightforward for lists under 10,000 subscribers. Above that, both require you to confirm list provenance and may ask for proof of consent if engagement looks low. Plan for a 24- to 48-hour review window on your first large import.

    If you’re already on one platform and considering a switch, test segmentation and automation performance with a 5,000-subscriber sample before committing. The workflow paradigms differ enough that rebuilding sequences takes longer than migrating the list itself.

    One Two Three Send covers email tooling, AI workflows, and hosting infrastructure for solo operators. Subscribe here to get one article daily.

    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 prompt libraries: where to store them and when they rot

    AI prompt libraries: where to store them and when they rot

    AI prompt libraries: where to store them and when they rot
    Photo: Ginny from USA via Wikimedia Commons (CC BY-SA 2.0)

    If you run prompts more than twice, you save them. The question is where—and whether you’ll ever find them again when the model changes or the use case drifts.

    Most solo operators start with a Google Doc, graduate to Notion, then scatter prompts across Slack saved messages, browser bookmarks, and a folder called “AI stuff.” Six months later, half the saved prompts fail because the model was updated, the output format changed, or the original context is gone.

    Here’s how to store prompts so they stay useful, and when to retire them before they waste your time.

    Pick one storage method and enforce it

    The best prompt library is the one you’ll actually use. That means low friction and a single source of truth.

    Plain text files in a dedicated folder work for operators comfortable with file browsers. Name each file by use case: email-subject-lines.txt, blog-intro-rewrite.txt. Keep a README with the model name, temperature, and date last tested. Version control with Git if you’re already using it for code; otherwise a Dropbox or Google Drive folder with file history is enough.

    Notion databases let you tag by model, category, and status (active / deprecated / testing). Add a “last verified” date column and filter by it. The search is fast, and you can duplicate a row to test a variation without losing the original.

    Dedicated prompt managers like PromptBase or custom Airtable bases add structure but introduce another tool. Worth it if you’re running dozens of prompts daily; overkill if you have twelve evergreen templates.

    Whatever you pick, the rule is the same: if a prompt isn’t in the library, it doesn’t exist. No exceptions for “just this once” saves in Slack or a scratch pad.

    Tag by model, temperature, and expected output

    A prompt without context is a time bomb. When Claude or GPT-4 updates, your saved prompt might return different lengths, tones, or formats—and you won’t know why until you’ve wasted twenty minutes troubleshooting.

    Store three pieces of metadata with every prompt:

    • Model and version. “Claude Sonnet, October 2026″ or “GPT-4o, November 2026.” If the provider doesn’t version publicly, note the date you saved it.
    • Temperature or sampling setting. A prompt tuned for temperature 0.2 will feel robotic at 0.9. If you’re copy-pasting into a web UI that resets settings, note what worked.
    • Expected output type. “Returns 5 subject lines, ~50 chars each” or “Generates 300-word intro, casual tone.” When output drifts, you’ll know whether the prompt or the model changed.

    Add a “last verified” date and update it every few months. If a prompt hasn’t been tested in six months and the model has updated twice, assume it’s stale.

    When to retire a prompt

    Prompts don’t age well. Models improve, your use case shifts, or you realise the original prompt was solving the wrong problem.

    Retire when the model changes and the output degrades. If a prompt that returned crisp 50-character subject lines now produces 80-character SEO keyword soup, don’t try to fix it with band-aid instructions (“keep it short”). Rewrite from scratch with the new model’s behaviour in mind, or switch models.

    Retire when you stop using it for three months. If a prompt was valuable, you’d be running it. If you haven’t touched it since February, delete it or move it to an archive folder. Clutter kills discoverability.

    Retire when the use case disappears. Prompts tuned for Twitter’s 280-character limit don’t help if you’ve moved to Threads or given up on social entirely. Don’t hoard prompts for workflows you abandoned.

    Mark retired prompts clearly—add “DEPRECATED” to the filename or move them to a separate folder. If you need the logic later, you’ll know where to look, but it won’t pollute your active list.

    Test and version instead of tweaking in place

    When a prompt stops working, the instinct is to edit it and save over the original. Don’t. You’ll lose the baseline and won’t know if the new version is better or just different.

    Duplicate the prompt, rename it with a version suffix (email-subject-v2), and test side by side. Run both on the same input and compare output quality, speed, and cost (if you’re calling via API and tracking tokens).

    If the new version wins, mark the old one deprecated. If it doesn’t, keep the original active and note what you tried in a changelog or comment field. Two months from now, you’ll save yourself from testing the same failed variation twice.

    Prompts are infrastructure, not inspiration. Treat them like code: version them, test them, and delete them when they’re dead weight. The goal isn’t to collect prompts—it’s to run the ones that work without thinking twice.

    Reply with how you store yours—or where they go to die. We’re collecting operator setups for a follow-up piece.

    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 media library pagination: where large libraries slow down

    WordPress media library pagination: where large libraries slow down

    WordPress media library pagination: where large libraries slow down
    Photo by Pankaj Patel on Unsplash

    If you’ve been uploading images, PDFs, and video thumbnails to WordPress for more than a year, you’ve probably noticed the media library start to drag. The grid takes longer to load. Scrolling feels janky. Search stops returning results fast enough to be useful.

    The problem isn’t your hosting—it’s how WordPress handles pagination when your media library grows past a few thousand files.

    How WordPress loads the media library

    When you open the media library, WordPress runs a database query to fetch attachments. By default, it returns 40 items per page in grid view, or as many as your screen size allows in list view. Each page load triggers a new query with an OFFSET clause that tells the database how many rows to skip before returning results.

    For the first few pages, this works fine. But as your library grows—say, past 3,000 to 5,000 files—every query has to scan and skip thousands of rows before it can return the 40 you actually want to see. The database does more work, and load times climb.

    WordPress core doesn’t index attachment queries by upload date or file type in a way that speeds up deep pagination. According to the WordPress Query class reference (checked November 2026), the WP_Query object used for media relies on the same posts table structure as everything else, and large offsets are expensive regardless of table size.

    When it breaks

    You’ll notice the slowdown around these thresholds:

    • 3,000–5,000 files: Grid view starts to lag when you scroll past page 10.
    • 10,000+ files: Searches take multiple seconds. Filtering by date or media type doesn’t help much because the query still scans the full table.
    • 25,000+ files: The media library becomes nearly unusable in the WordPress admin. Some hosting environments will time out before returning results.

    The exact breaking point depends on your database server, PHP memory limit, and whether your host uses object caching. But the pattern holds: offset-based pagination doesn’t scale.

    What to do about it

    Use a media library plugin that indexes differently. Tools like Media Library Assistant (checked November 2026) let you filter and sort by custom taxonomies, which can bypass some of the worst query patterns. Others, like Enhanced Media Library (checked November 2026), add categories and MIME-type filters that rely on indexed joins instead of table scans.

    Offload storage and serve files from a CDN or object storage service. This doesn’t fix pagination, but it does reduce the number of database rows WordPress has to manage. Plugins like WP Offload Media (checked November 2026) move your files to S3 or compatible services and leave only metadata in the WordPress database. Fewer rows means faster queries, even with large offsets.

    Archive old media. If you have thousands of images from posts you published years ago, export them, back them up, and delete the attachments from WordPress. You can re-upload individual files if you ever need to update an old post. This is manual work, but it’s the fastest way to shrink your media library if you don’t need random access to every file you’ve ever uploaded.

    Increase your per-page limit (carefully). Loading 100 or 200 items per page reduces the number of deep-offset queries you’ll trigger, but it also increases memory usage and can make the initial page load slower. Test this on a staging site before you push it to production. You can adjust the number in Screen Options at the top of the media library page.

    One non-obvious tip

    If you’re building a content site that publishes daily and embeds multiple images per post, budget for media-library maintenance from the start. Set a yearly reminder to audit and archive files, or commit to offloading storage before you hit 5,000 attachments. Fixing a slow media library after the fact is harder than preventing the problem in the first place.

    Most solo operators don’t think about database query performance until it’s already a problem. Treat your media library like you treat your email list: clean it regularly, and don’t let it bloat.

    Hit reply if you’ve found a better way to handle large WordPress media libraries—we’ll share the best answers in a future issue.

  • Social media platforms throttle API calls—here’s where you hit the wall

    Social media platforms throttle API calls—here’s where you hit the wall

    Social media platforms throttle API calls—here's where you hit the wall
    Photo by dole777 on Unsplash

    If you schedule posts, pull engagement data, or auto-share new articles to Twitter, LinkedIn, Facebook, or Instagram, you’re using an API behind the scenes—whether you know it or not. Every social media platform sets rate limits: hard ceilings on how many requests your account (or the app acting on your behalf) can make in a rolling window. Hit that limit and your scheduler stops posting, your analytics dashboard goes blank, or your cross-posting workflow silently fails.

    Most solo operators don’t think about API limits until they trip one. This guide explains where the walls are, what happens when you hit them, and how to design your workflow so you don’t.

    What counts as an API call

    Every interaction between an app and a social platform is an API request. Publishing a post is one call. Reading your follower count is another. Fetching the last 50 posts from your timeline might be one or fifty, depending on how the endpoint works. If you use a scheduling tool like Publer, Buffer, or Hootsuite, each action the tool takes on your behalf—posting, editing, deleting, reading replies—burns a request from your quota.

    The quota resets on a schedule: per minute, per hour, per day, or per app. Some platforms count per user; others count per application. If you connect three tools to the same Twitter account, all three may share the same pool of allowed requests.

    Where the major platforms set the ceiling

    Twitter’s (X’s) API tiers changed significantly in early 2023 and again in 2024; as of November 2026, the free tier no longer exists for third-party apps, and the Basic tier (around $100/month, checked November 2026) allows 10,000 posts per month and 1,000 read requests per month. If you schedule more than ~300 posts per month or pull analytics daily, you’ll exceed the read cap. The Pro tier raises both limits but costs several hundred dollars monthly.

    LinkedIn’s API documentation (checked November 2026) imposes different limits by endpoint. User-generated content (posts) is capped at 150 write requests per person per day for organic shares, and 25 per day for certain image or video operations. If you post once an hour around the clock, you’re under the wire—but if your scheduler retries failed uploads or you’re using multiple tools, you can hit the wall.

    Meta platforms (Facebook and Instagram) use a two-tier system: per-user and per-app. Facebook’s Graph API (checked November 2026) applies a rate limit of 200 calls per user per hour for most endpoints, but also enforces an app-level budget that scales with your app’s usage tier. Instagram’s API shares similar constraints. If you run a scheduling tool that serves multiple clients from one app ID, the app-level limit matters more than your personal ceiling.

    TikTok and Pinterest also enforce API quotas, but most solo operators use web-based schedulers rather than direct API access, so these limits typically affect the tool vendor, not you—until the vendor’s quota runs out and posts stop going through.

    What happens when you hit the limit

    Most platforms return an HTTP 429 status code (“Too Many Requests”) and a header indicating when the quota resets. Well-designed tools queue your request and retry after the window rolls over. Poorly designed tools log an error, show a generic failure message, or silently drop the task. You won’t know your post didn’t publish unless you check manually.

    Some platforms temporarily block your app or account if you exceed limits repeatedly. Twitter has historically suspended API access for 15 minutes to several hours after sustained violations. LinkedIn and Meta may throttle your requests progressively: your first dozen succeed, then every other one fails, then only one in ten goes through.

    How to stay under the ceiling

    Batch your API calls instead of making real-time requests every few minutes. If you pull analytics, fetch data once per day and cache it locally rather than querying on every page load. If you cross-post from RSS, deduplicate before sending so you don’t publish the same article twice and burn two quota slots.

    Use tools that respect rate limits and surface quota information. Publer, for example, queues posts and spaces them out to avoid bursts. Buffer provides visibility into when posts are scheduled and warns you if you’re approaching platform limits. If you’re building custom workflows with Zapier or Make, add delays between steps and check the task history for 429 errors.

    If you routinely hit limits, consider whether you need real-time data or can work with a delay. Most solo operators don’t need follower counts updated every hour. A nightly sync is enough. That single shift can cut your monthly API usage by 90 percent.

    Finally, if you manage multiple brands or clients, isolate each account’s automation. Don’t chain five Instagram profiles to the same Zapier app; Meta’s app-level limit will choke all five when any one gets busy. Use separate API keys or separate tool accounts where possible.

    When to pay for higher limits

    If your workflow depends on frequent publishing—hourly social posts, real-time comment monitoring, or live dashboard updates—and you’re brushing the free-tier ceiling every week, upgrading to a paid API tier or a higher scheduler plan is cheaper than the opportunity cost of silent failures. Twitter’s Basic tier may feel expensive at $100/month, but if a missed post costs you affiliate clicks or sponsorship deliverables, the insurance is worth it.

    Check your tool’s API usage dashboard (if it has one) or request logs every month. If you’re consistently under 50 percent of any limit, you have headroom. If you’re above 80 percent, you’re one workflow change away from breaking.

    Want more infrastructure deep-dives like this? Subscribe to One Two Three Send and we’ll send you one operator-to-operator breakdown every morning.

    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.

  • Newsletter header links: what readers click and how many is too many

    Newsletter header links: what readers click and how many is too many

    Newsletter header links: what readers click and how many is too many
    Photo by Markus Winkler on Unsplash

    Open any newsletter and you’ll see a row of links at the top: About, Archives, Unsubscribe, Sponsor, maybe a social icon or two. Most operators add them once during template setup and never look back. But header link behavior is different from in-body links—and the structure you pick changes what readers do next.

    Where header links sit and what they do

    Newsletter headers typically live in one of three places: above the logo, between the logo and the first headline, or in a thin utility bar at the very top. Email clients render them as live links in HTML emails; plain-text newsletters sometimes repeat them as a footer block instead.

    The most common links are:

    • View in browser — lets readers escape rendering problems or forward the issue
    • Archives — index of past issues, often the second-highest traffic driver after the homepage
    • Unsubscribe — required under CAN-SPAM (checked October 2026, FTC CAN-SPAM guidance), though most platforms auto-inject it in the footer
    • Sponsor / Advertise — pitch page for potential advertisers
    • About / Start here — intro page for new readers

    Beehiiv and MailerLite both offer drag-and-drop header editors that let you reorder or hide these without touching code. Substack bakes the structure in and gives you less control.

    Click behavior: headers vs. body links

    Header links get fewer clicks than body links, but the people who do click them behave differently. A reader who clicks “Archives” is often hunting for a specific past issue or trying to decide whether to subscribe. A reader who clicks “About” in the header is usually new—either forwarded the email or landed via search.

    Body links, by contrast, get clicked by engaged readers already moving through your content. Click-through rates on body links typically run 2–5× higher than header links, but header links drive longer session durations once someone lands. That makes header links better for onboarding and navigation, worse for immediate conversion.

    One pattern worth noting: “View in browser” links see a spike when an email renders poorly—Gmail image blocking, dark mode color inversions, or Outlook layout breaks. If your “view in browser” clicks jump above 8–10% of opens, check your template rendering across clients.

    How many links to include

    There’s no hard limit, but usability degrades past six or seven links. Mobile email clients compress headers aggressively, and a row of eight tiny links turns into a visual mess. Readers also suffer decision fatigue: too many options and they pick none.

    A conservative header might carry three links: Archives, About, and Sponsor. A maximalist header might include those plus social icons, a Shop link, a podcast feed, and a secondary CTA. The right count depends on how many distinct actions you want to offer and how much you trust readers to self-navigate.

    If you’re running a content-driven business with multiple revenue streams—newsletter sponsorships, a course, affiliate guides, and a membership tier—you’ll need more links than someone running a simple personal essay newsletter. But even then, consider grouping: a single “Work with me” link that leads to a hub page beats three separate CTAs fighting for attention.

    Placement and priority

    Left-to-right reading means the first link in your header gets the most attention. If you’re optimizing for subscriber retention, put Archives first. If you’re optimizing for revenue, lead with Sponsor or Shop. If you’re optimizing for growth, lead with a referral CTA or a “Forward to a friend” link.

    Some operators run a utility bar above the main header with low-priority links—Unsubscribe, Update preferences, View in browser—and reserve the main header row for high-value actions. That separation works well if your template has the vertical space, but it adds another visual layer readers have to parse.

    One underused option: dynamic header links. Beehiiv and some custom setups let you show different headers to different segments. New subscribers see “Start here” and “Archives”; long-time readers see “Sponsor” and “Refer a friend.” It’s more complex to maintain, but it aligns the header with where each reader sits in your funnel.

    What to test

    If you want to optimize your header, start by pulling click data from your ESP. Most platforms (MailerLite, Beehiiv, Buttondown) break out link performance by URL. Compare header link clicks to total opens, and compare header CTR to body link CTR.

    Then test removing one link. If you’re carrying seven and nobody clicks “Podcast,” drop it for a month and watch what happens. Fewer choices often means more action on the links that remain.

    Also test reordering. Swap your first and third links for two issues and compare click counts. Small changes in sequence can shift behavior—especially on mobile, where only the first two or three links show above the fold.

    If you’re just setting up your newsletter template and aren’t sure where to start, go minimal: Archives, About, and one revenue link. Add more only when you have a specific reader need that isn’t being met.

    Want more operator tactics like this? Subscribe to One Two Three Send and we’ll send you one article every day—no fluff, no filler, just the tooling and structure that makes online businesses run.

    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.

  • Payment link branding: which processors let you hide their logo

    Payment link branding: which processors let you hide their logo

    Payment link branding: which processors let you hide their logo
    Photo: Donald Trung Quoc Don (Chữ Hán: 徵國單) – Wikimedia Commons – © CC BY-SA 4.0 International.(Want to use this image?)Original publication 📤: –Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:26, 1 March 2023 (UTC) via Wikimedia Commons (CC BY-SA 4.0)

    When you send a customer to a payment page, every logo, badge and footer message shapes whether they trust you or the processor. Some platforms let you strip their branding entirely; others lock it in place unless you’re on enterprise plans that cost more than most solo operators will ever pay.

    Here’s what you control—and what you don’t—on the checkout pages you link to from emails, social posts and landing pages.

    Stripe Checkout and Payment Links

    Stripe offers two hosted options: Checkout (embedded or redirect) and Payment Links (standalone URLs you share directly).

    On both, the Stripe wordmark appears in the footer by default. You can remove it—but only if you’re on a paid Stripe plan (Standard starts at 2.9% + $0.30 per transaction; no monthly fee, checked November 2026). The branding toggle lives under Settings → Branding → Checkout appearance. Once disabled, your checkout shows only your own logo and product details.

    If you stay on the free tier, the “Powered by Stripe” footer stays. It’s small, but it’s there on every page.

    Stripe also shows trust badges (card-network logos, security icons) near the payment form. You can’t remove those individually; they’re part of the checkout template. If you use Stripe’s embedded Checkout (checked November 2026) on your own domain, you control everything above and below the iframe, so the perceived branding shrinks further.

    PayPal Standard Checkout

    PayPal’s hosted checkout—what most solo operators use when they paste a button or link—always shows the PayPal logo in the header and footer. There’s no setting to remove it, even on business or premier accounts.

    If you want a fully white-labeled experience, you need Braintree (PayPal’s separate payments platform, checked November 2026), which requires custom integration and approval. Braintree lets you hide PayPal branding entirely, but it’s not a plug-and-play link you can email—it’s an API you wire into your own checkout flow.

    For most operators sending Payment Links, the PayPal logo is permanent.

    Gumroad

    Gumroad checkout pages show the Gumroad logo in the top-left corner and a “Powered by Gumroad” badge in the footer. You can’t remove either on the free tier (10% transaction fee) or the Gumroad Pro plan ($10/month, checked November 2026).

    There’s no enterprise or white-label option. If you use Gumroad, your buyers see Gumroad branding on every page.

    The trade-off: Gumroad’s checkout converts well because buyers recognise the Gumroad interface. The branding isn’t a bug—it’s a trust signal in niches where Gumroad is ubiquitous (indie SaaS, digital products, courses).

    Lemon Squeezy

    Lemon Squeezy’s hosted checkout always includes a “Secured by Lemon Squeezy” badge in the footer. Like Gumroad, there’s no plan tier or setting that removes it.

    You can customize colours, fonts and your own logo in the checkout appearance settings (checked November 2026), but the Lemon Squeezy name stays.

    If you use Lemon Squeezy’s API (checked November 2026) to build your own checkout on your domain, you control the branding entirely—but you’re also responsible for the UI, validation and payment-form plumbing. Most solo operators don’t go that route.

    When branding matters—and when it doesn’t

    If you’re selling to an audience that already knows you, processor branding matters less. A footer logo won’t kill a $29 ebook sale when the buyer clicked from your newsletter.

    It matters more when:

    • You’re running paid traffic to a cold audience, and trust is thin
    • You’re positioning as a premium service, and a third-party checkout dilutes that
    • You’re embedding checkout in a branded funnel, and visual inconsistency creates friction

    In those cases, the extra cost or integration work to strip branding can be worth it. In most other scenarios—especially early on—it’s noise.

    The non-obvious choice

    If you want checkout pages you fully control without API wiring, and you’re already paying for something, Stripe on a paid plan is the cleanest path. The per-transaction cost is the same as the free tier; you’re just unlocking branding removal and a few other appearance toggles.

    If you’re not paying anything yet and don’t want to start, accept that the processor logo will appear. Focus on the copy, the offer and the load speed instead—those move conversion more than a footer badge does.

    Want more breakdowns like this? Subscribe to One Two Three Send—we explain how online-business tools actually work, with no fluff and no affiliate pressure.

  • Productivity app webhook limits: where triggers stop firing

    Webhooks let one app notify another the instant something happens—a purchase completes, a form submits, a subscriber confirms. They’re the backbone of workflow automation for solo operators. But every platform that receives webhooks imposes rate limits, and when you cross them, triggers fail silently or queue unpredictably.

    Understanding where those limits sit—and how each tool handles overflow—keeps your automations reliable when traffic spikes.

    Where the caps sit

    Zapier allows 100 webhook requests per minute across all your Zaps on the Starter plan, rising to 1,000 per minute on Professional and above (Zapier Help Center, checked November 2026). If you exceed that, new requests return HTTP 429 and won’t create tasks.

    Make (formerly Integromat) enforces a scenario-level limit: each webhook endpoint can receive a maximum of 30 requests per second on the Free tier, 120 per second on Core and Pro plans (Make Help, checked November 2026). Requests beyond the cap are rejected immediately.

    n8n, when self-hosted, inherits the rate limits of your reverse proxy or hosting environment; n8n Cloud enforces per-workflow quotas that scale with your plan tier but does not publish a fixed requests-per-second figure (n8n docs, checked November 2026).

    Pabbly Connect advertises unlimited webhook triggers on paid plans, though the platform queues incoming requests during heavy load and processes them in order—expect delays, not rejections (Pabbly Connect, checked November 2026).

    What happens when you hit the wall

    Most platforms return an HTTP 429 status code when the rate limit is exceeded. The sending service—your payment processor, form builder, or CRM—typically retries a few times with exponential backoff, then gives up. You lose the event.

    Some senders, like Stripe, retry webhook delivery for up to three days with decreasing frequency (Stripe webhook docs, checked November 2026). Others, including many form plugins and smaller SaaS tools, retry once or twice within a few minutes, then drop the payload permanently.

    Zapier queues tasks that arrive within your plan’s task limit but rejects webhook requests that exceed the per-minute cap before a task is created. Make drops overflow requests entirely. Pabbly queues them, but processing lag can stretch from seconds to minutes under sustained load.

    How to design around the cap

    First, check whether your sending app supports batching. Stripe, for example, lets you subscribe to a single aggregated event instead of firing one webhook per charge. That cuts volume by an order of magnitude during a launch or sale.

    Second, add a lightweight queue in front of your automation platform. A Redis or Amazon SQS queue can absorb bursts, then drip-feed requests to your webhook endpoint at a rate the platform accepts. This requires a small server script but eliminates silent failures during traffic spikes.

    Third, distribute load across multiple Zaps or scenarios. If you’re processing form submissions, route half through one webhook endpoint and half through another. Each gets its own rate-limit bucket, doubling your effective capacity.

    Fourth, monitor webhook delivery at the source. Stripe, PayPal, and most payment processors log every delivery attempt and response code in their dashboard. Check weekly—if you see 429s, you’re already losing data.

    When to move upstream

    If your workflow consistently bumps the webhook cap, it’s time to pull data instead of waiting for pushes. Poll the source API every few minutes using a scheduled automation, or switch to a platform that offers higher-tier webhook quotas.

    Alternatively, move the rate-limited step earlier in the chain. Instead of sending every new subscriber through a webhook to tag them in your CRM, batch-import a CSV once daily. You lose real-time sync but gain reliability and cut webhook volume to zero.

    Want more infrastructure breakdowns like this? Subscribe to One Two Three Send—we explain how online-business tools actually work, one mechanism at a time.

  • SEO metadata sync: when title tags and H1s should match (and when they shouldn’t)

    SEO metadata sync: when title tags and H1s should match (and when they shouldn’t)

    SEO metadata sync: when title tags and H1s should match (and when they shouldn't)
    Photo by Markus Winkler on Unsplash

    Every SEO guide tells you to “align your title tag and H1.” Most don’t explain what that actually means—or when breaking the rule makes more sense.

    Your title tag is what shows in search results and browser tabs. Your H1 is the headline visitors see on the page. Google reads both, but uses them differently. The question isn’t whether they should match—it’s when matching helps and when it boxes you in.

    When Google prefers identical tags

    For commercial pages—product listings, service pages, landing pages optimized for a single term—keeping your title tag and H1 identical removes ambiguity. If your title is “WordPress Managed Hosting for High-Traffic Sites” and your H1 says the same thing, Google has one clear signal about the page topic.

    This matters most when:

    • The page targets a single transactional keyword with commercial intent
    • You’re competing in a crowded SERP where relevance signals need to be unambiguous
    • The page has minimal supplementary content (a signup form, a pricing table, not much prose)

    Identical tags also simplify A/B testing. Change one, change both. You’re testing the hook, not the structure.

    When splitting makes the page stronger

    Editorial content—how-to guides, tutorials, opinion pieces—often benefits from a split. Your title tag optimizes for the search query; your H1 optimizes for the reader who just landed.

    Say you’re writing a guide on WordPress caching. Your title tag might be “WordPress Caching Plugins: Setup Guide and Performance Impact”—a search-friendly phrase with the core term up front. Your H1 could be “How WordPress caching plugins speed up your site (and when they don’t)”—a more conversational hook that sets up the argument.

    The title tag pulled the click. The H1 keeps them reading.

    This split works when:

    • The page serves informational intent and the reader needs context, not just keyword confirmation
    • Your brand voice doesn’t fit into a 60-character title tag
    • You’re targeting a question-based query (“how long does WordPress caching take”) but want a declarative H1 that answers it

    Google’s algorithm has handled this for years. John Mueller noted in a 2021 Google Search Central hangout that differing title and H1 text is normal and that the search engine doesn’t penalize it when both are relevant to the page content. The key is relevance, not duplication.

    What happens when they conflict

    Conflict isn’t the same as variation. If your title tag promises “WordPress Hosting Speed Tests” and your H1 says “Why We Switched to Managed WordPress,” you’ve created a relevance gap. The searcher expected data; you gave them a migration story.

    Google may rewrite your title tag in the SERP if it decides the H1 or another on-page element better matches the query. According to a Google Search Central explainer on title links (checked November 2026), the system generates titles based on page content, including headings and other text, when it believes the provided title doesn’t accurately describe the page.

    That rewrite isn’t always bad—it can improve CTR for queries you didn’t optimize for—but it means you’ve lost control of the message. If you’re seeing frequent rewrites in Search Console, the mismatch is usually the reason.

    How to decide for your own pages

    Start with intent. If the page exists to rank for a single term and convert that traffic, match your tags. If it exists to inform, educate, or build trust, give yourself room to write a better H1.

    Check what’s ranking. Open an incognito window, search your target term, and scan the top five results. If every title tag and H1 is near-identical, you’re in a space where exact-match still wins. If you see variation, the SERP tolerates (or rewards) editorial voice.

    And if you’re not sure, test both. Publish with matched tags, let it index, then split them after a month and watch Search Console for position and CTR shifts. The data will tell you whether the tighter signal or the better hook wins.

    One more thing: if this kind of operator-to-operator breakdown is useful, subscribe to One Two Three Send—we publish six days a week on the tools, tactics, and trade-offs that matter when you’re running a content business solo.

  • WordPress revision storage: how much disk each draft really uses

    WordPress revision storage: how much disk each draft really uses

    WordPress revision storage: how much disk each draft really uses
    Photo by Nick on Unsplash

    WordPress saves a complete copy of your post content every time you hit save. Not a delta. Not a diff. The entire post body, custom fields, and metadata—duplicated in full and written to wp_posts with a row type of revision.

    For a solo operator publishing three posts a week, this rarely matters. But if you’re running a content site with multiple contributors, long-form articles, or dozens of custom fields per post, revision storage can balloon into hundreds of megabytes—sometimes gigabytes—of database bloat that slows queries, inflates backups, and complicates migrations.

    Where revisions live and how they grow

    WordPress stores every revision as a separate row in the wp_posts table, linked to the parent post by post_parent. Each revision carries the full post_content, post_title, post_excerpt, and timestamp. If you use custom fields or a page builder that serializes layout data into post meta, those get duplicated too—in wp_postmeta, keyed to the revision ID.

    By default, WordPress keeps every revision forever. A 5,000-word post edited twenty times generates twenty full copies of that content. If you’re embedding base64 images in custom fields or storing JSON layout blocks, each revision can exceed 100 KB. Twenty revisions × 100 KB = 2 MB for one post.

    Multiply that across a year of publishing and you’re looking at meaningful disk usage—and slower SELECT queries whenever WordPress scans wp_posts without an index filter on post_type.

    How to cap or disable revisions

    You can limit the number of revisions WordPress keeps by adding a constant to wp-config.php:

    define( 'WP_POST_REVISIONS', 5 );

    This keeps the five most recent revisions per post and discards older ones on the next save. Setting it to false disables revisions entirely, though that also removes the ability to roll back accidental edits—useful for solo operators who publish fast and rarely need an undo buffer.

    To disable autosave (which triggers a revision every 60 seconds by default), add:

    define( 'AUTOSAVE_INTERVAL', 300 );

    That pushes the interval to five minutes. You can’t disable autosave completely without a plugin, but stretching the interval cuts down on duplicate saves during editing sessions.

    The WordPress Codex documents both constants under Revisions (checked November 2026).

    When to prune and how much you’ll recover

    If you’ve been running WordPress for years without a revision limit, you can reclaim disk space by deleting old revisions. Plugins like WP-Optimize and Advanced Database Cleaner offer one-click pruning, but you can also run a manual query:

    DELETE FROM wp_posts WHERE post_type = 'revision';

    Follow it with:

    DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL;

    That clears orphaned post meta tied to deleted revisions. On a 500-post site with twenty revisions per post, you might recover 200–500 MB of database storage. On larger content operations, the savings can hit multiple gigabytes.

    After deletion, run OPTIMIZE TABLE wp_posts; and OPTIMIZE TABLE wp_postmeta; to reclaim the freed space and rebuild indexes. Most managed WordPress hosts (including BigScoots) run nightly optimization, but manual pruning is faster if you’re migrating or cloning a site.

    One non-obvious consequence: backup size and restore time

    Revisions don’t just eat disk—they inflate every database backup. If your nightly backup routine dumps the entire database to S3 or a remote server, a bloated wp_posts table means longer backup windows, higher transfer costs, and slower restores when you need to roll back.

    A 2 GB database with 1.5 GB of revisions takes three times as long to restore as a pruned 500 MB copy. If you’re running automated staging-site clones or testing migrations, trimming revisions before export cuts minutes—sometimes hours—off the process.

    If you’re managing a high-frequency content site, set WP_POST_REVISIONS to 3–5 in wp-config.php today. You’ll keep enough history to recover from mistakes without letting old drafts compound into database drag. And if you’ve never pruned, run a one-time cleanup and watch your backup size drop.

    Got a WordPress infrastructure question? Reply and we’ll cover it in a future issue.

  • Reader Q&A: How to track open rates when privacy blocks pixels

    Reader Q&A: How to track open rates when privacy blocks pixels

    Reader Q&A: How to track open rates when privacy blocks pixels
    Photo: Poojakc10 via Wikimedia Commons (CC BY-SA 4.0)

    A reader asked: “Apple Mail Privacy Protection means half my list shows 100% opens. How do I know what’s actually being read?”

    Short answer: you can’t track individual opens reliably anymore. Apple’s Mail Privacy Protection (MPP), rolled out in 2021 and now used by roughly 50% of email clients according to Litmus data (checked November 2026), prefetches and caches emails—including tracking pixels—before the recipient ever opens them. Gmail and other providers have followed with similar privacy features.

    But you’re not flying blind. You just need to shift what you measure and how you interpret it.

    What still works: aggregate engagement and click behavior

    Open rates are now a ceiling, not a floor. If your newsletter platform reports 65% opens, that tells you at most 65% of your list received the email in an inbox that loaded images. It doesn’t tell you who read it.

    Click-through rate (CTR) becomes your primary engagement signal. Clicks require intentional action—a privacy feature can’t fake them. Track total unique clicks per send, and watch the trend over time. If CTR drops while reported opens stay flat or rise, you know engagement is softening even if the open number looks healthy.

    Most newsletter platforms—Beehiiv, MailerLite, ConvertKit, Buttondown—report clicks with full attribution. Focus there. A 3–5% CTR on a content newsletter is typical; above 8% suggests strong relevance.

    Segment by domain and client when possible

    Not all subscribers are affected equally. MPP primarily impacts users on Apple Mail (iOS, macOS, iCloud.com). Gmail users on the web client or Android app generally don’t trigger prefetch behavior in the same way.

    If your platform lets you segment by email domain or client, compare engagement across groups. Look at click rates for @gmail.com vs. @icloud.com vs. @hey.com addresses. You’ll often find that non-Apple domains still show meaningful open-rate variation, while Apple domains cluster near 100% or show erratic patterns.

    This won’t give you individual-level certainty, but it helps you understand where your data is cleanest and where it’s noisiest.

    Use reply rate and conversion events as ground truth

    If you include a question, poll, or call to reply in your newsletter, track how many people respond. Reply rate is unambiguous—someone had to read enough to hit send.

    Similarly, if you link to a landing page, product, or signup form, your analytics platform (Google Analytics, Plausible, Fathom) will show referral traffic from your email. Cross-reference newsletter send time with a spike in email referrals. That’s real engagement.

    For monetised newsletters, track attributed revenue or conversions per send. If you’re promoting an affiliate link, course, or sponsorship landing page, measure downstream outcomes instead of trying to back-solve from open data.

    Stop optimising subject lines for open rate alone

    Pre-MPP, A/B testing subject lines against open rate made sense. Now, that metric is too noisy to trust for statistical significance unless your list skews heavily toward non-Apple clients.

    Test subject lines against click rate or reply rate instead. Pick two variants, send to a small segment, wait an hour, and see which drove more link clicks. That’s the version that got people to engage, regardless of whether the pixel fired honestly.

    Better yet: test entire email concepts—topic, format, CTA—rather than marginal wording tweaks. The signal-to-noise ratio is higher.

    What to tell stakeholders or sponsors

    If you sell sponsorships or report metrics to a team, don’t bury the MPP caveat. Explain that opens are directional, not precise, and provide click data and conversion tracking as the verified engagement layer.

    Most sponsors in 2026 understand this. If they don’t, point them to the Apple Privacy Features page (checked November 2026) and any of the dozens of trade articles published since 2021. Open rate inflation is now industry-standard context.

    Offer attributed traffic (UTM-tagged links), conversions, or reader survey data instead. These are harder to game and more closely tied to sponsor ROI.

    One last thing: if your newsletter platform still highlights open rate as the top-line metric on your dashboard, dig into the settings. Many now let you reorder or hide it. Put clicks, growth rate, and reply rate up front instead. What you look at every morning shapes what you optimise for—make sure it’s a number that still means something.

    Got a question about running your online business? Hit reply or send it our way—we’ll answer it in a future edition.

    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.

Powered by CookieAdmin