2

We run a website to provide cashback for forex traders from all over the world. Now, we'd like to add new services to our portfolio, such as cashback for poker, binary options and lots of online services.

Let me explain the current situation for you.

  • We have great position in Google, our average position is 2.4. This is a huge factor for us.
  • Our domain is _forex_cashbackcloud.com. So our domain is really specific for the forex field.
  • We have separate 10-15 emails for every domain (counting aliases). We pay for Google Apps to manage them.
  • We have a special loyalty program, where the more you use our service (which usually means you trade more), the more we pay you back.
  • We have a referral program where users can refer their friends to our site for money.
  • We are on Symfony 2.3, using Doctrine ORM.
  • Our site is translated to 3 languages right now and we're adding 2 more in the near future.
  • Our server environment runs Nginx.

The problem

Right now, we are facing a difficult decision. Should we open a completely new site and make everything there, under one roof. Or, should we open new sites for every field we'd like to be able to give cashback. Here are my concerns.

  • As we are opening for other fields, like online casinos our domain can't be the one we use now, because it's too specific. However we really don't want to lose our SEO ranking for the current field.

  • We don't want to make users have to log in for separate sites. We'd like a single gate, where they can reach their profile

  • We don't want to copy and past our code base. If we do it once, it could be working. However, for the third and forth time it could get messy and hard to maintain.

  • Our users have one account right now. They collect their 'virtual cash' on their balance until they reach our withdraw limit and they can withdraw their money. People who trades on forex may use our services on other fields like online casinos. So, they want to collect their money on one single account.

  • Administration and support. If we lots of domains we should have separate email addresses for these sites. That could be real pain in the *ss.

  • To make the matter worse, our current users have to get access to our new sites and of course our new users have to access any other fields too. So, we kinda need a shared database for it. Plus, users must be able to log in to their profile with single-sign-on, we cannot ask them to log in separately for every site.

  • We need to consider SEO in every decision we make. It's a huge factor for us, so we cannot leave it out of the equation.

  • We have lots of pages which will be the same on every site. Obviously, we don't want to manage these pages separately. (Lots of them are static pages like terms of service, privacy policies, about pages and so on) Plus, it could count as duplicated content in a Google bot's eyes and we could easily get punished for that.

  • We'd like our referral to work with any sites, on any fields. For example, a poker player can refer a forex trader and vice versa.

  • We run Symfony 2.3, which works great for us, and we don't wanna change it.

I was thinking of a good example here, and I found out Envato does kinda the same. They have lots of domains (www.themeforest.net , www.codecanyon.net , etc.). They have a single sign on and single userbase. However, they have separate balance, and referral programs. But they manage domains extraordinarily well and they change them flawlessly as I navigate on the site.

Another good example is Stack Exchange with Stackoverflow. :) It possibly has the same code base for every site, it does kinda the same for every field and it runs on multiple domains, and/or subdomains of Stack Exchange.

All in all, my question is that is there a best practice in this? Or some good examples which you can share with me? Or does anyone has experience with these kind of problem. I'd really appreciate the help and thank you very much for it in advance.

The possibilities are the following:

  • one completely new domain (we may lose all seo ranking, easier to maintain, low seo synergy, have one codebase)
  • multiple domains with one distributing site like Envato (get to keep our seo rankings, harder to maintain?, lots of emails, duplicated content possibility, higher costs)
  • one domain and multiple subdomains (kinda the same as multiple domains I think. I don't know too much about seo and maintainability in the case.)

I know that there is no silver bullet in the case, but I'd be really interested in your opinions. Also, I'd be thrilled if you can toss me some examples how to execute these kind of things in Symfony2.

Cheers.

ps.: This question was firstly asked on StackOverflow. They sent me here, they said I'll be in good hands here. :)

UPDATE 1.0

Hi guys, a quick update on the solution here. Right now we're in the middle of a big transition to the new site. We have made a lots of difficult decisions to get here. All in all, we went with the "multiple domains" approach because we didn't want to lose any SEO traffic.

But what about maintainability? I think we figured out something to solve this. We created a CommonBundle in Symfony 2.3 where we store all of our main, common functionality. It's a separate bundle with a separate namespace, including our User managing Controllers, main Model classes and all the common views which could be used for all the sites.

We'll use one database with prefixes. I'm not sure here, that this is the best solution, but it's obviously the easiest option for now.

To create the actual multisite in Symfony, we used a solution from here. It seems to be working, but I'll get back to you when we know more.

2

One option could be to create a new website for all of the fields, which is easier to maintain, has the same user base, etc.

You could use a 301 redirect to redirect people from your current domain to the new one, keeping most of your page rankings.

One post I read online had this to say about 301 redirects:

A 301 redirect is a permanent redirect which passes between 90-99% of link juice (ranking power) to the redirected page.

So your referrals, login, user base, and website are all easier to manage, and you can keep most of your rankings.

  • 1
    Thanks for your help! This obviously is one way to do this. However, domains play huge role in SEO rankings and if we do not include the field specific keyword in our domain we might lose lots of traffic. (And as you mentioned we kinda lose some amount with the redirect too) I think we're going with the multiple domain method, but we don't know the specifics yet. – omgitsdrobinoha Jul 8 '15 at 14:33
1

Well, you can try a variety of different approaches here, as you stated.

  • one completely new domain (we may lose all seo ranking, easier to maintain, low seo synergy, have one codebase).

In this case, you are going to lose seo ranking, but... as future perspective, new domain and redesigning everything / building from scratch is (from my perspective) a best way to do something big like this. I'd go with this solution because, SEO is not so much important part at the point of such a big makeover. You can do it at the end, if the page was good, rankings will always be good. And the most important thing is that CODEBASE is going to be easier to maintain. I'd go with this approach.

  • multiple domains with one distributing site like Envato (get to keep our seo rankings, harder to maintain?, lots of emails, duplicated content possibility, higher costs)

Ok, in this approach, you are going to keep bunch of old stuff from old codebase, all the emails, with the time it's going to be hard to maintain, and it's not a problem in content that it's going to be duplicated, it'll all be upside down.

  • one domain and multiple subdomains (kinda the same as multiple domains I think. I don't know too much about seo and maintainability in the case.)

This is also a great way of doing things. Separation of concern in this case is great. You can add one subdomain to one team or guy to maintain it. And it's much more easier to do stuff and separate concerns.

So, to draw a conclusion, pick first or third approach, don't pick second approach because it's going to get lot harder by the time to do stuff around.

  • 1
    Thanks for this. I also updated my question with the current situation. Just a heads up: we went with the 2nd approach, but I think we managed to make it quite easily maintainable. :) – omgitsdrobinoha Oct 7 '15 at 10:44
1

One domain and multiple subdomains (kinda the same as multiple domains I think. I don't know too much about seo and maintainability in the case.

This is the best way. I've tried it and it's still up and running.

  • Why do you suggest this? How does this solve the problem? Can you point to any resources? – Andrew Lott Oct 6 '15 at 9:07
  • As far as I know, From SEO perspective one domain with multiple subdomains is the same as separate domains. Why would it be better than keeping the original domain? Do you have an example? – omgitsdrobinoha Oct 7 '15 at 10:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.