Best SEO Blog|Launch your site.

People in the SEO community talk about Website structure and architecture but we don’t really define it very well. In fact, one must ask if there really is a difference between Web site structure and Web site architecture. I think we can provide distinct contexts for both.

However, let me begin by suggesting that Web site structure is really a part Web site architecture, which is concerned not only with structure but also materials or components.

For example, Web site content can be served as static pages or dynamic pages (or both). However, we use the word dynamic loosely, as it can have several relevant uses. For example, a transactional page that only exists one time (such as a confirmation of a purchase completion) is a dynamic page. But a database-driven site that builds all its pages as they are requested also serves dynamic pages.

So, to help clarify these different types of content, let’s speak of static pages, persistent dynamic pages (aka virtual pages), and transactional dynamic pages (aka temporary pages). Static pages are stored in their own individual files (usually the file names end with extensions like “.htm”, “.html”, “.shtm”, “.shtml”, etc.). Persistent dynamic pages are stored in a database (like MySQL) but they generally don’t change their content or appearance. You see the same pages over and over, but they are really virtual pages. Transactional dynamic pages only exist once and they are tied to specific transactions. These are temporary pages.

These definitions, I think, fall into the Web site architecture category because they provide a framework of atomic components from which a Web site may be built.

We can speak of static sites, dynamic sites, and hybrid sites. In a static site all the content is served from static files (although you can allow for server side inclusion of on-page elements, even if they are loaded from a database). In a dynamic site, the pages are constructed by an application (like a Perl or PHP script). The data for the pages may or may not come from a database (it could be stored in a set of text files).

In my view, these are still architectural issues.

You get into the sub-category of Web site structure as you begin to assemble your components into an ordered group. By that, I mean you decide whether you’ll have folders (directories), whether you’ll put more than one file into a folder (directory), and how you’ll interlink your pages (navigation).

Page arrangement and distribution are thus the first order of business in establishing a Web site structure. Today most people install some sort of content management system (CMS) to handle these basic design decisions. The CMS creates folders, assigns pages to them, and keeps a map of everything’s location.

You can use a CMS to serve either static or dynamic content, and many CMS installations do in fact serve both types of content.

Going deeper into the structure issue, most sites are developed according to a tiered hierarchy. That is, you place a minimal amount of content pages in your root folder and you build sub-folders there that contain other content. Each sub-folder should logically define a distinct topic within the Web site. For example, your “About …” section could include a company profile, an executive biography page (or several), a mission statement, and other incidental pages. Your products would logically comprise another topic or section that deserves its own sub-folder.

And each sub-folder could potentially be further sub-divided. Don’t be afraid to do this. Don’t agonize over how far away from the root URL any particular folder or page is. That’s amateurish search optimization because, frankly, it doesn’t matter how many folders deep your content goes. All that matters is how many clicks it takes anyone (or any robot) to reach the content. Folder depth does NOT equal click depth.

It is generally a good idea NOT to include more 10-15 pages in a folder. It is generally a good idea to store your images in their own folder or folders. In fact, you may want to consider storing your images in a separate domain or sub-domain.

Now, speaking of sub-domains, some sites divide their content into distinct sub-domains. This is advisable when your content sections are distinct enough from each other to have separate needs. For example, if your site features an image gallery, it may need a different type of CMS than the blog your site includes. You could put one or both types of content on a sub-domain — or in sub-folders, as some people do that.

I would use a sub-domain strategy where I felt confident of building a distinct brand value for the sub-domain. If I didn’t feel the content justified its own branding strategy, then I would prefer to use a sub-folder.

You don’t have to use a tiered structure, but if you have more than 9-12 pages on your site you’ll either create a very awkward site structure or you’ll create a virtual hierarchy, in which all your files are located in one folder but your navigation system breaks the pages up into groups or categories.

Web site navigation does NOT have to exactly match the physical structures you use to organize your source files. However, if you use one structural paradigm for your navigation and another structural paradigm for your page addresses (the URLs include all folder names), you may confuse yourself or your visitors. Consistency between navigation and page location helps if you can achieve it, but on larger sites that is not always a realistic goal.

The larger your site becomes, the more likely you’ll have to devise more than one navigation system for it. You can organize your navigation in tiers or layers. You should NEVER attempt to include all your navigation in one menu, one style sheet, or one include. Each level of navigation should be limited to no more than 10-15 options. People can only easily comprehend about 10-12 objects in a group at a time.

If you have enough content that you create navigation systems for each section, those navigation systems should also include at least one option for returning to the root page of the site. In some site designs you can get away with keeping the top-level navigation bar on every page and just adding a second-level navigation bar below or beside it that is customized for each section.

If your system embeds more than 25-30 navigational links on a page, that is too many.

You don’t have to limit yourself to a primary navigation mechanism. For example, you want to include a site search tool on every page of a large site. But you can go beyond that by adding specialized navigation blocks.

For example, on a site that archives articles you can include “Related articles” in your footers.

On a site that manages an image gallery you can include different links to different navigational views of the same image groups (or you can link to “Related images”, “Similar images”, etc.). A navigational view is an alternate format for basically the same set of documents. Although most sites don’t employ multiple navigational views in their structures, some sites do. The best-known examples of multiple navigational views include footer or margin links that replicate the primary navigation menu (often embedded in image maps, Flash menu bars, and other non-crawlable objects).

There should be no harm in using multiple navigation views as long as they benefit your visitors. You can use alternate navigation blocks, mechanisms, or views to organize your data in a very different way from your primary site. Think of a site that features profiles of cars. The main site could organize the profiles by region and manufacturer; an alternative site (a sub-domain, for example) could organize the profiles by type of car and year.

I would be careful not to create fluff secondary navigation systems. I would make them distinct by associating each navigation system with unique content to provide value to the user.

I would not include such things as page layouts, styles, color schemes, and embedded objects in Web site structure and architecture. These concepts fall under presentation design rather than structural design.