Forum Moderators: phranque
Site 1: Portal style
Site 2: Brick and mortar company style
The brick and mortar site doesn't generate much income as a front-end for the brick and mortar company. The reason for this is that there is a second site that is also actively promoting that company. The larger part of all sales is going through that site, which is more optimized for sales. I want to keep that other site as it is, because it is performing well.
There are some parts of both sites I want to merge into a new one.
The forum part of the first site is performing reasonably well. The forum is running on separate forum software which makes it easy to separate it from the rest. As I like the domain name of the site where the forum is running, I can just keep it there.
The static content of the second site is performing well in Google. I think this is mainly because of the clean HTML, informative text, combined with the absence of duplicate content issues. This static content is mainly "evergreen" and does not need much attention. This content is on clean SE friendly URLs and a number of the pages have inbound links pointing to them.
The picture gallery is performing well in Google images and attracts a decent amount of traffic. Main problem is that it is small, and totally hand programmed in HTML files. Adding a new picture to the gallery costs me editing two or three HTML files every time, which is the main reason I am only adding new pictures now and then. I have a picture base of more than 1000 pictures that would be interesting for the gallery, but at the moment it is just too much work.
The on-site widget at the brick and mortar site was once added as something to play with, but it has become the main source of traffic to that site. I want to extend it to a larger size, but I face the same problem as with the picture gallery, i.e. it is fully hand programmed and adding new items to the on-site widget costs me editing two or three files every time.
The news and link parts of the portal site have proven little value and it costs me too much time to keep them current. Google never liked them, but for some reason they rank in Live. They suffer a great amount of duplicate content problems.
Step 1: Removing the CMS system
First of all I want to get rid of the old CMS system on the portal site. I could just upgrade to a new version of the same CMS, but I don't like the system, it is too bulky, too many options I don't need and too difficult to optimze for clean HTML pages with normal SEO optimizations (unique descriptions, no duplicate URLs etc). I also don't want to replace it with another off-the-shelf CMS product. I have tried many and my experience is that I can faster program a small system myself that totally fits my needs, than adapting an existing system and updating it--including my own adaptations--every time when a security fix comes out.
I will delete all link and news items from the portal site. They have no added value for me and for the internet user. All the info is either available from other sources or outdated anyway. When I have done this, only about 100 static content pages are left in the CMS system. These pages provide value, but they rank badly because they mostly consist of thin content, i.e. small pages with contact information of related companies and organizations. This is however information that I don't want to throw away as it costed me time to gather and maintain. I will make a small PHP/MySQL based system to store them. This also gives the possibility to store them in a more structured way. Each info page is now a plain text page in the CMS system. With my own database tables, I can separate information like telephone numbers, zip codes etc in separate fields making maintenance easier.
The new static pages will be on different URLs than in the past, but I will carefully redirect every single old URL to the new URL with a 301 redirect in my httpd.conf.
After these conversions, I can delete the CMS system from my webserver.
Step 2: Moving the picture gallery
The picture gallery on the BaM site is currently hand programmed. I have looked at many existing picture gallery software and there is not one I like. Because I don't want to store much information per picture, I will make on my portal domain a MySQL table containing the picture URL, description etc and write a small front-end to it to retrieve pictures, store new ones and organize them in categories.
I will copy all pictures to the new portal and 301 redirect all picture references from the BaM site to the new portal. For enhanced user performance I will add a "discuss picture" link from all gallery pages to the forum to let people discuss certain pictures.
Step 3: Moving the on-site widget
The on-site widget would be better served if it was based on a database. I will therefore add a database system for this widget to my portal site and make it easy to maintain for me (the bigest problem at the moment). Because the widget is user-interactive and people might want to discuss features, I will add a section in the portal forum about the widget and add appropriate links to that. When the database driven widget is working, I will 301 redirect the old hand written pages on the BaM site to the new location.
Step 4: Moving the static content
After removing the CMS system from the portal, that site is more or less decapitated. Moving the appropriate static content from the BaM to the portal site will give it a complete look again. Of course, all old URLs are 301ed to their new location.
Did I forget anything? Do you think merging two performing parts of two sites and skipping the non-performing parts is a high-way to success or isn't it worth the work and should I try to optimize and clean both sites seperately?
Do you think merging two performing parts of two sites and skipping the non-performing parts is a high-way to success or isn't it worth the work and should I try to optimize and clean both sites seperately?
If both sites draw the same kind of audience, you're probably losing people when they have to go to a completely different site for one of the features, and, all things considered, I'd probably opt for the merger.
OTOH, if the purposes of the sites are so different that they draw completely different audiences, and the content of one would just be confusing to the audience of the other one, I'd probably keep them separate.
The only SEO advantage I've noticed after splitting off a not-very-related part of a large site into its own smaller site is that it seems to have been easier to get incoming links ("seems" because I don't really know the reason for it). The large site is in an intensely loyal niche, which I think makes other sites less likely to link to a site that isn't completely related. So this wouldn't be true for everyone. [ETA: The smaller site is still too new to make any statements about, but it's also picked up a few links from sites that are related to its content that never linked to the combined site.]
[edited by: Beagle at 7:48 pm (utc) on Jan. 22, 2008]
