Archive for July, 2009

Imagine being a content developer for a website. You write a bunch of clever and informative articles, which should deliver a good dose of new visitors and ranking potential to the site. You submit them to the IT department for publishing online, and wait for good things to happen. But instead, it all falls flat. A look at your web analytics tools reveals that the number of site visitors has not increased over the time your new material was published. Further research reveals that your new content is not even in the search engine indexes! To quote the mighty Fred Willard, “Wha’ happened?” Perhaps some commonly seen site errors prevented your new content from being added to the index.

Just like a house, good web content needs a sturdy, reliable platform on which to reside. What good is a gorgeous, million dollar home if it’s sitting on a foundation of rickety 2×4s? No housing inspector would ever climb into such an unstable house to review it. And when a search engine crawler (aka bot) comes across a website littered with coding errors and serious problems with structure and design, it may, too, abandon its effort to crawl it. If that happens, no matter how good and compelling the content might be, it will never make into the index.

So how do you know if your site is has a rock-solid foundation or is just barely standing up? You need to get into your code. You can use a few good tools to help detect problems, but ultimately you’ll need to understand what the tools are saying when they indicate things are broken so you can fix them. Let’s get into a few of the site errors that are either pretty common or pretty important, and cover what you need to know to avoid their deleterious effects.

Invalid mark-up code

If your page mark-up code is bad, you’re bound to have crawling problems. But you might not know that the problems exist if your testing merely consists of, “How does it look in my PC’s browser?” Modern desktop browsers are pretty adept at munging through what you probably meant to do into a workable, on-screen presentation. They can often deal with code that is footloose and fancy-free when it comes to standards compliance. But the search engine bots are not as flexible as desktop browsers, and code problems can often trip them up and bring the crawling of your site to a halt. In addition to that, mobile device browsers are not likely to be as accommodating with poorly written code as desktop browsers, either. Anything you can do to make your code solid and standards compliant is good, for both your users and the bots.

To see where your code stands, use a good mark-up code validator. Most good development environments will offer either a built-in validator or references to such tools online. A particularly detailed validator is the W3C Markup Validation Service, a free, online HTML validator from the folks who bring you the coding language standards. It doesn’t validate entire websites recursively, just one page at a time, but it is still a very good source for detecting and identifying the issues behind coding errors.

Examine the results of the validator scan. What did it find? Check to see if you have some of these more common coding problems in your pages:

• Does your file contain a document type declaration (DTD) statement? (It’s not absolutely required for early versions of HTML, but you’ll need to have it for XHTML documents.) And remember to use the correct coding practices for which type of document you specify—the requirements for XHTML versus HTML are similar, but not identical.
• Are all of your tags closed properly? All of your paired tags must have corresponding openers and closers. The paragraph tag, <p>, for example, is one whose closing tags is often omitted. And if you are using XHTML, are you closing single (aka empty) tags correctly? Empty tags, like Break, need to include a forward slash before the closing greater-than sign, as in <br />.
• Are your tags written in lower case letters? It’s not required for HTML, but it is for XHTML, so it’s now considered a best practice.
• Are all of the tag attribute values, even numerals, as in <table border=”1″>, enclosed in quotes? While this is not required for earlier versions of HTML, it’s certainly a best practice and is a requirement in XHTML for creating well-formed code.
• Are the tag attributes used in your code valid? HTML has changed over the years, and some attributes have been deprecated with the introductions of the latest specifications of HTML 4.01 and XHTML 1.1. An example of this is <table align=”left”>, where the standards dictate that the newer style attribute should be used now instead of align. If you are unsure, check with a reliable mark-up tag reference, such as the Tag Reference for HTML/XHTML.
• Are you using deprecated tags? Again, changes to the standards have seen some tags become obsolete. For example, the <u></u> tags for underlining text was deprecated in HTML 4.01 and is not supported at all in XHTML using the Strict DTD.
• Are your tags positioned in the right place in your code? For example, <meta> tags can only be used within the <head> tag. Make sure you are placing your tags correctly.
• Are your tags nested correctly? If <tag 1> precedes <tag 2>, </tag 2> must be closed before </tag 1>. Remember this: first opened, last closed.
• Are you using the escape special character &amp; for the ampersand character in your href attribute URL values? Some long, dynamic URLs may include the ampersand character. But to keep your code compliant, replace the ampersand references in URLs with its associated escape character code.

Tip: Test your pages in multiple browsers. One may be far more tolerant than another, and you really need to accommodate the least tolerant browser to allow the highest portion of your site’s visitors to have a good experience.

Bad links

