How to achieve this goal with SEO being a huge factor

[fastsol]

So I currently have my business website that I have spent the last 7 years building and tweaking the heck out of to do exactly what I want.  The site itself works perfectly for me, but I have recently decided to offer a version of the site to other fellow business owners within my industry through a subscription fee.  The desire from other owners to use the site has been great, so I need to figure out how to do a few things.

 

As like most sites are built, mine was not intended to be used by more than one location of business.  I plan to use a slightly more generic domain name for the subscription version so that I can hopefully group everyone on to the one domain and use variables/cookies/sessions to determine what content to show based on the location the customer chooses.  Honestly I have come up with a couple ways to achieve that goal but I don't think any of those ways will allow for SEO for each location subscribed.

 

Here is where I feel that my concept differs from most sites that have multiple locations on one domain.  I sell remote car starters and so would my subscribers.  But the subscribers are all independent business owners themselves across the nation that all do business their own way and have different pricing for their area.  So the main "content" of the sites pages (products page, faq page, contact page) would all be the same across the subscribers but the specific pricing for products and specific contact info would be different per business (all driven by databases).

 

I figured I would make a landing page for first time visitors that don't have a cookie or session stored, where they would choose a location closest to them to browse products from.  That part is simple.  The list would come from a database, no big deal.  The hard part is figuring out how to proceed from that point and redirecting them with some sort of $_GET or session/cookie to keep on their browser but also in a way that google bots can follow and index the business specific info.  Google bots don't carry session or cookies through their crawl, so it would leave me with GET vars only it seems.  Well if I did that, I would have to change a crap ton of code and every link to also have that GET.

This next part I know many of you will say is a bad schema but again without literally changing hundreds of queries through out the site I see no other way.  I would replicate the database for each business so they each can control their own stuff.  Now I would only replicate the necessary parts of the database and create other tables as needed. For example the products db I wouldn't replicate that cause I don't need all the data of each product, but rather a new table that links them and allows certain aspects to be changed for the business at hand, like pricing.  One key point I should mention is that the main database would be the one running my site, all the other databases would be on the same server, so I can connect to them all very easily across domains.

The idea I had with this is that based on the business selected on the landing page, I would set a db var that connects to the db for that business along with having a preset connection to my main site.  So I would basically have 2 db connections through out the site that pull certain info from each db.  Business specific from the one db and common info from the main db.  At this time I don't feel this is a bad idea as I already do it for another site I made for my industry and it works great and functions without a single issue.

 

A big reason I felt replicating the db was "decent" idea is the only other way I know how to achieve this is to replicate the entire file system for each business and use subdomains or sufolders in the url.  Well them I'm really screwed if I have to update a file cause I'd have to update across possibly 100 subfolders.  If I had to update across 100 databases it's not as bad or time consuming.

 

So in the end, how do I go about making this in a way that SEO is just as good as if it was a single location site, but not do it in a way that I have to recode half the files or all the queries that run it?  I'm looking for some good, knowledgeable info here.  Hopefully I have described enough that you can see the challenges I am facing.  Maybe I'm overthinking this whole thing or maybe I am way off base on how to go about it.

 

Here is my site http://remotelystartedmn.com

The domain I would use for subscribers is remotelystarted.com (no mn on the end).

[benanamen]

Before you do anything you might want to secure your server better. You are running an outdated version of Php and your site is vulnerable to a Clickjacking Attack.

[kicken]

I'd go with a solution that identifies the site by domain, either fully or via a sub domain on your generic domain. There's no need to replicate the entire code base for this, just point all domains to the same folder and inspect the $_SERVER['HTTP_HOST'] variable to identify which domain is being used to access the site. You can map that to a configuration file that would store the information about which database to use or whatever other information you need on a per-domain level.

 

$host = $_SERVER['HTTP_HOST'];
$host = preg_replace('/[^a-z0-9.-]/i', '', $host);
$configFile = 'config/' . $host . '.conf';
if (file_exists($configFile)){
    $configuration = json_decode(file_get_contents($configFile));
} else {
    $configuration = []; //Some generic config.
}

This kind of setup would also allow your customers to have their own custom domain name if they want, which you could charge them for if you wanted to. With independent domain names the search engines would view them as independent sites and index them accordingly.

 

If you're going to duplicate the database for each site then I'd consider just duplicating the entire thing rather than trying to duplicate only some of it and run the site with a mix of two different databases.

 

