Run Webflow on a Subdomain While WordPress Runs Your Main Site (2026 Guide)

I get this question from clients about once a month. Their main site runs on WordPress, they want to launch something on Webflow (a campaign hub, a careers site, a new product page that needs design they can actually ship), and they don't want to migrate everything or pay a developer to rebuild the WordPress side from scratch. Subdomain is almost always the right answer. I've shipped a dozen of these setups now. Here's the operator version of what actually happens: where DNS gets messy, what breaks when your CMS load grows, and how to think about the SEO side honestly.

Can I run Webflow on a subdomain while my main site is WordPress?

Yes, and it's the cleanest split I run for clients who don't want to leave WordPress but need Webflow's design and CMS for one part of their site. Put WordPress on the root domain (yoursite.com) and Webflow on a subdomain (go.yoursite.com, careers.yoursite.com, learn.yoursite.com). Two separate hosting environments, two separate CMSes, one brand at the URL bar.

This is how every Webflow microsite project I've shipped for a WordPress-first client has been set up. Last year I built a careers hub on careers.[client].com for a UK B2B SaaS company whose main site sat on a heavily customised WordPress install they had no appetite to touch. We wanted custom-designed role pages, automatic syndication to job boards via Airtable, and faster iteration than their dev cycle could give them. Webflow on the subdomain solved every one of those, and their main site engineers never had to know it existed.

The mental model that helps: a subdomain split means you treat the WordPress site and the Webflow site as two products that happen to share a brand. They share the navigation, the visual identity, and that's it. They don't share a database, they don't share users, they don't share templates. Trying to integrate them past the brand level is where teams get into trouble. The subdomain is the seam, and you respect the seam.

There's no Webflow plugin for WordPress that meaningfully changes this, and there shouldn't be. The thing people Google (Webflow WordPress plugin) doesn't really exist as a serious tool, because the two platforms aren't trying to be one stack. The plugins that do come up are usually export tools that take a Webflow page and dump its HTML into a WordPress template, which strips out the part of Webflow that's actually valuable (the visual editing, the CMS, the hosting). I tried that route exactly once for a client in 2022. Within three months they were back asking me to rebuild it as a proper subdomain.

How do I connect a Webflow custom subdomain to a WordPress site?

The connection is entirely DNS. You're not integrating anything at the application level; you're pointing one subdomain at Webflow's servers while the root keeps pointing at wherever WordPress lives. Both sites operate independently.

Here's the actual sequence I run for clients:

1. Decide the subdomain. The convention I usually push for: go.yoursite.com for marketing hubs, learn.yoursite.com for education content, careers.yoursite.com for hiring, get.yoursite.com for campaigns. Avoid www2 and similar. It looks unprofessional and Google has historically treated it oddly.
2. Add the custom domain inside the Webflow project. Project Settings, then Publishing, then Custom Domains, then add the subdomain. Webflow gives you a CNAME target that looks like proxy-ssl.webflow.com or, on newer projects, a different host. Copy that target exactly.
3. Add the CNAME at your DNS provider. This is the part that trips people up because they assume DNS lives at WordPress. It almost never does. WordPress is the application, but the domain's DNS is usually managed at Cloudflare, Namecheap, GoDaddy, Route 53, or wherever the original domain was registered. Add a CNAME record: host is "go" (or whichever subdomain), value is the Webflow target. TTL 3600 or default is fine.
4. If you use Cloudflare proxying, turn the orange cloud OFF for this subdomain. Webflow handles SSL itself, and if Cloudflare proxies in front of it you'll either get certificate issues or break Webflow's CDN. Set the record to DNS Only (grey cloud) and let Webflow do its job.
5. Wait for SSL. Webflow auto-provisions an SSL certificate once the DNS resolves. This takes anywhere from five minutes to a couple of hours. If it's been longer than that, check that the CNAME resolves correctly from a public DNS lookup tool. About one in five client projects I do has some legacy DNS record (an old A record, a stray TXT) that needs to be cleaned up before the cert provisions.
6. Publish the Webflow project to the custom domain. Until you click publish to the custom domain (not just to the webflow.io staging URL), nothing serves at the subdomain. People miss this.

