Opinions vary on what constitutes “web site architecture”. You’ll find a variety of definitions for ‘web site architecture’ if you look for them. You can also look at the definitions for ‘architecture’ and see there is little general agreement.
In my point of view, Web site architecture encompasses both intrapage and interpage elements. The architecture of the Web site include the pages that comprise its content, the relationships between those pages, and the organization of the pages themselves. Let’s start with simple page architecture.
A typical Web page can usually be logically or visually subdivided into five zones: four margins and a body. The page structure or architecture, however, may only stipulate two margins and a body or one margin and a body. Some pages (especially on older sites) have only a body. A page margin is an area within a page that contains content separate and distinct from the main body copy.
If you use templates that impose white space down the right and left side of the page, that white space does not constitute your logical page margins. That is, the white space is like a place mat on which you’ve overlaid your logical page. So it’s really the content that is subdivided into zones, not the page that is subdivided. The distinction may seem arbitrary but there is a madness to my system.
In addition to zones a Web page also has fluidity. Pages are fluid if and only if their visible elements rearrange themselves when you change the browser window dimensions. It is better for pages to be fluid than for them to be rigid. Rigid pages are usually designed to specific screen resolutions and browser window dimensions. In search engine optimization, choosing a rigid or fluid page design heavily influences your flexibility with on-page elements.
Most Web developers today confuse screen resolution with browser screen space. You cannot afford to design pages on the basis of screen resolutions. That is, assuming that a 1024×768 screen layout works best because most people use that resolution is wrong, not because of the space the browser frame takes up but because you don’t know if the browser window is maximized.
Your page’s fluidity is part of its architecture, and the less fluid your page is, the less likely your architecture is going to help anyone. If you want to know just how crude and ineffective your beautiful page layout is, use a cell phone to look at your Web site. It won’t be pretty. And don’t naively assume that people use their cell phones to look only at mobile-friendly content. THEY DON’T.
A lot of people have also spun their wheels in the meaningless “CSS versus tables” debate. I only bring that up to point that tables can be used to create fluidity. They also can be (and usually are) so misused as to make them perfectly useless in a live Web site. But you should create a table-based template structure that you study (just keep it on your computer). Look at how the data moves around the screen as you change resolutions with maximized browser windows and how it moves around the screen as you change the browser window size.
There is a great deal more to be said about intrapage architectural issues but I think that will have to wait for next week.
Let’s move on to interpage concepts.
There are five ways to navigate a site from within:
- Your “navigation menu”
- Your HTML Sitemap page
- Cross-promotional margin links
- Links embedded in copy
- Site search
Most Web site designs fail to achieve even basic optimization for the navigational menu links. A lot of sites actually do better with cross-promotional margin links and links embedded in copy.
Your internal link anchor text is more important than your external link anchor text if only because it helps your visitors understand what is on the other side of the link. Which link works better, this link or this link to the SEO glossary page on SEO Theory? Both links lead to the same page.
People like Matt Cutts use misleading link anchor text in order NOT to pass relevant value to other sites. You can use lazy anchor text to pass irrelevant value within your site or you can use active anchor text to accurately or at least adequately describe the page you’re linking to.
The next time you’re tempted to use “here” as your link anchor text, ask yourself how easily understood your page would be if it showed up in a search result for the word “here”. Not that you’re likely to improve your page’s ranking for that word, but you’re still boosting its relevance for “here”.
Beyond that, you really don’t need to worry much about “site architecture”. Oh, sure, people like to organize large collections of pages into folders (also called directories). You know what? That has absolutely nothing to do with search engine optimization.
Now, it’s true that you can stuff keywords into page names by inserting folders into a page location. But some people agonize over how “deep” content is. But there is really no such thing as “deep” content. Content is only as deep as the number of clicks it takes to find it. If you feel you have too many clicks to your content, add a link somewhere.
Your goal with site architecture needs to be to get people from point A to point B. Point A is their entry page and point B is their conversion page. Don’t be naive and assume that everyone who is going to convert will come into your site through page B. If you have two pages you need to make sure people can get to their conversion point through either page.
If you have 1,000 pages you still need to make sure people can get to their conversion point from any page.
On a 1,000 page Web site you have no excuse if it takes more than 3 clicks to get to any page from your root URL. And if you can get to any page within 3 clicks from your root URL, you should be able to get to any page from any other page within 3 clicks.
Click 1: Go to the HTML Sitemap page
Click 2: Go to the destination page or a page that leads to the destination page
Click 3: Go to the destination page from the intermerdiary page
If you include a site search tool, you should be able to reach any page within 2 clicks (just don’t use Google for your site search).
Some people believe in the value of “theming”. That is, they’ll designate one part of a site to handle content theme 1 and another part of the site to handle content theme 2. Without getting into the pros and cons of theming, all I have to say is that has absolutely nothing to do with site architecture. In a multitheme site you should still be able to offer people an HTML Sitemap and/or a site search.
Your intermediary pages will tend to be your section header or folder index pages but they don’t have to be. You can create miniature directories that index logical portions of your site. Think of them as specialized portals that help people find a lot of related content across different section types. Suppose you sell books, posters, CDs, and DvDs. If you create a Stargate portal for your Stargate-related items, you help your visitors.
Major retailers actually do this with their eCommerce sites.
Newspapers do this with their news stories.
Online magazines do it too.
A lot of large content sites create user-friendly portals for very popular content. You don’t have to wait to see which content is popular. You have the option of deciding which content will become popular.
There are other things you can do and I’ll come back to this topic next week.
{ 0 comments… add one now }
You must log in to post a comment.