At its Create the Web event in San Francisco, Adobe CTO Kevin Lynch revealed the company’s bid to help build the future of the Web – Edge Tools and Services. The new tools take all of Adobe’s previous efforts in HTML5 development, and combines them with brand new tools that will help creative and technical minds alike create Web sites.

Edge Tools and Services includes the following software:

Edge Reflow was only shown in preview form today and will be available for general preview later this year. The rest of the software, including Edge Animate, Inspect, PhoneGap Build and WebFonts will be available today. Edge Code will also be available, but it’s still in preview.

“We are excited to put a powerful new set of HTML5 tools into the hands of web designers and developers and can’t wait to experience the beautiful websites, digital content and mobile apps they’ll create,” said Danny Winokur, vice president and general manager, interactive development at Adobe. “We are passionate about enabling creative people to do anything they can imagine with web technologies, which is why we’re contributing to the web platform and making the Edge Tools & Services available for free, including the first release of Edge Animate.”

Adobe hopes that these new tools will help developers and creators alike innovate the Web, including four key areas: layout, foundational graphics, cinematic visual effects, and typography. These four areas are central to the evolution of the Web by making it more expressive.

To help get people started, Adobe will be giving away Edge Animate in Creative Cloud for free starting today. After the introductory period, it will go back up to its normal $499 perpetual license price. Those who don’t have that kind of money laying around can opt for the much cheaper $14.99 per month licensing fee.

Those looking for the best bang for their buck, Adobe will be offering all of its new Edge Tools alongside CS6 in its Creative Cloud membership. It’s $49.99 a month under an annual contract.

It’s not quite there yet, but the future of the Internet is going to the Web. HTML5 is heralded as what’s leading the charge to this brave new future. Adobe wants a part of that, and the company’s new Edge tools helps get a foot in the door near the beginning. Now it’s up to designers and developers to create the future.

The main hook of the LinkedIn iPad app is its “stream” for infinite content scrolling. This will allow users to have an “engaging content consumption experience.” The only problem with this approach is that mobile devices are not exactly the best when it comes to memory which an infinite scrolling list requires a lot of.

To circumvent the lack of large pools of memory, the team went the extra mile by building their own solution to this problem. They could have used Apple’s solution that would have allowed for infinite scrolling, but the LinkedIn team apparently wanted the challenge of building their own in HTML5 which currently lacked such a technology. In the end, they obviously succeeded, but they also helped HTML5 developers everywhere by proving it could be done.

The first technique in streaming large images via HTML5 was to replace the src attribute of the img tag with a small image when it was moved off screen. This allowed the large images to be displayed on screen while saving memory when said images were moved off screen.

It turns out that making the images small didn’t save enough memory in the long run. To combat this, they bagan to hide pages so that they wouldn’t take up memory as well. They did this by setting the CSS visibility property of a page to hidden. This allowed more memory to be freed up as well as the app running smoother because the browser didn’t have to keep the invisible pages up.

Apparently those first two techniques helped sove 80 percent of crashes. To help solve crashes for the other 20 percent, the team started to remove pages altogether. They only removed pages that were not required and replaced them with an empty page of equal height and width called a “stub.”

All of this led to them creating a stream that would have the current page loaded with all images visible with the previous and next pages being fully loaded as well. After that, the second previous and next would be loaded up but didn’t have any images. The next after that would be an invisible page. Once it had gone beyond that, the pages would removed. It’s an ingenious method of keeping infinite scrolling in place without having to sacrifice anything.

Now that they had this method in place, they only had to start working on improving the performance of the app. They helped this along by adding in some HTML/CSS optimizations. The first is to avoid client side image scaling. To avoid that, simply specify the width and height attributes of an image in HTML tags. The second is to simply not use CSS box shadow as it has a negative effect on performance.

All of this work helped keep the app running, but they were still running into crashes now and again. To keep it perfectly stable, they would have to keep the DOM nodes to a minimum. Remember those stub nodes that replaced far off pages in the stream? They were able to combine those stubs into a single dummy node to prevent the app from crashing.