A bad link encompasses more than mere mistyped or expired URLs. It also includes structural and site design problems that may not break a site, but can prevent it from reaching its full potential. But bad links are a very common problem, if only because the target of the link is typically outside of the linking webmaster’s control (at least external ones!). The webmasters of the sites you linked to usually fail to courteously let the rest of the known universe know when they’ve changed the URL of their pages! OK, so that was a bit facetious (as if that would be feasible, if even possible, to do!), but the problem remains. Pages you link to are regularly moved, deleted, or renamed without your knowledge, and those who tried to link to them look like a fool. As if that were the only repercussion. Broken links are bad form for search engine optimization (SEO), which means this error can eventually affect your page’s rank.

You need to regularly run a link checker as part of your site maintenance work. There are a lot of tools out there on the Web to do this work, but some only check one link at a time. That’s fine if you have a three-page site and only six outbound links! Besides, you could easily do that by clicking through your site in a browser! You need a tool the scan all the pages on your site in one fell swoop and give a consolidated report on the findings. Many mark-up language development environments offer tools for this, so check there first. I also recommend that you look at the webmaster tools offered by the search engines. Bing’s Webmaster Center offers a Crawl Issues tool that provides feedback on detected broken links. Use the File Not Found (404) filter to get a report on broken links. Also note that Google and Yahoo! also offer their own version of webmaster tools with similar functionality.

The following is a list of link issues to look for on your site:

• File Not Found 404 errors. Error 404 is an HTML error that appears when you click a link or enter a URL in your browser that has no corresponding page. It could be due to a typo in the URL address (either keyed into the browser’s address bar or in the anchor tag’s href attribute value), or the page itself could be missing. Find all of the outbound 404s in your site and figure out what is wrong with each . You might have to go to the linked website’s home page and work through the site’s navigation to find the correct page, if it still exists. Of course, you can also get 404 errors in your own site’s internal navigation (let’s hope that didn’t happen!).
• Missing page elements. Your internal navigation may go to the correct page, but some of the linked page’s elements may not appear, such as images, animations, scripts, or other externally-referenced files. Check the links for those elements, and if possible, use absolute links (which include full URLs) rather than the shorter, more convenient, but less reliable relative references (links addressing the file relative to the calling file’s location in the site’s directory structure rather than the full path of an absolute URL).
• Mixed canonicalized links. We’re discussed the value of canonicalization in this blog before. And while this is not an error that will stop the bot in its tracks, it can negatively affect the ranking of your own pages if you regularly use multiple URL variations for the same page. Choose the canonical URL for a page, use it consistently in your internal linking, and consolidate your flow of link juice to that single URL. Now that’s what I’m talking about.
• Navigation blockages. Using script for your internal site navigation may work just fine in your browser, but it’ll stop a bot dead in its tracks. Just don’t do it! Use anchor tags with keywords in the anchor text and the bot will be happy.

Tip: By the way, 404 errors are not limited to your outbound links. Other webmasters might incorrectly code or not keep up with changes to your site, resulting in 404s for users who want to see your content. Help keep those folks on your site by creating informative and useful, custom 404 pages. For more on this, see our previous discussion on this issue in Site Architecture and SEO – file/page issues.

Other coding errors

There are other coding errors or omissions that can adversely affect the way the bot collects information about a site. Let’s cover these as well.

• Missing, empty, or duplicate <title> tag
• Missing, empty, or duplicate <meta> description tag
• Missing, empty, or duplicate <h1> tag

These tags are key locations in the page for using keywords and key phrases to associate for relevance with your content. The <title> tag is required in HTML and XHTML documents, and the other two might as well be (all of them are very strategic for SEO). Each one is to be used only once per page, and all must have text (no images or just blank spaces!) between the tags. That text in those locations is considered important keyword text by the bot (for it defines the content of the page), so make the most of it. Don’t duplicate text strings between these tags, either. That’s a wasted opportunity for defining more keywords.

The last issue I want to mention is the use of 302 redirects. We talked about 301 redirects before, and how to strategically use them. 302s are only temporary redirects, and unlike with 301s, no link juice credit is passed to the redirected page. Using a 302 redirect is not a coding error per se, but much of the time it is a strategic error from the perspective of SEO. Unless you have a genuinely temporary need to redirect a page, stick with 301s as an SEO best practice.

If you have any questions, comments, or suggestions, feel free to post them in our SEM forum. Until next time…

– Rick DeJarnette, Bing Webmaster Center

We hope Wednesday’s announcement of the new search and advertising partnership with Yahoo! is just the first step in a journey that will provide more choice to consumers, better value to our customers, and more innovation by enabling efficiencies and integration within our Search and Search Advertising businesses.

As of now, things here will remain status quo. There will be no immediate changes to our ongoing work because of this announcement. We will continue to support webmasters with the Webmaster Center forums and talk about SEO and SEM issues in the Webmaster Center blog.

