Custom Domain SEO for SaaS: How We Built White-Label Domain Support

How we implemented custom domain support for 1000+ SaaS tenants and achieved a 250% improvement in organic search rankings while automating SSL certificate provisioning

The Problem: Multi-Tenant SEO Dilution

When we launched FIKR as a multi-tenant SaaS platform, every customer lived on a subdomain: customer1.fikr.space, customer2.fikr.space, and so on. From a development perspective, this was elegant. Single codebase, wildcard SSL certificate, simple routing logic. We could onboard new customers in seconds without touching any infrastructure. But as our customers started growing and taking their content marketing seriously, we kept hearing the same feedback: "Why can't we use our own domain?"

At first, we didn't understand why this mattered so much. A subdomain works perfectly fine from a technical perspective. The content is identical whether it's served from customer.fikr.space or blog.customer.com. But then we started looking at the SEO data, and the problem became crystal clear.

Our customers' content was performing poorly in search results, not because the content was bad, but because search engines treated all subdomains as part of fikr.space. When Google crawled customer1.fikr.space and customer2.fikr.space, it saw them as sections of our domain, not as distinct websites owned by separate companies. This meant our customers were competing with each other for rankings. Even worse, the domain authority they built through their content marketing efforts was accruing to fikr.space, not to their own brands.

One customer came to us with hard data. They'd been publishing high-quality content on their FIKR subdomain for six months. Their blog posts were getting maybe 50-100 organic visits per month total. They decided to test moving a few posts to a custom domain they owned, keeping everything else identical. Within 30 days, those same posts were getting 300-400 visits per month. Same content, same quality, same topics. The only difference was the domain. That's when we knew we had to solve this problem properly.

We explored several options. The simplest approach was telling customers to use CNAME records pointing to our infrastructure, but that left them managing DNS changes and SSL certificates manually. The most complex was building a full-featured domain management system like what you'd find in Shopify or WordPress.com. What we needed was something in between: automated, scalable, and transparent to end users while giving our customers complete control over their domain presence.

Understanding Custom Domain Architecture

A custom domain system for multi-tenant SaaS needs to solve three core challenges: domain verification, SSL certificate provisioning, and request routing. Each of these problems has technical complexity that compounds at scale. When you're handling one custom domain, you can use manual processes. When you're handling 1000+ domains, everything must be automated and foolproof.

Here's the flow we designed for onboarding a new custom domain:

1. Customer enters their desired domain (blog.example.com) in our dashboard
2. System generates unique verification DNS records (TXT and CNAME)
3. Customer adds DNS records at their domain registrar
4. Our verification service polls DNS every 60 seconds checking for records
5. Once verified, we automatically provision an SSL certificate via Let's Encrypt
6. Domain becomes active and starts routing traffic within 2-5 minutes
7. System monitors certificate expiration and renews automatically 30 days before expiry

The key architectural decision was using Cloudflare for SaaS as our foundation. Cloudflare for SaaS is a service specifically designed for our use case. It handles SSL certificate provisioning and renewal automatically, provides DDoS protection for all custom domains, and includes their global CDN network. Instead of building certificate management from scratch, we could focus on the domain verification and routing logic.

But Cloudflare for SaaS doesn't solve the entire problem. We still needed to build the verification system, the customer-facing dashboard for domain management, and the routing logic that maps incoming requests to the correct tenant. Most importantly, we needed to handle edge cases: what happens when a certificate fails to provision? What if a customer accidentally removes their DNS records? How do we handle subdomain vs apex domain configurations?

DNS Configuration: Subdomain vs Apex Domain

One of the most common points of confusion for customers is the difference between subdomain and apex domain configurations. This distinction matters significantly for how custom domains are set up and what DNS records are required. Understanding this helps explain why some setups are more complex than others.

A subdomain configuration is when a customer wants to use something like blog.example.com or docs.example.com. The "blog" or "docs" part is the subdomain. These are simple to configure because they use CNAME records, which are DNS records that create an alias from one domain to another. The customer just points blog.example.com to their assigned hostname on our infrastructure, and everything works immediately.

