Took me a while to figure out why websites were breaking in some pages, till I was finally able to figure out that Internet Explorer has a bug where it can handle only pages with under 30 CSS files. Anything above that and the page would go dead.

Don’t believe me? check Microsoft’s “All style tags after the first 30 style tags on an HTML page are not applied in Internet Explorer”

All style tags after the first 30 style tags on an HTML page are not applied. Occasionally, you may also receive the following error message:

The page you are looking for might have been moved or had its name changed.

If you use a network monitor tool to capture network traffic, you may notice that a TCP reset occurs when Internet Explorer is receiving the page. Internet Explorer then generates another POST request if the original request was a POST request. Or, Internet Explorer may send a GET request instead.

You’d think that Microsoft would fix such a bug, but looking at the Internet Explorer versions that are affected, the list starts back at version 4.0 and goes up all the way to the most recent version as of today – Internet Explorer 8. Brilliant.

If you’re developing Drupal based websites, 30 CSS files are nothing, especially with the more advanced themes and modules. It’s enough that you include the theme, views and panels to easily top this limit.

But, there are a few things that might help.

For one, the IE Unlimited CSS module saved me with the Drupal 6 installations.

In some cases, though not all, the built-in Drupal CSS aggregation/optimization may help (if it’s aggregated already, that is).

How to enable Drupal CSS file aggregation

1. Log in as your Drupal site’s administrator.
2. Go to the Administer » Site configuration » Performance page.
3. Check the Enabled checkbox for Optimize CSS .
4. Click the Save configuration button.

Another option, if you’re not in Drupal is using a CSS optimizer solution. Here’s from Nadeau Software’s list, and although they claim it won’t speed up by much, it might save you from IE.

CSS optimizers

Hand-editing CSS to make it more optimal is tedious. Instead, use a CSS optimizer application. Here's a few of the many available:

• Blumentals Software's CSS Toolbox (freeware)
• CSS Drive's CSS Compressor (freeware)
• Michael Bianco's CSS Optimizer (freeware)
• Robson's CSS Compressor (freeware)
• Lottery Post's CSS Compressor (freeware)
• CSS Tidy (freeware)
  • CleanCSS (freeware)
  • Code Beautifier (freeware)
  • CSS Formatter and Optimiser (freeware)
  • CSS Code Formatter and Optimizer (freeware)
  • ... and many more based upon CSS Tidy

It never ceases to amaze me how a serious company as big as Microsoft, with all the resources available to it, keeps getting the whole browser thing wrong. What’s even more remarkable, is that there are those among us who still use that thing.

We're happy to announce another feature to assist with managing duplicate content: parameter handling. Parameter handling allows you to view which parameters Google believes should be ignored or not ignored at crawl time, and to overwrite our suggestions if necessary.

If you’re not handling this through robots.txt, this is a great way to simply address duplicate content issues cause by parameters leading to duplicate pages that display the exact same content.

The option in GWT indicates :

Dynamic parameters (for example, session IDs, source, or language) in your URLs can result in many different URLs all pointing to essentially the same content. For example, http://www.example.com/dresses?sid=12395923 might point to the same content as http://www.example.com/dresses. You can specify whether you want Google to ignore up to 15 specific parameters in your URL. This can result in more efficient crawling and fewer duplicate URLs, while helping to ensure that the information you need is preserved. (Note: While Google takes suggestions into account, we don't guarantee that we'll follow them in every case.)

Since someone emailed me to ask - here are some of my suggestions for optimal SEO configurations. If you have others – I’m interested.

Gallery2

• g2_highlightId : Ignore
• g2_imageViewsIndex : Ignore

Drupal

• destination
• order
• sort

Google Custom Search

• as_q
• sitesearch

BTW – Yahoo’s Site Explorer has had a similar concept with Dynamic URLs (under Actions) for years.

Specify up to 10 dynamic parameters that you want us to treat specially whenever these are seen in URLs belonging to http://www.yourdomain.org . We will automatically rewrite the URLs containing these parameters as specified below. You can choose to:

1. Remove these parameters from the URLs, such as in case of session ids, you could ask to remove 'sid' from URLs.

2. Use a default value for the parameter, for example you could set the 'src' parameter to be 'yhoo_srch'

Cron has been running for over an hour and is probably stuck.

or

Attempting to restart Cron

That usually doesn’t leave you with much to work with, does it?

[UPDATE 05/09/2010 - I recommend installing the SuperCache module that will either take care of 90% of the problems or help you track down the probelm. This should quickly be integrated into core, if you ask me]