For those who learn better with visual examples, here’s a video of the LinkedIn team showing off how the DOM changes when a user moves through the stream. Check it out to see some awesome HTML5 magic.

To combat this and maybe even help sites optimize their code and content, the company has published an HTML and CSS style guide. It contains the standards that their own developers and programmers adhere to. While your company of choice may use a different style guide, Google offers up their own for those who may not have one yet.

Most of the style guide deals with formatting and its implications on the code you write. The style guide, however, also contains best practices to encourage better coding etiquette. Google also says that they find style guide authors arguing over whether code should be descriptive or prescriptive. Google takes an approach that includes both so that the code can retain some stability, but allow developers to express themselves more openly through their code.

The HTML and CSS style guide is just another in a long line of style guides published by Google. They have previously released style guides for C++, Objective-C, Python, JavaScript and an XML document format style guide.

The wealth of information contained in the style guide might not be surprising to code masters, but it should be incredibly helpful to those just starting to learn code or amateurs who might need some guidance on standards. It’s also just interesting to see what Google views as good style when it comes to HTML.

You can check out the HTML and CSS style guide here. You should definitely check it out. You won’t be disappointed and you might even learn something. You might even rise to the rank of a mighty street coder one day.

It looks like it’s a five step program, so get ready to be rehabilitated folks. If you’re tech savvy it should be a no-brained, but if you’re are somewhat impaired you may need to buy the study guide. Either way, take a look at this thing, it may actually come in handy and help you solve a couple issues in the future.

Enjoy:

On the Mozilla Hacks blog, HTML5 evangelist Chris Hellmann shows off click highlighting and how it can be easily created using Javascript. If you’re new to click highlighting, it’s essentially the generation of a brightly colored dot that appears when you click. The longer you hold in the mouse button, the larger the dot becomes.

If you hold in the mouse button and move it around, the dot moves around with the mouse. This can be done with a little JavaScript magic where you generate a DIV element and move it with the mouse. Hellmann details the code for easy implementation:

The growing of the dot doesn’t use JavaScript, but rather CSS transitions. This is done by changing the scale of the dot from 0,0 to 1,1. Here’s the code for dot growth:

Hellmann says that it would be nice if they could keep everything in CSS, but that it’s impossible in some browsers. For those browsers, there is a method for changing CSS to JavaScript. It’s achieved through Clickhighlight.js with the source code currently available through Github.

Here’s a video demo of the application if you need more of a visual element for learning. Hellmann says that he envisions adding touch support and turning this into a bookmark tool. What other uses can you see for click highlighting? Let us know in the comments.

Gamzee is a small game development company focused on social games for Facebook and the Web. They saw a problem they didn’t like. Facebook games like CityVille weren’t truly cross platform. You couldn’t check on your city from Facebook on your phone. HTML5 can make that happen and that’s what Gamzee did.

Their game is called Skyscraper City and it’s a “city building game that combines the gameplay of social builders with the fun of Lego-style blocks. You can stack almost any city unit on top of any other to build towers, elaborate structures, or whatever you want.”

Sean Soria of Gamzee comes out of the experience of building a game via HTML5 with only one clear observation – HTML5 game development is hard. The good news is that they learned a lot about the process and want to share the information with the rest of the game development community.

The first thing to consider, like with any game, is the platform. HTML5 allows you to make games cross platform with any device that can render HTML5 elements. This includes PCs, smartphones and tablets that are running the necessary browsers. Gamzee took that to mean that their game would played mostly on PC with the mobile version serving as back up. Makes perfect sense, but gamers never make sense. They found that the majority of players were using their mobile devices as the primary platform. First lesson is to spend a great deal more time on the mobile version of your game, maybe even make it the primary platform.

The second lesson is in regards to the application you use to render your game. Much of the noise surrounding visual rendering in HTML5 has been for Canvas and for good reason, it’s powerful enough to render complex animations and even in browser video chat. Unfortunately, it turned out that Canvas doesn’t run very well on older iPhones. The key here is to make new rendering engines until you find one that fits.

