Moving Off Carrd: When a Single Page Isn't Enough Anymore

Carrd is the best ten dollars a non-technical founder can spend. A single page, a handful of sections, a form that forwards to your inbox, a custom domain, and you are on the internet with a product that looks like someone cared. The trouble is that Carrd is designed, explicitly and deliberately, to stop at one page. That constraint is its virtue when you are launching. It becomes a cage the moment your business grows a second organ.

Most founders miss the moment they outgrow it. They notice the symptoms, which are things like an empty blog promise in a newsletter, a product list that has to be rebuilt as an image every time a SKU changes, a demo request form that cannot ask different questions of enterprise versus self-serve leads. Then they spend six months wedging those things into Carrd with embedded iframes and third-party tools, and the site gets slower and stranger, until eventually someone on the team says the word "replatform" and the panic starts.

This piece is the map we wish more founders had before the panic. It covers the three signals that mean you have actually outgrown Carrd (not just that you are frustrated with it for a weekend), the three upgrade paths that make sense in 2026, and the DNS plus redirect checklist for swapping out your landing page without losing a single ranked URL or a single inbound link. WitsCode has run this migration roughly forty times in the last two years, and the pattern below is what works.

The Three Outgrowth Signals

Do not replatform because Carrd feels limiting. It is meant to feel limiting. Replatform when one of three specific jobs becomes the bottleneck on your growth.

The first signal is that you need a CMS-backed blog. Not a changelog, not a three-post "news" section you update by duplicating a Carrd block, but a real content operation. If you have decided to invest in SEO, or you have a content hire, or you are running a newsletter that needs web-viewable archives, you need proper article URLs, proper tags, proper author pages, an RSS feed, and ideally a draft workflow where a non-technical editor can schedule posts without asking an engineer. Carrd cannot do this, and the embed-Notion and embed-Substack workarounds destroy your ability to rank for the articles because the content is not actually on your domain in a crawlable shape. If your marketing plan for the next twelve months includes organic search, the blog signal alone is enough to move.

The second signal is a product or service catalogue that changes. This is the one that catches founders by surprise. Carrd can display ten services on a single page beautifully. It struggles with forty. It chokes at two hundred. If your business has grown to the point where you have distinct pages for different verticals, different integrations, different use cases, or different locations, you have entered programmatic-page territory. You need a template, a data source, and a build system that can stamp out fifty pages from one layout. This is Carrd's native weak spot because Carrd is, at its core, a single-page tool with a small directory feature bolted on. Programmatic SEO, landing pages per ad campaign, integration pages, and alternatives pages all require capabilities Carrd cannot grow into.

The third signal is a custom multi-step form or an authenticated flow. The moment your sales process needs branching logic (enterprise leads go to one qualification form, self-serve to another), or conditional fields, or a calculator that returns a custom quote, or a gated resource that requires a light login, or an embedded Stripe checkout with dynamic line items, you have left the brochure-site world. Carrd forms are single-step and send to an inbox or a webhook. That is it. If you find yourself duct-taping Tally, Typeform, and Zapier together on top of Carrd to simulate a real lead flow, you are paying twice (in subscription fees and in user drop-off on the handoff) for what a real site would give you natively.

If none of those three are true, stay on Carrd. Seriously. The replatform is expensive in time and attention, and a faster Carrd page with one clean CTA beats a half-built Webflow site every single quarter.

Path One: Webflow for Content-Heavy Sites

Webflow is the right answer when your bottleneck is content and your team is non-technical. The CMS is genuinely good. Collections let you define article schemas, team members, case studies, or integrations, and editors can add entries through a web interface that looks like a simplified Airtable. The visual designer gives you real control over layout without ever opening a code file. And the hosting is fast enough out of the box that you will pass Core Web Vitals on a well-built site without thinking about it.

Webflow suits you if your site is going to be between ten and three hundred pages, most of those pages come from CMS collections, and your primary users of the site (the people who will edit it weekly) cannot read HTML. A content marketing hire, a founder who wants to write posts herself, a freelance designer who needs to push a landing page for a campaign without waiting on engineering. Webflow gives all of them safe, in-browser control. The staging environment, the revision history, and the publish-preview flow are all handled.

The tradeoffs are real. Webflow gets expensive as you add seats and CMS items, with the Business plan landing around seventy to eighty dollars a month and the Enterprise tier opening at meaningfully more. You are locked to Webflow's hosting; you cannot pick up your site and run it on Vercel. Custom functionality beyond what Webflow interactions allow requires embedded scripts, which start to feel like the iframe workarounds you left Carrd to escape. And Webflow's form submissions are fine but unexceptional, so if your form is complex you will often end up embedding a Tally or a HubSpot form inside a Webflow page.

Choose Webflow if your primary outgrowth signal was the CMS blog or a content-heavy catalogue and your team will be editing the site themselves without engineering involvement.

Path Two: Astro plus MDX for Content plus Performance

Astro is the right answer when you want Webflow-level ease of content but you have (or can borrow) a developer for the initial build, and you care about performance and cost discipline. Astro is a static site generator that renders almost everything to plain HTML at build time, shipping essentially zero JavaScript by default. It ingests content from local MDX files, from a headless CMS like Sanity or Contentful, from Notion, or from a plain Airtable. The output is cheap to host (Netlify, Cloudflare Pages, and Vercel all have generous free tiers that a typical Carrd-sized site never exceeds) and fast enough to set performance benchmarks your competitors cannot match.