First thing to tackle this is try and get the cron unstuck and running. To do that, you can install the Devel module, goto the variable view, and delete the cron_semaphore variable that indicated a cron is already running. After flushing all cache you should be able to run cron again. Then, you might come across various types of the next strange message

MySql : " Warning: MySQL server has gone away "

Gone away where?

This indicates that MySQL is timing out. To tackle that you’d need to tweak MySQL a bit. Drupal has a great guide on that. Essentially, it’s opening your /etc/my.cnf and setting it to something that allows longer runs. Following is what I ended up with :

[mysqld]
skip-bdb
set-variable = max_connections=500
safe-show-database

Don’t forget to restart the server and after clearing the cron semaphore again rerun the cron. That should take care of things.

I've just come across an excellent overall overview of Drupal SEO presented by Mastering Drupal through video screencasts. They take you step by step doing Drupal SEO in a way I've always wanted to do, but never had the time for. I would go as far as saying it's one of the best step-by-step SEO tutorials I've watched, and I'm glad someone finally did something like that for Drupal.

Find the Drupal SEO video episodes here: first, second, third, forth, and fifth (they ask that you go to the site and subscribe to view those). All together, about an hour of Drupal SEO tweaking.

Great work, guys.

[UPDATE 05/09/2010 - I recommend installing the SuperCache module that will either take care of 90% of the problems or help you track down the probelm. This should quickly be integrated into core, if you ask me]

Usually, it's a problem with on the modules you recently installed. Most of the time, it's also accompanied by another PHP error before or after. It's best to get a long look at the error log, and see whether anything's wrong. If there are errors, look them up on the Drupal.org site, and if one of the modules is causing it - upgrade it, or report the problem to the development team.

There are many things you can do to debug this problem, but I was looking for an easy solution for one of my not-so-techie colleague.

First, take a look at CronPlus:

CronPlus is meant to relieve application programmers of the need to reinvent the same old wheel of filtering down the Drupal cron calls — which can happen at any interval chosen by the installer — into real-world (approximate) time intervals. CronPlus provides an approximation at each interval. It does not claim, nor even attempt, to be accurate enough for precise applications such as month-end financial processing or real-time control. Instead, it is meant for duties such as routine log cleanup, updating data from external sources, pushing data to other systems, and similar things which require only an approximate time base.

Looking into this issue I came across those two interesting tips. This next tip will give you a more detailed cron message on the module currently being processed:

The flow won't reach all following cron hook calls and you'll get the problem you've described. The key is to find out which hook_cron is causing the crash, you can do that by adding this in the module_invoke_all() located in includes/module.inc