As Mozilla has pointed out, audio still sucks when it comes to HTML5. Gamzee found it to be no different. They compromised by including sound and music for the desktop version while only having music in the mobile version.

The rest of the advice is all about designing for the mobile experience. If you truly want to be cross platform, you’re going to have to make sacrifices for the mobile versions. Smartphones still aren’t as powerful as a computer so there are going to be cuts. The issue is that you want to keep the experience largely the same across both platforms. They did this by limiting the size of the play area in both versions to make sure the mobile version would work. They also found that CSS makes up about 50 percent of all cross platform game development.

In short, this is what Gamzee learned from the experience. I suggest any aspiring developers take this to heart if they’re interested in HTML5 development.

We validated that you can make a cool, rich isometric game in HTML5 and have it be cross-platform.

We learned that if people can play a game on any device, a lot of them are going to do it primarily on mobile or tablet.

We learned that HTML5 cross-platform games require a lot of experimentation.

We learned that as great as HTML5 is, some things still aren’t quite there yet;

That designing a cross-platform experience means you need to think about the user experience on all devices from the ground up (in your game design);

That you shouldn’t have a game on mobile that does a lot of stacking or overdrawing;

And that you’d better love CSS and be good at it.

To see the fruits of their labor, you can play Skyscraper City on Facebook or mobile right now. It’s an impressive HTML5 feat that developers could learn a lot from. HTML5 does have its drawbacks and Gamzee presented them well, but that shouldn’t dissuade developers from trying out new technologies.

The sad truth is, after three or four seconds, nearly half of your website’s visitors may be gone, having bounced away in frustration.  And for those users who do suffer through a slow page load, the slowness will negatively impact their satisfaction and their engagement with your site. Delays as small as a hundred milliseconds have been shown to decrease the amount of time users spend on a site, reduce conversion rates and reduce average order size. Slow pages also rank lower in searches, are less likely to get indexed, and are less likely to be recommended via word of mouth. In every conceivable way, when it comes to your goals for your website, slowness is the enemy.

Where does the slowness come from? Perhaps surprisingly, over 90% of the time users spend waiting for a given page to load typically occurs after the main HTML page has been retrieved from the server! So for a huge number of slow sites, the single biggest culprit is bloat and inefficiency in the page. Specifically, the main offender is often too many HTTP requests triggered by the page. Each stylesheet, script and image found in a typical HTML page requires a separate round trip from the browser, to request and receive the resource from a web server.  The latency inherent in these HTTP requests delays the display of the page and users’ ability to interact with it. The overhead of these round trips can be massive, dwarfing the time it took to obtain the HTML document itself. So one effective rule of thumb for making your pages faster is to find ways to reduce the number of HTTP requests it requires.  This principle is the basis for many of the front-end optimization techniques recommended by web performance experts. Below are a few such techniques for reducing HTTP requests.

A quick disclaimer about the following recommendations: web performance optimization is a complex and evolving discipline, and brief articles like this one require glossing over some subtleties, details and trade-offs. So, please consider these points as an introduction and a starting point, rather than a definitive or prescriptive solution.

1. Stylesheets

Combine them:

Simply “concatenate,” or combine, multiple stylesheet files into one. If you have four .css files, for instance, instead of referencing them individually:

<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/one.css”>
/** contains: css rules in one.css **/
<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/two.css”>
/** contains: css rules in two.css **/
<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/three.css”>
/** contains: css rules in three.css **/
<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/four.css”>
/** contains: css rules in four.css **/

combine their contents into a single .css file like this:

<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/concat-v2.css”>
/** css rules in one.css **/
/** css rules in two.css **/
/** css rules in three.css **/
/** css rules in four.css **/

… so the content of each of these four files is included in the same order in the combined file. The same styling will apply to your page, but it cost a fraction of the HTTP requests to fetch it.

Put CSS in the head:

Also, be sure to put CSS in the HTML document’s <head> where it belongs, to speed up rendering. Inline <style> tags can delay rendering and force the browser to re-paint the whole page, which is costly from a performance perspective. Minification and compression are highly recommended, to reduce file size. Making your stylesheets cacheable will also greatly speed up subsequent page. (I’ll discuss caching and related topics in a future article in this series.)