The WordPress side does absolutely nothing during this. Your WordPress site doesn't need a plugin, doesn't need a redirect, doesn't need anything. The root domain keeps resolving to your WordPress host through its existing A record. The subdomain gets its own CNAME pointed at Webflow. Two records, two destinations, one happy brand.

The one piece of cross-stitching worth doing is navigation. Edit the WordPress header to link to the Webflow subdomain where it should, and recreate the same navigation in the Webflow project pointing back to the WordPress URLs. Users should never feel the seam. Search engines will see two separate properties (more on that in a second), but humans should experience one site.

Does running Webflow on a subdomain hurt SEO?

Short answer: a properly executed subdomain split doesn't hurt rankings, but Google treats subdomains as separate properties for crawling and indexing purposes, which means your SEO setup has to be doubled, not halved. That's the honest tradeoff.

A few things I tell clients who are nervous about this:

Subdomain vs subdirectory has been an SEO debate for fifteen years, and the answer keeps shifting. Right now, in 2026, Google says it treats them effectively the same for ranking. In practice, subdomains accumulate authority slightly more slowly because some of the topical signals don't carry across as cleanly. That gap has narrowed enormously in the last five years. For most B2B and SaaS sites, the ranking impact is negligible compared to the operational cost of trying to force Webflow into a subdirectory.

Forcing Webflow into a subdirectory is technically possible and almost always a bad idea. You can use a reverse proxy (Cloudflare Workers, a custom Nginx config, or a service like Reblaze) to make Webflow content appear at yoursite.com/learn/ instead of learn.yoursite.com. I've built this for one client whose marketing team insisted on subdirectory for cross-linking reasons. It worked, but the maintenance overhead was real: every Webflow publish required cache invalidation, SSL config was painful, and we had to keep two CDN configs in sync. Unless you have a strong SEO reason and an engineer who's going to own the proxy long-term, use the subdomain.

The SEO doubling is the part to budget for. You'll need a separate sitemap for the Webflow subdomain (Webflow generates this automatically), a separate Google Search Console property for the subdomain, separate analytics tracking (or a shared GA4 property with the subdomain configured), and your robots.txt files don't share. I've had clients lose two months of indexing because they assumed adding their root domain to Search Console covered the subdomain too. It doesn't.

Internal linking is where most teams underperform. Cross-link from WordPress to your Webflow subdomain like you'd cross-link to any external high-authority site. Real anchor text, contextual placement, not just a header nav link. Same in reverse. The subdomain gets a meaningful authority boost from being linked to from a high-traffic root domain. If WordPress is your main traffic source, this is the lever that closes most of the subdomain-versus-subdirectory gap.

One thing I won't sugarcoat: if you currently rank well on the WordPress site for queries you're now trying to attack with a Webflow microsite, splitting the topic across two properties can dilute the strongest page. The fix is to plan the content split carefully, not to default to "everything new goes on the subdomain." If a piece of content belongs on the main site for SEO reasons, build it on WordPress. The subdomain is for new territory or for content where you need Webflow's design and CMS flexibility enough to accept the SEO tradeoff.

Webflow CMS on subdomain vs WordPress: which should handle what?

The rule I run with: WordPress holds the content your team is already used to publishing into it, Webflow holds the content where editorial control and design polish matter more than blog-style throughput. The CMS choice should follow the editorial workflow, not the other way around.

In practice, here's how I split it for most clients.

WordPress keeps the main blog, news, press releases, anything with a high publishing cadence by a content team that already lives in WordPress. Don't fight muscle memory unless there's a real reason.

Webflow takes product pages, landing pages, careers pages, case studies, customer story hubs, programmatic SEO collections, anything that needs structured fields, designed layouts, and reference relationships. Webflow Collections are far better for this than WordPress's custom post types, especially once you start using reference fields and dynamic embeds.

