Developers October 9, 2020

Subdomain vs domain for the authenticated users

Masatoshi Nishimura @massanishi

I notice many saas hackers use regular domains for the landing page. Once the user is logged in, they are directed for subdomain. Google uses this approach for all their business suites (ex: https://doc.google.com). But there are exceptions like Netflix who keeps the domain for authenticated/unauthenticated the same.

Using the static landing page that takes up the whole root domain seems like a waste to me. And you'll need to still check the authentication in the backend even for the landing page so you can redirect the users appropriately. So you cant just serve the static html at the end of the day even for the root.

Here is a rough pro/con I can think using subdomain approach.

Pro

  • You can assume every part of the app is authenticated user
  • Deployment is separate from the landing page.

Con

  • Need to handle extra domain network config
  • Need to configure extra web server like nginx

Do you have your preferred approach?

  1. 6

    I think a good framework for thinking about this is:

    You are going to want to take separate approaches to how you build your marketing website (for first-time visitors), vs. your production web app (for customers).

    You want to treat this like two separate products. Build something mostly static that you can serve up, SEO optimized and instrumented with your preferred analytics tools, on your root domain or www. 301 Redirect the one you don't choose to the other.

    Set up your help docs and blog underneath your top-level domain (so they contribute to the same bucket of SEO work). Like /blog/ and /docs/.

    Then work really hard to optimize that product for first-time visitors, and for Google.

    Then optimize app.yoursite.com for your long-term customers. A company that reaches analytics maturity will have a separate set of tools for instrumenting and optimizing the site users use. And you're not going to want most of that to leak into Google analytics.

    Typically, the Marketing team owns Google analytics, and the Product team owns your event analytics. They can mostly be siloed as long as you figure out attribution and an easy way to correlate attribution from the Marketing side into the Product team's analytics stack, and send them monthly reporting on performance based on the attribution they're sending you.

    I have a reverse proxy in front of our public website to merge everything we do for marketing purposes (website + blog + all help documentation). You could use this to put the app under /app/ or something similar, but it's going to make it harder to keep GoogleBot doing what you want it to do, and you're going to have to instrument it with separate analytics anyway. So, there's not much upside.

    Netflix has a lot of upside to merging their app and website because they want to use the unauthenticated directory listing of their content library to pull in users from Google. They want to rank for "watch ____ online", where ____ is every long-tail search that matches something in their library. They even generate pages for stuff that isn't in their library!

    Another benefit of a static site is that you can serve millions of visitors for like a buck a month. You just stick your site in an s3 bucket, and point a CNAME record to it. Never have to worry about a blog post going viral and taking down the site.

    Lots of tradeoffs though. Everyone who contributes to the site needs to be more technical. And there's a bunch of off-the-shelf tools you can't use -- which may carry huge SEO and marketing benefits, since their defaults are sometimes much more robust (your static templates might forget to include all the relevant meta tags, or some other basic on-page SEO checklist item).

    1. 3

      This is a great explanation! I'm going through this right now building no-code apps. It seems the path is to build a static site on the domain using a landing page / marketing automation tool, and then put the no-code app on the subdomain.

    2. 2

      Thanks for the detailed and clear breakdown. I like that conceptual separation between the two with marketing (first term users) and customers (long term users). That makes sense. I must have confused the two as a single man team.

      Serving static site would have been ideal for me too. But where would you serve the redirect of authenticated users to the "app" page - maybe in the frontend javascript? (assuming you have that flow). It'd have been perfect if that reverse proxy served that simple function.

      1. 2

        Cookies can be shared across subdomains -- making it a single Ajax request to the app to decide if you want to redirect the user.

        Fairly lightweight but there's an unwanted delay. You're right, if the reverse proxy can sniff out your authentication cookie and redirect you it's much more seamless.

        I kind of dislike this behavior on most sites (sometimes I want to re-read the pricing page or something but have to do so incognito, because this behavior blocks access to the homepage). Other sites do benefit from the redirect though.

        1. 2

          I see what you mean. I open in incognito all the time to check out their homepage. But that seems to be a standard flow.

          Oh wait. Quick browsing around, sites like Digitalocean, Slack, Google Photos do not automatically redirect. So, redirect is not a must after all.

  2. 2

    I’m using two separate domains, because they are two separate programs.

    WordPress for the website and the actual service I’m selling is build with different scripts/hosted on a different server also.

    It was just easier for me to do it like this.

    Adding the DNS configuration and/or Ssl is a no brainer in this case.

    The actual script where users login to do their business, doesn’t need web indexing by Google, it’s locked by a login form.

    I suppose every website / web app has their own needs etc. Just stating mine. Perhaps Google is doing the same for the exact same reason (convenience), Netflix was able to pull it off with their billion dollar budget and commitment.

    1. 1

      What you are saying makes sense. I guess you're not directing loggedin users from Wordpress to the actual service.

      Whether you want indexing or not seems to play a big factor in deciding to create a separate app or not. Thanks for clarification.

Recommended Posts