In order to have an SEO friendly site, and follow the modular design concepts I recommend, it is easiest to build your sites with content you have put into database format. Databases provide ease of searching, sorting and use, plus provide for convenient re-usability and more flexible updating.
If at all practical, put all of your content into a database. Use as many different fields and tables as possible when constructing the database, so that you have the option of using parts of the information in a different manner on another site. This makes the design of the site slightly more complex, but it is more than compensated for by the benefits we describe here.
For example, suppose you are building a site on how to make great pizza. You have forty or fifty pizza recipes. You could create a table called recipes with three fields: recipe number, title, text.
But recipes typically consist of two parts, the list of ingredients, and the procedural description. It is better to put those in two separate fields, in case you want to use them separately in the future. The description also usually includes a phrase such as ’serves 8′ or ‘8 servings’. You might want to put that in a separate field as well, where you simply save the number 8 in a field called servings.
Then, at some future date, you decide to put up a site on dieting. With a simple script, you can convert your list of ingredients and number of servings to show the number of calories per serving for these pizzas, which you can easily add to your dieting site.
If your network is about food, you might want to break it down even further and put each ingredient in a separate table, each list of ingredients (actually just references to the first table) plus quantities in a second table, then names and descriptions in a third with a counter field that gives the second table a reference for its list of ingredients. Then you will be able to allow users to search for recipes by ingredient as well as name.
This is an example of linked tables within a database — a very efficient and practical form of data storage. Table one (Ingredients) has just two fields, reference #, ingredient name. Table two [Ingredient-List] has three fields, recipe # [from table 3], ingredient # [from table 1] and quantity. Table 3 [Recipes] has four fields recipe #, name, description and servings.
Later you decide to get fancy, and add a pop-up description for each ingredient when the mouse hovers over it in the list of ingredients for a recipe. It is easily done by adding a ‘description’ field to the Ingredients table. Had you put recipes in a single table, that change would not be so easy.
When you build a Web Empire with inter-related topics, you never know when one part of a database might be useful on another site, or when you might want to add functionality to some part of the data, so split the data as fine as is practical.
Database information is always useful. Remember, you can use multiple databases (stored in different tables or retrieved dynamically from another of your sites). Your main content may be unique to the site, while another site can be cannibalized for data by extracting part of its database just to fill a side-bar or be included inside other content just as you would a photograph. By randomizing the retrieval of some of the database content, you can provide dynamically changing content within your page, which makes it more ‘fresh’ too, for both your readers and search engine spiders. In our next post we will show you how to control the update frequency of randomized elements using PHP.