September 20, 2019

What's the best strategy to reach X monthly visitors?

What's better?

  1. Multiple niche websites
  2. One website that expands its topics in time.

For example:

  1. One website for paleo diet, one for keto, and one for vegan diet
  2. One that starts with paleo, then adds keto and, after a while, vegan

The example is random, I am not interested in starting a nutrition website.

I think the first and I suppose that it is better for monetization too, but I wanted to hear your opinions.

  1. 2

    Multiple niche websites will give you more flexibility, but a single website would have greater SEO and brand recognition benefits.

    My vote would be separate, niche websites, but all subdomains of the same umbrella domain (if possible). And something to tie the brands together if possible as well.

    1. 1

      Thanks for your suggestions and your time.

      For subdomains, I suppose that you mean something like keto.domain.com, paleo.domain.com and so on.

      I was thinking in different website but basically the same brand. Like you said, a tie between brands. To give you an example, like Amazon does with audible, aws and so on. Or looking to more down to earth brands, sumo with sumo.com, appsumo.com etc.

      What do you think about it?

      1. 2

        Yeah that's what I mean by subdomains. I think if you're talking about nutrition websites that are similar but for different niches, the subdomains are the way to go.

        If you're thinking about several more-or-less unrelated (or only loosely related) businesses, then you'd probably want to build them one at a time anyway and let the brands evolve organically.

        Amazon didn't have (or plan to have) AWS when they started, and they bought Audible. They were able to merge those brands into their own when the time came, without explicitly planning for them. In the beginning, they just focused on Amazon.

        Same for Sumo, I assume. I don't know that much about them. But they probably didn't launch all of those businesses at the same time.

        1. 1

          This is a really interesting strategy. To be honest with you, I never thought about it, but makes a lot of sense and I will probably follow it.

          The last question... Why do you prefer a subdomain over a subfolder for each different category?

          1. 2

            Nice 👍

            Subdomains are completely separate sites, so they can be updated independently, hosted in different places, etc. They'd be more flexible if, for example, you wanted a unique section or feature on keto.domain.com and not paleo.domain.com. Or if you decided to convert just one of them to a Shopify ecommerce site or something.

            If you want them all to be consistent, there are probably more benefits to a subfolder approach.

            One of my businesses, Really Simple Store, has 7 subdomains (shop. / account. / cart. / orders. / etc), which are 7 distinct web apps. They all look the same, and my customers might not even notice the subdomains changing, but it gives me a lot of flexibility to work on different parts, and if I want to upgrade to a new codebase or platform, I can do each section individually instead of the entire complex app at once. That's more extreme than most people go, I think, but that's my preference... flexibility and quick changes/updates with a low risk of breaking other parts of the app.

            1. 2

              Thanks, you have been very helpful. I will ponder about the pro and cons of subdomains and subfolders. Thanks again.

            2. 1

              Drew I like the sound of this. It sounds to me like they are almost like micro services in that each element is independently deployable. However I'm curious to know how you pass data from each part of the site to the other?

              1. 1

                Great question. One of the subdomains is an API. That holds all of the data and makes it available to all the other apps. Each of them is basically a "front end" for different parts of the data, and they always use the universal API (none of them store their own, separate data).

                1. 1

                  Very interesting and clever. I wouldn't mind learning more about that. Have you blogged about it anywhere?

                  1. 1

                    I've been meaning to write about it but haven't yet.

                    This is good motivation to. I'll comment back here with a link when I do.