Apex domains (also called root domains or naked domains) are more complex. These are domains without any subdomain prefix, like example.com. The technical challenge is that DNS specifications don't allow CNAME records at the apex domain level. This restriction exists because the apex must have SOA and NS records, and CNAMEs conflict with these required records. To work around this limitation, we use ALIAS records (supported by some DNS providers) or A/AAAA records pointing to Cloudflare's anycast IP addresses.

Here's what we recommend to customers based on their use case:

• Subdomain (blog.example.com): Add CNAME record to your-org.ssl.fikr.space - Simple, works everywhere, recommended for most use cases
• Apex Domain (example.com): Requires ALIAS record or A/AAAA records - More complex, some DNS providers don't support ALIAS
• www Subdomain (www.example.com): Same as subdomain approach, commonly used for main websites
• Multiple Subdomains: Each subdomain needs its own CNAME record and verification

From an SEO perspective, subdomains work better for content that's distinct from the main website. If a customer uses example.com for their product homepage and blog.example.com for content marketing, search engines treat these as separate properties. This can be beneficial because the blog builds its own domain authority without being judged against the product pages. However, if a customer wants all their SEO value concentrated in one place, using a subdirectory on their main domain (example.com/blog/) would be better, though this requires different technical integration.

Implementation: Domain Verification Service

The domain verification service is the heart of our custom domain system. It needs to be reliable, fast, and handle edge cases gracefully. We built it as a standalone service that runs independently from our main application, polling DNS records every 60 seconds for domains in "pending verification" status.

Here's the core verification logic:

// Domain Verification Service
interface CustomDomain {
  id: string;
  organizationId: string;
  domain: string;
  status: 'pending' | 'verified' | 'active' | 'failed';
  verificationToken: string;
  cloudflareHostnameId?: string;
  sslStatus: 'pending' | 'active' | 'failed';
  createdAt: Date;
  verifiedAt?: Date;
}

async function verifyDomain(customDomain: CustomDomain): Promise {
  const txtRecord = `_fikr-verification=${customDomain.verificationToken}`;
  const cnameTarget = `${customDomain.organizationId}.ssl.fikr.space`;

  // Check for verification TXT record
  const txtRecords = await resolveDNS(customDomain.domain, 'TXT');
  const hasTxtRecord = txtRecords.some(record =>
    record.includes(customDomain.verificationToken)
  );

  // Check for CNAME record pointing to our infrastructure
  const cnameRecords = await resolveDNS(customDomain.domain, 'CNAME');
  const hasCnameRecord = cnameRecords.some(record =>
    record.includes(cnameTarget)
  );

  if (hasTxtRecord && hasCnameRecord) {
    // Domain verified, initiate SSL provisioning
    await provisionSSL(customDomain);
    return true;
  }

  return false;
}

This verification approach uses both TXT and CNAME records for security. The TXT record proves the customer controls the domain. Anyone can point a CNAME at our infrastructure, but only someone with DNS access can add a TXT record with our verification token. The CNAME record ensures traffic will route correctly once verification completes.

SSL certificate provisioning happens through Cloudflare for SaaS's API. Once domain verification succeeds, we make an API call to Cloudflare that triggers certificate issuance through Let's Encrypt's ACME protocol. The entire process is automated:

async function provisionSSL(customDomain: CustomDomain) {
  // Create custom hostname in Cloudflare for SaaS
  const response = await cloudflare.customHostnames.create({
    hostname: customDomain.domain,
    ssl: {
      method: 'txt',
      type: 'dv',
      settings: {
        http2: 'on',
        min_tls_version: '1.2',
        tls_1_3: 'on'
      }
    }
  });

  // Store Cloudflare hostname ID for future operations
  await db.customDomains.update(customDomain.id, {
    cloudflareHostnameId: response.result.id,
    sslStatus: 'pending'
  });

  // Monitor certificate issuance
  await monitorSSLProvisioning(customDomain.id, response.result.id);
}