foreach (module_implements($hook) as $module) {

$function = $module .'_'. $hook;

replace it with something like this :

foreach (module_implements($hook) as $module) {

if ($hook == 'cron')

watchdog('cron_runs', $module);

$function = $module .'_'. $hook;

You'll get a new category in the event log called "cron_runs" on your next cron that will list the cron call order. The last one in this list is your culprit. Remember that this is considered core hacking and you should remove the code as soon as you discover the problem location. Core hacking is calling for trouble.

If you're sure all is working like it should, then another good tip is about playing around with the timeout settings :

Go to your settings.php file (under sites/default or wherever it is). At the bottom of it you will see a list of ini_set commands. Add the following to the list:

ini_set("max_execution_time", 60);

The number at the end is the number of seconds a program can run before timing out. Setting it to 0 means "never timeout" which you should use very carefully, like on a development site where you have control over the server. Try increasing the number at the end until your cron completes.

There is also a way to do this in a .htaccess file (the command is worded slightly differently), but some isps, like mine, have the system set up in a way that will cause a fatal error if you try to control php ini_set from the .htaccess file. As far as I know, you will never go wrong by putting it in the settings.php file.

How do you debug your problematic Drupal Cron jobs?

For example, I was getting the following error when trying to log in:

PHP Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cache limiter - headers already sent (output started at /includes/bootstrap.inc:760) in /includes/bootstrap.inc on line 760

Seemed like a session cookie problem.

Hoping that I'll save some time for those facing this issue, here's the short description of the problem from John Albin:

This bug is more pernicious than originally thought. There’s a critical bug with an edge-case configuration. Here’s a not-so-unusual situation:

If a user goes to a PHP-based site at http://example.com (it doesn’t even have to be running Drupal, just some PHP code that uses sessions), by default PHP sets a cookie named PHPSESSID for .example.com.

If that user then goes to a Drupal site at http://intranet.example.com and attempts to login, Drupal sets a cookie named PHPSESSID for .intranet.example.com with authenticated permissions. BUT, the user’s browser sends both the .example.com and the .intranet.example.com cookies back to the intranet Drupal site and when Drupal tries to access the $_COOKIE['PHPSESSID'] value via PHP’s session functions, it gets the .example.com value; the wrong session id!

From the user’s point of view, the user sees no “Unrecognized username or password” message (Drupal does enter a “session opened” watchdog entry), but because Drupal can’t access the correct cookie, the user keeps seeing the login screen. If the .example.com cookie is set to expire in 2037 (some PHP apps do that) and the user doesn’t think to delete cookies for a completely different web server, the user will NEVER be able to log into intranet.example.com!

From the cookie spec:

When sending cookies to a server, all cookies with a more specific path mapping should be sent before cookies with less specific path mappings. For example, a cookie "name1=foo" with a path mapping of "/" should be sent after a cookie "name1=foo2" with a path mapping of "/bar" if they are both to be sent.

Even though both cookies are submitted by the browser, PHP clobbers the value of the more-specific cookie with the less-specific cookie that follows. So there’s no way that Drupal could try to differentiate the two cookies.

I believe this is rightly a PHP bug and have submitted a bug report with PHP. But Drupal has to have a work-around. I verified this affects both 5.1 and 4.7.6.

After trying almost everything, I've finally found John's patch on #64 and it worked okay for my configurations. Unbelievable.  Thanks John.

Here are a few general tips on making sure everything is using Unicode :

Install manually, don't use Fantastico 

One of the things that Fantastico does is install the database in the wrong collation. Create your database by yourself, make sure that the collation is set right, and then proceed with the Drupal installation.

Verify by running a Unicode change script

Some Drupal modules still have bugs of creating tables with the wrong collation. Here's a piece of quick code you can run from your shell if you notice mixed collation in your DB. I will go table by table and change the collation to Unicode. If you don't have shell, try a shell solution for PHP.

Change all tables to Unicode:

for table in `mysql -h<DBserver>-u<DBuser> <DBname> -p<DBpassword> -e "show tables" | grep -v Tables`; do mysql -h<DBserver>-u<DBuser> <DBname> -p<DBpassword> -e "alter table $table convert to character set utf8" ; done

Change DB to Unicode :

mysql -h<DBserver> -u<DBuser> -p<DBpassword> alter database <DBname> character set utf8;

Here's my impression of the "average visitor" (AV) I met throughout my IT years:

• Only a few AV look at the address of the link to see what address it's referring to the status bar. Some won't even be able to tell if it's an internal or external link if they do look at it.
• Only a few AV use the "Open Link in New Tab" or even "Open Link in New Window". Even fewer AVs are aware of the middle-click option. IE6 users, which still constitute for an overwhelming percentage of browser users, don't even have tabs and they hate opening a new window with it flawed positioning and resizing.
• While the AV does know about the "Back" button, AV will usually use it in a case of a mistake. If the link found is a good read, AV will stay there.

Which leads to the conclusion that most people that are interested in an external link provided on you site will leave the site, sometimes not knowing that they're transferring somewhere else. This problem is also relevant when pointing out to images or videos.

Aside from adding HTML code by hand to the links here's what you can do:

1. Use a module or a plugin to mark the external links to indicate that they're external, and if you wish - forward outgoing links to a new window. If you're using WordPress, consider installing the "External Links Plugin For WordPress" or "Identify External Links". If you're using Drupal, consider installing the "External Links Module".
2. Use Snap or other preview tools that open a small preview window of where the link is leading to. You can also use MyBlogLog to show the number of visitors who clicked on an external link. AVs will understand that clicking the link will lead them somewhere else. While this might work well on some sites, it is extremely annoying on others. There is a long debate over this tool all over the blogosphere.

* Please note that automatically opening a new window for a link is considered bad practice among some web developers, but I think it justifiable in some cases.

Another neat option, used for links and images, is to AJAX open the link ontop of the site. There are endless JQuery code snippets and plugins that do this kind of thing, like :

• Thickbox
• Slightly ThickerBox

Here are the ones that available for Drupal (to see what this does, run one of the demo sites) :

• Lightbox2
• Thickbox
• Greybox Redux
• Litebox

Other Drupal quick tricks that aim at the same functionality:

• Valid XHTML Link Popups using jQuery
• External links in new window with message box.
• Open aggregator links in new browser window.

And here's also something for WordPress :

• Dan Atkinson with the jQuery 1.1.1 for WordPress and Thickbox 2.1.1 for WordPress.
• Lightbox JS version 2.0
• stimuli.ca Lightbox 2.3 plugin for WordPress

Some of those who submitted their sitemap to Google's Webmaster Tools might have came across a message saying that the sitemap can not be verified since all pages return "OK" success instead of "404 not found" headers - which is another example of how Google requires a proper 404 page. To check how your site is responding you can try one of the following ways :

1. Use an online tool, like - HTTP Header Viewer or HTTP Status Codes Checker.
2. Use the Live HTTP headers Firefox plugin.

Track a URL on your site that is suppose to return a "404 not found" message, and check the header. In some cases, like when running PHP CGI server, a wrong header will be returned, like "404 OK". This might happen since Drupal doesn't cover all possible configurations and follow up on PHP bugs.

Drupal's "404 OK" possible problem

Webmaster Tips was the first one I noticed to raise the "404 OK" issue for Drupal on the Drupal.org site. Guitarmiami wrote :

When running Drupal on a server with PHP as CGI you have to change line 288(?) in /includes/common.inc from

drupal_set_header('HTTP/1.0 404 Not Found');

to

drupal_set_header('Status: 404 Not Found');

Otherwise it will not send the correct 404 Not Found headers. That includes popular hosts like Site5, Bluehost, etc. More information can be found here: http://us3.php.net/header

This was true for my Drupal sites running on a specific host (Siteground), which were returning "404 OK" instead of "404 not found", due to a PHP CGI bug that requires a different command. To fix it, you need to change the common.inc file as suggested and the problem will be sorted.

Drupal's "403 Forbidden" possible problem

It's interesting to read that one of the commenters has suggested another issue with the way 403 Forbidden is returned. Although he didn't manage to get this sorted, I found that changing the drupal_access_denied in common.inc in quite the same way works okay. So change :

drupal_set_header('HTTP/1.0 403 Forbidden');

to

drupal_set_header('Status: 403 Forbidden');

Drupal Custom 404 pages

There are a couple of modules that can enhance Drupal's "404 not found" behavior. Consider using the following modules :

CustomError

This module allows the site admin to create custom error pages for 404 (not found), and 403 (access denied), without the need to create nodes for each of them.

Since the error pages are not real nodes, they do not belong a category term, they do not show in the search, and will not show up in node listings, or in Popular Content block.

Search 404

Instead of showing a standard "404 Page not found", this module performs a search on the keywords in the URL, e.g. if a user goes to http://example.com/does/not/exist, this module will do a search for "does not exist".

It includes beta stage search engine keywords detections.

-

First off, if you haven't done so, quickly enable Cleanurls and the core Path module in your Drupal installation from the admin interface. Now, let's get down to the modules :

Page Title

The page-title is an extremely crucial SEO element and this module will allow you to set in any way you prefer.

This module gives you control over the page title. It gives you the chance to provide templates for how the title should be structured, and on node pages, gives you the chance to specify the page title rather than defaulting to the node title.

Tips :

• I find the default settings to be satisfactory.
• Do note that you might need to play around with your theme to make this module work.

Pathauto

The page URL path is another important SEO and that can be set manually through the core Path module, but Pathauto takes that a step further with an autocreation of URL aliases based of your specs.

The pathauto module automatically generates path aliases for various kinds of content (nodes, categories, users) without requiring the user to manually specify the path alias. This allows you to get aliases like /category/my-node-title.html instead of /node/123. The aliases are based upon a "pattern" system which the administrator can control.

Tips :

• I recommend not setting anything to include dates, categories, breadcrumbs and the likes in your Pathauto alias settings unless you're absolutely sure this is what you need. You might change your mind about the category, or where something should be in a book, or maybe even want to report an old blog post. In my opinion - set it to the type followed by the title, AKA - [type]/[title].
• If you define feed aliases, remember that they will contain duplicate content for search engines that might hurt your SE rankings, so you'll have to add a disallow rule for those in your Drupal robots.txt.
• It took a while for the the developers to add the warning on not using the index aliases. In my opinion, this feature should be completely removed from pathauto for endless reasons (like alias duplication and SEO content duplication problem).

Global Redirect

Duplicate content gets you penalty with the search engines, and that's exactly what Global Redirect is for.

Simple module which…

• …checks if the currently url has an alias set and does a 301 redirect to it.
• …checks if the currently url has a trailing slash, removes it and checks if that has an alias and, if so, does a 301 redirect to that.
• …Finally, checks if the current URL is the same as the site_frontpage, if so - then redirects to "nothing" (ie the frontpage).

Although might be resource consuming, and could be configured by hand in your .htaccess, this will save you a world of trouble and prevent your content duplication problem.

XML Sitemap (formerly Google Sitemap)

To make sure all your site pages are indexed by search engines, you should create an XML sitemap and submit it to Google and Yahoo. XML Sitemap will export that sitemap for you.

The XML Sitemap module creates a XML sitemap in accordance with the Sitemaps.org specification.

Tips :

• It will not completely solve content duplication problem, but you might want to disable "Include links to taxonomy term pages"

Meta tags (Nodewords)

Metatags still play a role in some search engines, and they do provide vital information about every page with a preview description and relevant keywords. Metatags will help you define those, and will setup default metatags when those don't exist.

This module allows you to set some meta tags for each node. Giving more attention to the important keywords and/or description on some of your nodes allows you to get better search engine positioning (given that you really only provide the keywords which exist in the node body itself, and do not try to lie).

Tips :

• With all that's said about Site mojo and outgoing links, I still keep "all=index, follow" on most of the sites I run. I believe rel="nofollow" should mainly be used per link or per page and not as a general rule, but it does depend of the kind of site that you run.
• Make sure that "Use the teaser of the page if the meta description is not set" is enabled, and that tags are outputted in the html head.

Multiping

Pinging is used to notify ping sites that your site has updated so that crawlers will come and index the new content to include the changes made. Drupal still doesn't have good ping support and Multiping aims to fix that, allowing to add as many ping servers as you wish.

A replacement for the ping module of Drupal. It allows pinging of multiple sites (configurable via a web interface). If a site is unreachable, the ping request will be sent again during the next cron.php run.

Need a few preset ping servers? just import this to your database after setting Multiping up :

INSERT INTO `multiping` VALUES (4, 'http://bulkfeeds.net/rpc', 'http://bulkfeeds.net/rpc', 'weblogUpdates.ping', 1175127469, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (8, 'http://blogsearch.google.com/ping/RPC2', 'http://blogsearch.google.com/ping/RPC2', 'weblogUpdates.ping', 1175127469, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (9, 'http://rpc.weblogs.com/RPC2', 'http://rpc.weblogs.com/RPC2', 'weblogUpdates.ping', 1175127469, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (11, 'http://ping.feedburner.com/', 'http://ping.feedburner.com/', 'weblogUpdates.ping', 1175127470, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (12, 'http://rpc.blogrolling.com/pinger/', 'http://rpc.blogrolling.com/pinger/', 'weblogUpdates.ping', 1175127470, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (13, 'http://api.my.yahoo.com/RPC2', 'http://api.my.yahoo.com/RPC2', 'weblogUpdates.ping', 1175127470, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (17, 'http://rpc.weblogs.com/RPC2', 'http://rpc.weblogs.com/RPC2', 'weblogUpdates.ping', 1175127470, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (18, 'http://rpc.pingomatic.com/', 'http://rpc.pingomatic.com/', 'weblogUpdates.ping', 1175127470, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (19, 'http://rpc.technorati.com/rpc/ping', 'http://rpc.technorati.com/rpc/ping', 'weblogUpdates.ping', 1175127470, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (21, 'http://api.feedster.com/ping', 'http://api.feedster.com/ping', 'weblogUpdates.ping', 1175127471, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (22, 'http://api.my.yahoo.com/RPC2', 'http://api.my.yahoo.com/RPC2', 'weblogUpdates.ping', 1175127471, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (30, 'http://ping.feedburner.com', 'http://ping.feedburner.com', 'weblogUpdates.ping', 1175127471, 1, 1, 'N;', 0);
INSERT INTO `multiping` VALUES (32, 'http://ping.weblogalot.com/rpc.php', 'http://ping.weblogalot.com/rpc.php', 'weblogUpdates.ping', 1175127471, 1, 1, 'N;', 0);

Search404

Although disputed for its SEO value (positive/negative) I think it's worth mentioning this module and letting you decide this one on your own. It is important, however, that the pages that are not found return a "404 not found" message and not an "ok "message.

Instead of showing a standard "404 Page not found", this module performs a search on the keywords in the URL, e.g. if a user goes to http://example.com/does/not/exist, this module will do a search for "does not exist".

-

Last, not SEO related directly, but extremely important to keep your SEO components up to date and bugs free is the Update module, which should really make it into core. If you're using 4.7 or maybe you're interested in upgrading to dev releases, then you should consider installing Release Monitor instead.