But we urge you to stay tuned to the Bing Webmaster Center blog for regular updates and news of interest to our webmaster customers. We have high expectations for the future, and we know that you do as well. You can stay on top of breaking news by subscribing to the Webmaster Center blog RSS feed or by regularly visiting our blog page. In the meantime, we’ll keep up with other blog articles of interest to webmasters, including the popular SEM 101 column, to add value to this growing community of users. Thanks for tuning in!

– Rick DeJarnette, Bing Webmaster Center

Earlier this month, over 3500 of you responded to our survey asking you to help us prioritize some of the media features that had been suggested for the 2.9 release. While the exact features for 2.9 have not been hammered out yet, as we continue to match up developers with features, we wanted to share the survey results and let you know what we’re thinking in terms of approach.

First, the results. The first question, and the only one that was mandatory, asked what single media feature you would choose to include in version 2.9. The top vote-getter was standalone editable photo albums (as opposed to the current per-post gallery) at 17.5%, followed closely by easier embeds for videos and other third-party content at 16.5%. Next came basic image editing (such as rotating, cropping and resizing) at 13.7%, and post thumbnails (image teasers for posts featured on the home page) at 12.9%. The rest of the features each took less than ten percent of the vote. The full list came in like this:

The second question was optional (3406 people answered it), and asked you to rate each feature on a scale going from top priority down to definitely not for implementation priority. Results here were in line with the results from the first question, with most features rated as nice to have more often than anything else. The features that scored the highest in question 1 were more likely to have earned higher votes in the Top Priority column, but no feature was ranked as a Top Priority more often than it was ranked as a Nice to Have (though Media Albums, Easier Embeds and Post Thumbnails came close). The complete tabulations are shown in the chart below.

Question three was getting at the same thing, but in a more granular fashion, asking you to rank the eleven features in order of priority to you. As only one feature could be assigned to each position, this prevented people from assigning the same priority to multiple features, and we wondered if it would alter the results. Though some features got more recognition in this question, the overall rankings were still in line with the results from question 1. Here are the exact votes per feature/per position:

The fourth question asked for your preferences regarding including new media features in core, bundling them as plugins with the core download, or developing them as plugins but not bundling them with the core download. This vote was more interesting to watch. As the notice for the voting went first to the development community, then to the user community, it was possible to see a shift in the voting. Earlier in the voting cycle, there were more votes for bundling ‘core plugins’ for the advanced media features, while later votes skewed heavily toward just putting the features in core. This vote shows, I think, one of the differences between developer and user perspectives. While developers are heavily interested in keeping the core code lean and relying on plugins for advanced functionality, many users would prefer features they want to be included in core rather than being a separate plugin. The final tally on this question was 56.2% for including features in core, 38.1% for bundled plugins, and 5.7% for non-bundled plugins. The actual numbers:

Clearly this issue deserves more discussion, and the concept of how we move toward a system of canonical plugins and/or core “packages” intended for different use cases (CMS, photoblog, portfolio, etc) will be a big topic in the months ahead.

So where does that leave us regarding features coming down the road? When the vote closed, the results were discussed in the #wordpress-dev IRC chat to divvy up feature development.

The top-voted feature, standalone photo albums, is being worked on as a Google Summer of Code project by Rudolf Lai, under the mentorship of WordPress Lead Developer Mark Jaquith. The “pencils down” date for GSOC is in less than two weeks, at which point we’ll be assessing the state of Rudolf’s project. Hopefully, we’ll be able to incorporate it with 2.9 development, do some testing, amend the code and/or UI as needed, and have this launch with the 2.9 release (in core or as plugin TBD). Undoubtedly, additional functionality will be contributed by core contributors who have also been working on media plugins.

Easier embeds, the second most popular feature, is being looked at in a couple of ways. One, more shortcodes for third-party services. Work on this has already begun. In addition, Viper007Bond, of Viper’s Video Quicktags plugin fame, has taken on the task of working on a way to improve the embed experience in core. We’re not sure quite how this will work yet, but stay tuned.

Adding some basic editing functions like 90-degree rotation, cropping and resizing was considered an obvious winner in the dev chat, and as several plugins handle this functionality, we’re hopeful it will be included soon.

Post thumbnails are being handled by Mark Jaquith, who has created this functionality before, with an assist from Scribu, who has a similar plugin in the repository.

Lower ranked features aren’t off the radar, but may take lower priority than some other (non-media) features we have in the works. One of my favorite 2.9 features is in trunk now, and changes the way we delete content. Goodbye, annoying popup asking me if I’m sure I want to delete a comment/post/etc. Hello, fast and quiet removal into a trash can, from which the content can be retrieved if it was deleted by accident. Think Gmail style. We’re also hoping to work on improving page management, though that has a number of technical issues that may cause it to be a 3.0 feature instead.

