It has been 5 days now since I posted anything to DerekBeau.com, a sharp contrast to the way I started off the blog

I was in the process of purchasing a large website that was going to be used as a case study follow-up series to my post on buying website to increase income. To make a long story short, I did not end up acquiring the website. What I did do was waste a lot of money on escrow fees and learn a valuable lesson: make sure you know everything that is involved with managing a website before you commit to purchasing it.

I won’t disclose the name or price of this website, but I will discuss the reasons why I decided to cancel the transaction. Hopefully you can learn something from my recent experience as well.

Complicated Hosting Arrangement

The first thing that alarmed me about this website was the hosting situation. It was utilizing 6 dedicated servers (4 different Linux distros), none of which had any server administration package installed (such as Plesk, cPanel, H-Sphere, etc). Everything was set up using low level Linux commands. This is all fine and well if you are a Linux guru or want to pay a server admin ridiculous hourly rates to do everything for you, but it wasn’t alright for me.

I asked the hosting company and a recommended server admin if it would be possible to upgrade and transition this site to an updated and easier to manage system. They both had the same response: it would be possible but difficult. The only way to do it would be to make a backup of the website, wipe the servers clean, and reinstall everything. That process would have been harder than usual because of the following problem…

No Meaningful File Structure In The Back-End

When I received access to the servers, I could not seem to figure out where the main files for the site were stored. I wanted to make some simple changes to test things out, but could only find files that were left over from years ago. There were copies of files everywhere, numerous “test” files, and plenty of outdated files.

When I finally did find the “live” files, I was shocked to find out that there was no organization. All of the files (except for downloadable content and server-generated pages) were stored in the main directory. All of this made for a very confusing setup, and caused problems when combined with the next problem…

Extremely Poor & Antiquated Coding

The actual coding itself wasn’t the main problem. Sure, the site made use of tables rather than a table-less design, but that is to be expected from a site that hasn’t been redesigned in years. The main problem was with how everything was programmed to run.

In order to add new content, you had to use a very plain, yet complicated, form. To use it correctly, you needed to know which fields to fill in and which fields to leave blank, depending on what type of content you were adding. After adding content to the database, you had a run a script that would rebuild all of the pages on the site.

To edit any of the content, you had to modify the database directly. This was extra difficult because there were no database admin packages installed (like phpMyAdmin), it had to be done via SSH with Linux commands. After you modified your entry, you had run the rebuild script again.

To delete content, you had to again manually edit the database. After doing that, you had to find the uploaded content and the generated pages so that you could delete them manually.

The Straw That Broke The Camel’s Back

The last straw, for me, was when the seller was attempting to clean up all of the clutter on the servers (old files, test files, etc) and accidentally broke an element on the website. It took over 30 minutes for him to diagnose and fix the problem. This never would have happened if the site had be structured and programmed properly, and I didn’t want to spend a small fortune on a website that could be broken so easily.

With that being said, the system in place obviously worked for the seller. He had created a very popular website that was a great asset. You can’t expect everyone to follow the same standards and conventions as you when they build websites, and that was my biggest error in this transaction. I could have accepted many different circumstances, but not the drastic differences that were present here.

Although this post is a [lengthy] explanation as to why I haven’t been posting lately, it should also help you come up with additional questions to ask a seller before committing to buying their website. Had I asked specific details about the server setup, what server administration software they were using, how their site files were organized, how the site was managed, etc., this whole ordeal could have been avoided.

You should also make sure you have the expertise and/or resources to maintain a prospective website’s quality. This could include tasks such as maintaining (and growing) the community, producing a stead stream of quality content, maintaining traffic relationships, maintaining search engine rankings, or any number of other similar tasks.