2. Scripts

Combine them:

Just like with stylesheets, concatenating JavaScript files is a good way to reduce the number of HTTP requests in your page. If you have multiple scripts, combining them into a single script that is minified, compressed and is recommended.

Note there are tradeoffs with concatenation, for both CSS and JS. For example, you may want to discriminate between styles and scripts needed in every page of your site versus those unique to a given page or section of your site. You may also want to prioritize early loading for certain scripts, while others are fine to delay until everything else is done. And you may choose to reference certain popular libraries like jQuery on a commonly used public CDN URL in an attempt to leverage the browser’s cache from other sites the user has visited. So there are valid reasons not to combine every single .css or .js file in every page. But in general, given a choice between loading a bunch of smaller files separately and loading a single larger combined file, the latter is usually the better choice for performance.

Put scripts at the bottom:

Scripts should be loaded at the very bottom of your HTML document before the closing </body> tag. The old-school practice of putting them in the <head> introduces severe performance problems, in part because scripts are “blocking” resources. In other words, when the browser encounters a script tag, it generally stops doing much of anything else at all until it has fetched and executed the script. So putting scripts at the end of the document and/or fetching them asynchronously is important for performance. There are different ways to account for dependencies of the page on external scripts or interdependencies among scripts, and to preserve their order of execution in a cross-browser compatible way. For complex scripting and client-heavy web applications, using an open source script loader can be a good solution. But the simplest approach is usually just to put them at the bottom, in the desired execution order. [To learn more about blocking scenarios and script loading approaches, I highly recommend the excellent Steve Souders book “Even Faster Web Sites”.]

3. Images

Having too many images on a webpage is a very common performance problem that’s nearly as old as the <img> tag. Fortunately, there are optimization techniques which allow you to implement your chosen design with fewer HTTP requests. This can be achieved by combining image files with CSS sprites, by in-lining them with Data URIs, or by using pure CSS to eliminate the use of an image file altogether. Read on for details.

Combining with Sprites:

Combining images with “CSS spriting” has become a mainstream optimization technique. The idea is to combine a number of common images into a single, larger image file—and thus a single request.  This typically includes images like navigation elements, buttons, logos, icons or any other static images which are central to a design and which rarely change. When the big master image containing the smaller ones in it is fetched, CSS is then used to precisely position specific parts of the same image in the right places in the page while hiding the other parts from view. The result is a page that looks the same as if it had loaded each image separately, but which only required one HTTP request instead of dozens.