The deeper question is what breaks at scale, and this is where I see most subdomain setups creak. Webflow's CMS has hard limits: 10,000 items per collection on the higher plans, 20 reference fields per collection, no SQL access. For most marketing use cases that's plenty. When it isn't, you don't migrate off Webflow; you put a real data layer behind it.

I usually do this with Airtable as the source of truth, syncing items into Webflow Collections via Whalesync or n8n. The marketing team manages content in Airtable (faster, more familiar), Webflow renders it. I've written up the full setup in my [Airtable and Webflow integration guide](/airtable-webflow), because once you're past about 2,000 collection items or you need bulk updates, the native Webflow editor gets slow and the sync workflow saves you a meaningful number of hours per week.

For one client with a programmatic SEO play of 3,000+ location pages, Airtable sat in front of Webflow with city data, service data, and template references. Their team updated rows in Airtable. The Webflow site rebuilt the affected pages. The WordPress main site never had to know. That's the kind of split where the subdomain architecture actually pays for itself, because trying to run 3,000 programmatic pages through WordPress would have meant either ACF Pro plus a custom build (expensive and brittle) or a full developer team (unaffordable for that client). The Webflow plus Airtable stack let a small marketing team operate at engineering scale.

The seam to watch is user data. If you need a real account system, gated content, or e-commerce that talks to the same customer record on both sides, neither Webflow nor WordPress should own it. Put that in a real backend (Auth0 or Clerk for auth, Stripe for payments, an actual database for users) and let both Webflow and WordPress consume it through embeds or API calls. I've watched teams try to bridge WooCommerce on the WordPress side with Webflow Memberships on the subdomain and it always ends in tears. Don't.

When the subdomain split isn't the right answer

A few situations where I tell clients to stop and reconsider:

- You want one unified blog with one set of categories and one feed. Don't split it. Pick one platform.
- **You're already using WordPress for the main site because of a heavy plugin or integration dependency.** Confirm that nothing in your stack needs to live across both domains before you commit.
- **Your dev team has zero Webflow experience and no interest in learning.** Webflow is a different operating model. If nobody's going to own it, don't ship it.
- **You're doing this primarily to get off WordPress hosting.** Migrate properly instead. The subdomain is for parallel operation, not for sneaking off WordPress one page at a time.

If any of those land, the answer might be a full Webflow migration, sticking with WordPress and improving it, or a different stack entirely. I do those engagements too; details on how I work are on the [Webflow developer](/webflow-developer) page.

Frequently asked questions

Do I need a Webflow plugin for WordPress?

No. The subdomain split doesn't use any plugin. The connection is a DNS CNAME record, not an application-level integration. Most plugins marketed as "Webflow for WordPress" are HTML exporters that defeat the point of using Webflow.

Will users notice they're moving between two sites?

If you've matched the design and navigation properly, no. The URL bar changes from yoursite.com to go.yoursite.com (or wherever you put it), but that's the only signal. Match the header, footer, fonts, and core color tokens, and the experience reads as one site.

Can I use the same Google Analytics property across both?

Yes. Set up GA4 with the root domain and the subdomain as the same property, and configure cross-domain measurement so a single user session stitches across both. Without that step you'll see inflated session counts because every cross-property hop creates a new session.

What about email and other subdomains?

The subdomain you point at Webflow only affects that one host (go.yoursite.com). Your MX records, mail subdomains, and other DNS records aren't touched. The risk is only if you're overwriting an existing CNAME with the same name, which is rare in practice.

Can I move the Webflow content back to the root domain later?

Yes, with planning. You'd publish the Webflow project to the root, set up redirects from the subdomain to the new locations, and migrate WordPress to a subdirectory or shut it down. It's a project, not a one-click switch. Don't start with a subdomain split assuming you'll consolidate later unless you've costed that future migration honestly.