async function monitorSSLProvisioning(domainId: string, hostnameId: string) {
  const maxAttempts = 60; // 60 attempts = 10 minutes

  for (let i = 0; i < maxAttempts; i++) {
    await sleep(10000); // Check every 10 seconds

    const status = await cloudflare.customHostnames.get(hostnameId);

    if (status.ssl.status === 'active') {
      await db.customDomains.update(domainId, {
        status: 'active',
        sslStatus: 'active',
        verifiedAt: new Date()
      });
      return;
    }

    if (status.ssl.status === 'error') {
      await db.customDomains.update(domainId, {
        sslStatus: 'failed'
      });
      throw new Error(status.ssl.validation_errors.join(', '));
    }
  }

  throw new Error('SSL provisioning timeout');
}

The monitoring loop checks certificate status every 10 seconds for up to 10 minutes. In practice, certificates usually issue within 2-3 minutes. If provisioning takes longer than 10 minutes, something is wrong (usually DNS propagation delays or validation failures), and we mark it as failed so our support team can investigate.

Request Routing and Multi-Tenant Resolution

Once custom domains are verified and have active SSL certificates, the next challenge is routing incoming requests to the correct tenant. When someone visits blog.customer.com, our system needs to determine which organization owns that domain and serve their content. This resolution needs to happen on every single request, with latency under 5ms to avoid slowing down page loads.

We use a two-tier caching strategy. The first tier is in-memory caching at the application level. Each application server maintains a LRU cache of the 10,000 most recently accessed domain-to-organization mappings. This cache has a 5-minute TTL and handles 99%+ of requests without hitting the database. The second tier is Redis, which serves as a distributed cache shared across all application servers. If a domain isn't in the local cache, we check Redis before falling back to the database.

// Request routing with multi-tier caching
const domainCache = new LRU({ max: 10000, ttl: 300000 }); // 5 min TTL

async function resolveOrganization(hostname: string): Promise {
  // Tier 1: In-memory cache
  const cached = domainCache.get(hostname);
  if (cached) return cached;

  // Tier 2: Redis cache
  const redisCached = await redis.get(`domain:${hostname}`);
  if (redisCached) {
    const org = JSON.parse(redisCached);
    domainCache.set(hostname, org);
    return org;
  }

  // Tier 3: Database lookup
  const domain = await db.customDomains.findOne({
    domain: hostname,
    status: 'active'
  });

  if (!domain) {
    // Check if it's a default subdomain (org.fikr.space)
    const subdomain = hostname.split('.')[0];
    const org = await db.organizations.findOne({
      slug: subdomain
    });

    if (org) {
      domainCache.set(hostname, org);
      await redis.setex(`domain:${hostname}`, 300, JSON.stringify(org));
      return org;
    }

    throw new Error('Domain not found');
  }

  const org = await db.organizations.findById(domain.organizationId);

  // Cache in both tiers
  domainCache.set(hostname, org);
  await redis.setex(`domain:${hostname}`, 300, JSON.stringify(org));

  return org;
}

This caching architecture means that after the first request to any custom domain, subsequent requests resolve in under 1ms. The 5-minute TTL balances freshness with performance. When a customer adds or removes a custom domain, it takes up to 5 minutes for the change to propagate fully, which is acceptable for this use case since domain changes are infrequent.

Real Results After 6 Months

We launched custom domain support in Q2 2024 and tracked adoption and SEO impact closely. The results exceeded our expectations and validated the significant engineering investment required to build this feature properly.

Before Custom Domains:

• Average organic traffic per customer: 150 visits/month
• Domain authority concentrated on fikr.space: 45 DA
• Customer content ranking on page 2-3 average
• 15% of customers cited subdomain as reason for not using our blog features

After Custom Domains (6 months):

• Average organic traffic per customer: 525 visits/month (+250%)
• Customer domains building independent authority: 20-35 DA after 6 months
• Customer content ranking on page 1 for target keywords: 65% improvement
• Blog feature adoption increased from 35% to 78% of customers
• Infrastructure cost: $149/month for Cloudflare for SaaS plan handling 1200+ domains

The most striking result was the 250% increase in organic traffic for customers who switched to custom domains. This wasn't because we changed anything about the content or improved our SEO capabilities. The same blog posts, written by the same people, simply performed better when published on the customer's own domain rather than a subdomain of fikr.space. Search engines treated the content as authoritative for the customer's brand, rather than as supplementary content on our platform.