An Astro plus MDX setup gives you proper Git-based version control over content, so changes are reviewable and reversible. It gives you build-time programmatic page generation, which is the clean solution to the second outgrowth signal above. And because Astro lets you drop React, Svelte, or Vue components into specific islands of interactivity without dragging in a whole client framework, you can add a calculator, a pricing toggle, or a gated signup flow exactly where you need it and nowhere else.

The tradeoff is that editing content means either editing MDX files in Git (fine for technical teams, alienating for marketing hires) or plumbing in a headless CMS (doable, but now you are maintaining two systems). The build-and-deploy cycle, even with hot reloading locally, is not as immediate as Webflow's publish button. And the initial build requires a developer, which Carrd and Webflow do not.

Choose Astro if performance is a stated priority, you have development capacity at least for the build, you want a blog or programmatic pages, and your content editors either know Git or will accept a headless CMS workflow.

Path Three: Next.js for Custom App-Like Experiences

Next.js is the right answer when your site stops being a site and starts being a product. The third outgrowth signal, the custom multi-step form or authenticated flow, is the one that usually forces this path. If you are building a quote calculator with saved sessions, a client portal with a login, an interactive demo that talks to your backend, a marketplace with a search index, or any interface where the user is doing work and not just reading, you need server-rendered React with proper API routes, and that is what Next.js is for.

A Next.js build on Vercel, with a headless CMS for the marketing pages (Sanity and Contentful are the safe picks), a database (Postgres through Supabase or Neon), and authentication (Clerk or Auth.js), gives you everything Webflow gives a marketing team plus everything your product team needs to build the parts that are not just pages. You own the code. You can move it off Vercel if you ever need to. You can run A/B tests with Vercel's edge middleware, localise with Next's i18n routing, and integrate Stripe or HubSpot without a third-party embed.

The tradeoff is that Next.js is a framework, not a tool. It requires a real development team, a real deploy pipeline, and real ongoing maintenance. It is not what you choose because Carrd is limiting; it is what you choose when you have confirmed, through the three outgrowth signals, that your marketing site and your product interface are converging and need to live in the same codebase.

Choose Next.js if the custom form or authenticated flow signal dominates, or if the site and the app are becoming the same thing.

The DNS and 301 Checklist for Swapping the Landing Page

This is the section founders underinvest in and regret later. The technical migration itself is straightforward. The ranking preservation is not, and a sloppy swap can erase six months of SEO work in an afternoon. Run this checklist for every Carrd replatform, regardless of which path above you chose.

First, inventory every live URL on Carrd. A single-page Carrd site still has section anchors (yoursite.com/#pricing, yoursite.com/#about) that external sites may have linked to and that Google may have indexed as distinct URLs through fragment handling. Export them. For any sub-page or secondary Carrd site on a subdomain, inventory those too.

Second, map every old URL to a new URL on the destination platform. Hash anchors on the old single page typically map to proper routes on the new site (/pricing, /about, /features) or to scroll-to-section anchors on the new homepage. Do not leave any URL unmapped. An unmapped URL that had backlinks is lost link equity. Where Carrd used a subdomain (like hi.yourdomain.com for a secondary page), decide whether the new site will keep the subdomain or consolidate to the apex.

Third, stage the new site on a temporary subdomain. Put it on staging.yourdomain.com or a Vercel preview URL, and block it from indexing with a robots.txt disallow and an X-Robots-Tag header. Never let Google index the staging site; the duplicate content will confuse the eventual cutover.

Fourth, set up the 301 redirects on the new site before you change DNS. In Webflow, this is the redirects panel under site settings. In Astro and Next.js, it is a redirects config in your hosting provider (vercel.json for Vercel, netlify.toml for Netlify, or _redirects for Cloudflare Pages). Every old URL must return HTTP 301 to its mapped new URL. Not 302. Not a meta refresh. A proper permanent redirect.

Fifth, lower the TTL on your DNS A and CNAME records at least 24 hours before the cutover. Drop it from the default 3600 seconds to 300. This means when you flip the records, caches flush globally in five minutes instead of an hour.

Sixth, the cutover itself. Change the A record (or CNAME, for most modern hosts) from Carrd's IP to the new host's IP or alias. Simultaneously, unpublish the Carrd site (do not delete it; keep the project in case you need to roll back). Verify propagation with a DNS lookup tool across at least three geographic regions.

Seventh, within the first hour after cutover, crawl the new site with Screaming Frog or a similar tool, starting from the homepage, and confirm that every internal link resolves to a 200 and every redirect returns a single 301 (not a chain). Fix any redirect chains, which dilute link equity.

Eighth, in Google Search Console, submit the new sitemap, and use the URL Inspection tool to request reindexing of your highest-value pages. Monitor the Coverage report daily for two weeks. Watch for any old URL that is still being crawled and is not being redirected correctly. Watch for a drop in impressions, which is the early warning sign of a ranking loss.

Done properly, the ranking transition is invisible. Impressions dip for three to five days, then recover, and within two weeks the new URLs are ranking at parity with the old ones. Done sloppily, which almost always means skipping the 301 mapping or deleting the Carrd site before propagation completes, you lose three months of work.

Where WitsCode Fits

If you recognised one of the three outgrowth signals above and you do not have a technical co-founder or an in-house team to run the migration, the ninety days of back-and-forth it would take to do it safely is the ninety days you should be selling instead. WitsCode runs Carrd-to-Webflow, Carrd-to-Astro, and Carrd-to-Next.js migrations as a fixed-scope engagement, including the URL inventory, the 301 map, the DNS cutover, and the post-launch Search Console monitoring. The rebuilt site goes live with rankings preserved and your content team (or your engineering team, depending on the path) trained on the workflow. If you are at the outgrowth moment and you want the cutover handled, the WitsCode upgrade engagement is the route -> start there.