As always, you can keep track of development progress in a number of ways:
1. Keep track of Trac. Contribute a patch, test a patch, just read through tickets if you have some time to kill, whatever. There are over 500 tickets against the 2.9 milestone currently. Patches and testing can help us get that number down.

2. Follow Trac commits on Twitter. Don’t want to get involved in the nitty gritty, just want to see what’s getting committed? Follow wpdevel on Twitter and you’ll get core commit updates in your stream.

3. See what’s on the dev agenda. Each week for the IRC dev chat, there’s an agenda, created based on developer suggestions posted at wpdevel.wordpress.com. This blog also contains discussions about specific development issues.

4. Join the dev chat. The day changed this week, to accommodate European schedules. Chats are now held for one hour each week on Thursday at 21:00 UTC. That’s 5pm NYC, 2pm in California, etc. Chats are in the #wordpress-dev room at irc.freenode.com.

5. Watch this blog. If you’re not a developer and prefer to stick to major announcements, the occasional survey to help decide a feature, and security notices, just keep doing what you’re doing. Reading this blog will get you all of these things.

Thanks again for your help in prioritizing features for version 2.9, hopefully coming toward the end of the year to a server near you!

We’ve heard from a few developers that they are currently experiencing a few issues with Application Invites in the v0.7 container and PostTo for IFrame based applications. We take all platform issues seriously and your feedback and cooperation are paramount for the success of our platform.  We are working on getting the fixes out from our end, but in the meanwhile we wanted to alert you to the fix you can do from your end now.
 
For purely onsite applications:
When creating the Message object that you pass to requestShareApp make sure to include a value for TITLE (cannot be undefined):
 
// create the rSA message
var body = "Some message.";
var title = "This will be ignored but can't be undefined.";
       
// create an opensocial.Message object
var reason = opensocial.newMessage(body); reason.setField(opensocial.Message.Field.TITLE, title);
 
// initiate requestShareApp
opensocial.requestShareApp(recipient_array, reason, your_callback_func);
 
For IFrame applications:
You’ll have to change your reference to our IFrame Kit – This is mandatory as there is not a fix from our side for this.  Rest assured that appropriate actions are being taken to mitigate this from happening in the future.
 
Before you needed the following scripts included:
 
<script src="http://x.myspacecdn.com/OpenSocial/references/gadgets003.js" type="text/javascript"></script>
<script src="http://x.myspacecdn.com/modules/common/static/js/Apps/ifpc003.js" type="text/javascript"></script>
<script src="http://x.myspacecdn.com/modules/common/static/js/Apps/json001.js" type="text/javascript"></script>
<script src="http://x.myspacecdn.com/OpenSocial/IFPC_externalIframe004.js" type="text/javascript"></script>
 
Replace with:
 
<script type="text/javascript" src="http://js.myspacecdn.com/OpenSocial/RPC/RpcContainer.000.js"></script>
<script type="text/javascript" src="http://js.myspacecdn.com/OpenSocial/RPC/RpcContainer.003.js"></script>
<script type="text/javascript" src="IFPC_externalIframe005.js" ></script>
 
<script type="text/javascript">
gadgets.rpc.setRelayUrl('..', 'http://profile.myspace.com/Modules/Applications/Pages/rpc_relay.aspx');            
</script>
 
Code for IFPC_externalIframe005.js can be found HERE .
 
We have updated our sample application for reference.
 
After we have the fix out for appInvites to handle the missing Title you can go back to not including it if you choose.
 
We are deeply committed to the MySpace Open Platform and we’re sorry for any inconvenience this may have caused. We’re working hard to get a fix out now.

The WordPress team had initially committed to maintaining the WordPress 2.0.x legacy branch until 2010. Unfortunately, we bit off more than we could chew—the 2.0.x branch is now retired and deprecated, a few months shy of 2010.

Many of the security improvements to the new versions of WordPress in the last couple of years were complete reworks of how various systems were handled. Porting those changes to the 2.0.x branch would have been a monumental task and could have introduced instability or new bugs. We had to make hard decisions between stability and merging in the latest security enhancements. Additionally, far fewer people stayed on the 2.0.x branch than we anticipated. I take that as a testament to the new features in WordPress and perhaps even more the features offered by plugins, many of which don’t support older versions of WordPress!

I’m disappointed that we weren’t able to keep the branch maintained until 2010, but since one of the big reasons for that failure was the massive scope of our security improvements for the newer versions of WordPress, 2.0.x doesn’t die in vain!