Note this technique is fairly invasive, and can introduce a considerable maintenance burden. Since the images are no longer in separate files, editing even one of them can require generating a new master sprite image and sometimes editing the HTML and CSS using the sprite. Tools for automating CSS sprite generation do exist to help ease their maintenance costs [e.g. http://spriteme.org and http://compass-style.org/help/tutorials/spriting/]. However, it’s worth comparing alternative solutions for reducing HTTP requests associated with images.

Inlining with Data URIs:

It is possible to directly embed the contents of an image file in HTML or CSS, instead of referencing it as a separate file. For example, you can replace this:

<img src=”tiny_image1.png” …>

with this:

<img src=”data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO 9TXL0Y4OHwAAAABJRU5ErkJggg==” …>

This technique has some advantages over spriting. It involves zero extra HTTP requests, and it also makes the in-lined image immediately available for rendering as soon as the browser discovers it. It does increase the file size of the HTML page or the CSS file that includes it, so it’s definitely not appropriate for large images, but this tradeoff is often worth making for smaller files (e.g. < 4KB). For sites with a bunch of small images, this can be extremely effective for reducing extra requests. As for caching, if the DataURI reference is in a CSS file or HTML page that can be cached, the image is effectively cached as well.

Data URIs have maintenance overhead too. Changing an image requires changing every HTML or CSS file that references it. Also, some older and less capable but still-popular browsers don’t support Data URIs, so some conditional processing is required. This is a primary reason why Data URIs are not as popular as CSS sprites in the web performance world. But with the advent of automated performance optimization services (like Yottaa Site Speed Optimizer), the feature detection and maintenance burden can be removed altogether.

Replacing Images with Pure CSS:

One smart approach to reducing HTTP requests is to forego image files, in favor of styling HTML elements with CSS. CSS can be used to great effect in implementing background colors, borders, buttons, hover effects, styled text, and even vector-scalable icons (via “icon fonts”). Using pure CSS is virtually always better for performance than using image files, and it can help make your site more maintainable too. Of course, cross-browser compatibility issues and “graceful degradation” of a complex design [or better, proper “progressive enhancement” of a simple basic design] are a challenge for every web developer and designer… but there are some fantastic open-source projects and communities that can really help. For example, HTML5Boilerplate and Twitter-Bootstrap provide great starting points for excellent, highly tested templates and user interfaces, and are essentially reference implementations for modern web development best practices. They are a great way to leverage the accumulated knowledge of experts and to learn about best practices for your markup.

Splitting up the page:

Finally, for cases where the number of images can’t easily be reduced with one of these techniques, it’s worth considering breaking up the page itself into smaller pieces. Pagination, with use of Ajax to fetch additional content when the user requests it, is a way to support a smaller initial page with fewer HTTP requests. That is, instead of a massive page triggering large numbers of image requests, have the initial page require just a few such images. Then use pagination to incorporate the additional content and images in the user experience. This isn’t a casual decision — if not implemented carefully, splitting up a page can cause problems for SEO, accessibility, bookmarking and user-friendliness. But by following best practices, these issues can be surmounted, with the desired result of faster pages delivered to your site’s visitors.

To recap:

* Slow web pages impede your website’s goals;
* 90% of a typical web page’s slowness happens after the HTML has been downloaded;
* Reducing the number of HTTP requests triggered by your page is usually the best first step to making your pages faster;
* We reviewed some specific techniques for reducing the number of HTTP requests in a given page
* We noted that automation can ease or remove the maintenance burden for more invasive optimization techniques

Next time I’ll dive into another area of web performance optimization: doing more to leverage the browser’s capabilities, moving toward the client side of the client-server relationship. In the meantime I’m always interested in feedback and others’ thoughts on web performance. Please reply in the comments.

Matt Cutts posted a new webmaster help video, but this time, instead of responding to a user-submitted question like he usually does, he provides what he refers to as a public service announcement.

“If you block Googlebot from crawling javascript or CSS, please take a few minutes and take that out of the robots.txt and let us craw the javascript,” says Cutts. “Let us crawl the CSS, and get a better idea of what’s going on on the page.”

“A lot of people block it because they think, ‘Oh, this is going to be resources that I don’t want to have the bandwidth or something,” but Googlebot is pretty smart about not crawling stuff too fast, and a lot of people will do things like, they’ll check for Flash, but then they’re including some javascript, and they don’t realize that including that javascript – the javascript is blocked, and so we’re not able to crawl the site as effectively as we would like,” he says.

“In addition, Google is getting better at processing javascript,” he continues. “It’s getting better at things like looking at CSS [to] figure out what’s important on the page, so if you do block Googlebot, I would ask: please take a little time, go ahead and remove those blocks from the robots.txt so you can let Googlebot in, get a better idea of what’s going on with your site, get a better idea of what’s going on with your page, and then that just helps everybody in terms of if we can find the best search results, we can return them higher to users.”

“So thanks if you can take the chance. I know it’s kind of a common idiom for people to just say, ‘Oh, I’m gonna block javascript and CSS, but you don’t need to do that now, so please, in fact, actively let Googlebot crawl things like javascript and CSS, if you can.”

(Coverage of the SMX East conference will continue at WebProNews Videos.  Keep an eye on WebProNews for more notes and videos from the event this week.)

Nathan Buggia, Microsoft’s lead program manager of Live Search Webmaster Central, started things off by directing people to look at the Arbor Snowboards site.  Although great for users, it’s much less so for search engines.  Buggia recommends that folks learn about some better alternatives at janeandrobot.com ("search friendly design patterns for web development).

Sharad Verma, Yahoo’s senior product manager of Web Search, later stepped up to give some more specific advice.  While CSS is good, he believes external CSS is better, for example.  You shouldn’t disallow CSS in robots.txt, and don’t hide text using CSS.  As for Ajax, use href links, use spot Ajax, and turn off JavaScript in your browser and ensure that the content is navigable.

"Search engines are getting there," Verma noted.  "We are not fully capable but we are making progress."

This brings us to Tony Adam, Yahoo’s SEO manager.  He recommends being strategic in your Ajax implementations, and applying progressive enhancement to the task.  Adam suggests working with standards or platform teams to build standard interactions, and looking at what Jeremy Keith has done.

One last, solid piece of advice from Adam: "Take care of things before it even starts."

WebProNews Video anchor Abby Johnson contributed to this report.

1. Keyword Research & Selection
2. Competitor Analysis
3. Site Structure
4. Content Optimization
5. Link Building
6. Social Media
7. PPC
8. Statistics Analysis
9. Conversion Optimization
10. Keeping It Up

Overview

Website structure and SEO are a combination of topics that I’ve always had a particular interest in because of my background in software engineering. I have worked on, or maintained over 150 corporate websites having seen many of the things that can make a website go wrong, which can seriously impact a websites operation and search engine rankings.

Of the three pillars of SEO (Structure, Content, and Links) I find the structure of a website to be one of the most under rated things, even among search engine optimization companies. The structure of a website consists of several elements which all are interdependent on each other. These include the code behind your website, how your website interlinks, and the technologies used in your website.

At this point I’m going to strongly recommend that you’re using Firefox with the Web Developer Toolbar installed. The web developer toolbar gives you an easy way to validate your website, test your site on multiple screen resolutions, and around another 100 functions.

Valid Markup and Cascading Style Sheets (CSS)

I have made it practice to develop all my projects in XHTML 1.0 Transitional (my personal preference so I can use target="_blank" and rel="nofollow" attributes) or XHTML 1.0 Strict and CSS 1.0. XHTML is a reformulation of HTML 4 as an XML 1.0 application. It is a very clean and semantic markup language which will also force you to write cleaner code. Whether you choose XHTML or HTML 4 your code will be friendly to the search engines (stay away from 3rd party standards like IHTML).

As for Cascading Style Sheets (CSS) it gives us the ability to abstract the design out of a webpage, or site into a secondary document. This gives us a lot of advantages, and very few disadvantages. By removing redundant design code from your website you place the content closer to the start of the document, while reducing your code to markup ratio. It also makes it easier, and more cost effective to maintain your website as you can implement simple design changes by only editing on file.

When converting a website from table based design, to pure CSS based design there is generally around a 40% decrease in code. The reason for this is when most people use tables they end up placing tables, within tables, within tables all with their own attributes (height, width, border, etc). Now multiple all that redundant, and unneeded markup by the numbers of pages of you site and you’ll quickly see how Google (or any other search engine) will be able to index you website more efficiently.

In my research, and experience I have concluded using these two technologies in conjunction with each other is a part of guaranteeing your websites success, especially with its compatibility with Google. You will also find if you do any research on this topic a recurring mantra of CSS fanatics tables are for tabular data not design.

You’ll find that most of the highly organically ranked SEO companies implement CSS based design on their own websites. For examples of CSS based design check out Beanstalk Search Engine Positioning, SEOMoz, and Quenet Consulting.

Website Templating

Now I’m going to start this section with a rant about Dreamweaver templates, and how useless they are. As a SEO / Web Developer there is nothing I loathe more than seeing a Dreamweaver template. If you’re going to template a site use a technology like Server Side Includes, PHP Includes, or ASP includes. The disadvantages of Dreamweaver templates are:

1. Embedded comments in your code can reak havoc on Keyword Density Tools
2. If you need a non standard footer in an index file you will need to break it from the template, creating issues for future template updates.
3. If you have a disagreement with your web developer / designer and you part company if he doesn’t supply you with the template it’ll cost you.

When building websites I personally use PHP for implementing Server Side Includes. PHP is a relative easy language to learn for implement simple things like includes. It is also one of the most popular Apache modules, as of April 2007 there were 20,917,850 domains, and 1,224,183 IP addresses with it installed. PHP is also available for the Microsoft IIS (Windows Server) web server.

Search Engine Friendly URLs

One thing that I can’t stress enough is try to stay away from Dynamic URLs, these are URL addresses with variables, and values following the "?" character. Google used to state that it had troubles indexing sites with dynamic URLs, and to a degree this still holds true. If you are going to use Dynamic URLs always try to have less than 2 variables in your URL. I have seen sites with excessive products, and URLs where Google / Live / Yahoo all have a different number of pages cached.

A better approach is to URL Rewrite your URLs. For the Linux side Apache has Mod Rewrite, and for Windows you can use ISAPI Rewrite. When you implement a URL Rewriting system you are essentially creating a hash URL lookup table for your site, than when a server query comes in it checks the hash table to see if it finds a match then feeds it the corresponding entry.

To put it into simple terms what we strive to accomplish with URL Rewrites is to mask our dynamic content by having it appear as a static URL. A URL like Article?Id=52&Page=5 could be rewritten to /Article/ID/52/Page/5/, which to a search engine appears to be a directory with an index.htm (or whatever default / index page your particular web server uses). To see an implementation of Mod Rewrites check out Dr. Madcow’s Web Portal in the Article Section, and Link Archive.

Dynamic Websites and Duplicate Content

If there is one reoccurring theme I see in a lot of dynamic websites on the internet is that they can sometimes present the same content on multiple pages. An example of this is when you visit a website that allows you to "view a printer friendly version of this page", a better web solution implementation would be to develop a printer friendly Cascading Stylesheet.

Another goal is also to avoid having any additional URLs on you site such as Links for changing currency with a redirect script, links to "Email to a friend" pages, or anything related to this. Always use Forms to POST date like this so that the same page, or a static page to reduce page count. This issue seems to plague a lot of custom developed ecommerce / CMSes. I’ve actually see CMSes that will present up to 5 URL / Links for each page, in the long run the spiders got so confused in indexing the catalog that some of the main content pages were not cached.

Internal Site Navigation

If built properly most websites will never have a need for an XML Sitemap, other than to get their new pages indexed that much quicker (Ecommerce & Enterprise being exceptions). I will however recommend that every website have a user accessible Sitemap linked from every page to aide your users, and for internal linking.

Most sites with indexing problems have issues with their internal page linking structure. The biggest of all these issues are websites that implement pure javascript navigation based system, these systems depend on Javascript to insert HTML into pages as there rendered. Now Google can parse javascript menus to find URLs, however all of these pages will only be linked from the JS, and not the pages there located on (expect no internal pagerank passing). The best Javascript menus are menus that manipulate your code on your page to change which sections are being displayed via CSS. An example of a hybrid CSS / Javascript menu that I like is QuickMenu by OpenCube (these guys have a great support department).

Keep I mind the more internal links you have to a page, the more internal strength this page will be given. So when in doubt link it up.

Testing Your Site Structure

When it comes to reliable website deploying all I can say is "Test It, Test It, and then Test It Some More". When testing structure I rely on 3 different programs / firefox extensions. The first is Xenu Link Slueth, this is a great tool to run on your website to figure out how many pages can be spidered, and to find dead links. The second is the Web Developer Extension for Firefox, make sure you always validate your code when you make changes. And the last is consult Google and Yahoo to see how many pages are in your index compared to how many pages Xenu found, on Yahoo or Google type site:www.yourdomain.com (Don’t use Live’s site: function it is useless).

After you’ve finished testing your code if you need to debug it I strongly recommend the Firebug Firefox Extension, and the IE7 Developer Toolbar.

Conclusion

When trying to maximize your organic rankings your internal structure is paramount, consider your site structure to be equivalent to the foundation of your house. If your foundation is not built adequately your house may be livable, but may have long term issues. With websites your long term issues will be a failure to maximize your ROI of your website, so practice safe and smart structure.