Challenges We Had to Overcome

Building custom domain support at scale revealed edge cases we hadn't anticipated during the design phase. The most common issue was customers making DNS configuration mistakes. They'd add the CNAME record but forget the TXT record, or they'd point the CNAME to the wrong target. We solved this with a real-time DNS checker in our UI that queries DNS as the customer configures their domain and shows exactly what records we can see.

The second major challenge was handling certificate renewal at scale. Let's Encrypt certificates expire after 90 days, and Cloudflare automatically renews them 30 days before expiration. But some customers would change their DNS configuration after initial setup, breaking the renewal process. We built a monitoring system that checks all custom domains' SSL status daily and alerts customers 14 days before expiration if renewal validation is failing:

• Automated daily SSL certificate health checks across all 1200+ domains
• Email notifications to customers 14 days before certificate expiration
• Dashboard warnings when DNS records are misconfigured
• Automatic retry logic for failed renewals (attempts every 6 hours)
• Result: Zero certificate expiration incidents in 6 months of operation

Another unexpected challenge was handling internationalized domain names (IDNs). Some customers wanted to use domains with non-ASCII characters, particularly in European and Asian markets. DNS uses Punycode encoding for these domains, so we had to implement conversion logic that transforms user-entered domains like "münchen.example.com" into "xn--mnchen-3ya.example.com" for DNS operations while displaying the human-readable version in our UI.

We also discovered that some corporate firewalls and content filters block Let's Encrypt validation requests. This caused certificate provisioning to fail for about 2% of enterprise customers. Our solution was implementing a fallback validation method using DNS TXT records instead of HTTP validation. This adds complexity but ensures enterprise customers behind restrictive firewalls can still use custom domains successfully.

When Custom Domains Make Sense vs Subdomains

Custom domain support adds significant complexity to a SaaS platform. Before investing the engineering resources to build it, evaluate whether your customers actually need it. Based on our experience and conversations with other SaaS founders, here's how to decide.

Choose custom domains if:

• Your customers need to build domain authority for SEO (content marketing platforms, blogs, documentation sites)
• White-label branding is important (customer-facing portals, help centers, knowledge bases)
• Your customers are enterprises with strict domain policies (compliance requirements, corporate security)
• Your platform hosts public-facing content (websites, landing pages, marketing materials)
• Customers are willing to pay premium pricing for white-label features (usually 2-3x base price)
• You have the engineering resources to build domain verification, SSL automation, and monitoring systems

Choose subdomains if:

• Your platform is primarily for internal tools (dashboards, admin panels, team collaboration)
• Customers don't share their platform URL publicly (internal wikis, project management, CRM)
• SEO is not a factor in customer success (B2B tools, private collaboration spaces)
• You're early stage and need to focus on core product features rather than infrastructure
• Your customer base is mostly SMBs who don't have technical resources for DNS management
• Platform branding is part of your growth strategy (Typeform, Airtable, Notion built brands through subdomains)

Final Thoughts

Implementing custom domain support transformed how our customers think about FIKR. Instead of viewing it as a tool they use internally, they now see it as part of their public brand infrastructure. The 250% increase in organic traffic for customers using custom domains validated that this was the right investment, even though it took three months of dedicated engineering work to build properly.

The key insight is that custom domains are a multiplier, not a standalone feature. They make your SaaS platform's value more visible because customers can build their brand on your infrastructure without sacrificing SEO value to your domain. This is particularly important for content marketing platforms, customer portals, and any SaaS product where users create public-facing content.

From a technical perspective, the combination of Cloudflare for SaaS and automated verification systems made this feasible at scale. Building certificate management from scratch would have taken 6+ months and required dedicated infrastructure operations resources. By leveraging Cloudflare's platform, we focused our engineering effort on the customer experience and domain verification logic while outsourcing the complex parts of SSL certificate lifecycle management.

If you're building a multi-tenant SaaS platform and your customers need public-facing presence, custom domain support should be on your roadmap. Start with solid verification and monitoring systems. Automate everything possible. Plan for edge cases like IDN support and enterprise firewall restrictions. The engineering investment pays off through higher customer retention, increased product value, and significantly better SEO outcomes for your users.