Allowing your users the ability to have some control over the actual product list and not just pricing seems like it could be desirable, but without knowing more about your business and who you're marking this toward I can't say for sure.

 

I also can't speak to much toward SEO as most of the stuff I work on is internal apps where SEO is irrelevant. I know having the same content at multiple URLs is generally a bad thing but having different pricing/contact info may help avoid problems with that.

[fastsol]

I have fixed the clickhjacking issue (I believe) based on recommendations from online sources.  The php version I will look into and verify the implications of updating before proceeding there.

 

Any other suggestions on my original post?

[benanamen]

I have verified you have fixed the Clickjacking.

 

You still need to handle the X-POWERED-BY. I should not even be able to see what version your Php is.

[fastsol]

I have verified you have fixed the Clickjacking.

 

You still need to handle the X-POWERED-BY. I should not even be able to see what version your Php is.

I changed the php.ini for the entire server, so hopefully that has fixed it.  Let me know either way and I can edit the domain specific ini if needed.

[benanamen]

You need to set  expose_php = off  and then restart Apache.

[fastsol]

I forgot to restart Apache. Check it now.

[benanamen]

Still not right. You can check it yourself using this online tool 

 

http://www.webconfs.com/http-header-check.php

[fastsol]

Cool, got it now.  Had to do it on the domain specific ini.

[benanamen]

You said you have been working on the site for the past 7 years. That leads me to believe your code is probably outdated. Are you using Mysqli or PDO? If you're still using the obsolete mysql_* code, then you have even more work to do before you think about implementing your idea.

 

You might want to consider posting your DB schema for us to review. If the DB design is flawed, that would be another thing to take care of before implementing something bigger.

[gizmola]

As like most sites are built, mine was not intended to be used by more than one location of business.  I plan to use a slightly more generic domain name for the subscription version so that I can hopefully group everyone on to the one domain and use variables/cookies/sessions to determine what content to show based on the location the customer chooses.  Honestly I have come up with a couple ways to achieve that goal but I don't think any of those ways will allow for SEO for each location subscribed.

 

Here is where I feel that my concept differs from most sites that have multiple locations on one domain.  I sell remote car starters and so would my subscribers.  But the subscribers are all independent business owners themselves across the nation that all do business their own way and have different pricing for their area.  So the main "content" of the sites pages (products page, faq page, contact page) would all be the same across the subscribers but the specific pricing for products and specific contact info would be different per business (all driven by databases).

 

Here is what is going to happen: anyone looking at a subsite will inevitably start looking at other subsites to do price comparisons. There will be absolutely no way for people to have different pricing based on their version of the site without those that are even remotely web savvy penetrating the veil of segmentation to look at the other vendors you are hosting.

 

 

In my opinion, the way to handle this is as a RESTful SaaS solution. So what you would want to do is provide a REST api that gets the items from your database, along with the pricing factors, inventory etc, that would differentiate one reseller from another.

 

There is quite a lot that you will probably need in order for your database to segment these resellers. So your database and the associated queries are certainly not going to work without these additional selections, and possibly many to many resolvers that relate a reseller (and their associated geography) with their view of the world.

 

With REST you could then provide a basic version of the site, with templates, style sheets, etc, that could then be easily embedded in a customer's existing site, or provided as a standalone site. This could be a separate product from the base REST api access.

 

I think it's a bit naive to assume that you will be able to repurpose your existing site and its codebase into a SaaS solution, although even the business model for how this makes sense for you monetarily isn't clear. Will you be getting a cut of sales? Will you be charging purely for the hosting of the system? There are many different ways you might be planning to monetize your business.

 

This question is too large and open ended to be answered here in anything but vague generality. It's really not what this community exists to do -- we are more focused on specific questions about php, database and web development, and the scope of your question is too general and business specific.

[benanamen]

* Partial Quote

 

There is quite a lot that you will probably need in order for your database to segment these resellers.

 

I think it's a bit naive to assume that you will be able to repurpose your existing site and its codebase into a SaaS solution, ......

This question is too large and open ended to be answered here in anything but vague generality. It's really not what this community exists to do -- we are more focused on specific questions about php, database and web development, and the scope of your question is too general and business specific.

 

I agree with @gizmola. You are not going to be able to re-purpose your existing site and scale it. You need to "blueprint" the whole thing out before you even write a single line of code. Doing an Enterprise level application is a whole lot different than doing a single site/company app. Right now, you don't know what you don't know.