Those who dance are considered insane by those who can't hear the music.
In my first post I gave an overview of Google Webmaster Tools.
In this second post I am going to look at some of the key areas that I have found useful when reviewing a site listing in Google from a Drupal developers point of view.
These area of interest are: Crawl Errors, Fetch as Google and Sitemaps.Crawl details
Once logged in to Google Webmaster Tools and selected the site I want to deal with, I have found the ‘Crawl’ section (on the left hand side) to be one of the most important areas.
Here you can get information on what site pages Google has crawled, including various errors and details about how many URLs have been indexed from your sitemap.xml file.
This section is broken into the different types of errors:
- Server error
- Soft 404
- Access denied
- Not found
- Not followed
Server error: These are any URLs that have returned too slowly or are blocking Google in some way. This would typically be pages causing errors on your site, so they should be dealt with fairly urgently.
Soft 404: These pages are interesting. They are like ‘Not found’ pages, but they aren’t strictly invalid pages as they aren’t returning a 404 header response. Google’s 'help' details these pages as:
‘A soft 404 occurs when your server returns a real page for a URL that doesn't actually exist on your site. This usually happens when your server handles faulty or non-existent URLs as "OK," and redirects the user to a valid page like the home page or a "custom" 404 page.'
In some cases, these pages could be search pages which take in various query parameters to determine the search criteria. As the search content changes, the results of certain criteria may return no results.
This type of page can also be seen as a ‘soft 404’ page.
Google recommends setting up your robots.txt file to not index such search pages as the content could be misleading. If you are providing a sitemap.xml file this should contain all of your sites content for Google to index.
Access denied: These are fairly obvious - they are pages that Google can not access.
This might be due to authentication being required or just that Google is being blocked from seeing the page. It's worth keeping an eye on these pages as it might be that you have an error on a page that is preventing Google from accessing it etc.
Not found: These are also fairly obvious - they are pages that Google can not find or are returning a 404 header response.
This might be due to the page changing URL or just that the page no longer exists. It is worth keeping an eye on these pages as it might be that you have removed some pages and you didn’t realise that there was a link on a page on your site (or indeed on someone else's site) that is linking to that page.
In the event that the URL has just changed, but the page that this was referring to still exists, it is advisable to provide a redirect from the old URL to the new URL so that Google can reindex the correct URL. This should be done using a 301 redirect and can be achieved using a htaccess file.
Not followed: These are pages that Google tried to follow but couldn’t for some reason.
Other: This is more of a ‘catch all’ for any pages that couldn’t be accessed but don’t fall into any of the categories above.What can you do with the list of URLs?
Within each of the above sections, if there are any URLs found, a list will be presented. Clicking on one of the URLs will open up further useful information:
- Error details: When this error was first detected and why etc.
- Linked from: Where this URL is linked from (either your own site or external sites)
- ‘Fetch as Google’: Useful button to see what Google actually sees when it visits the URL
You can also mark URLs as being ‘fixed’, i.e that they should no longer appear in that list.
This will remove them from the list, but if Google detects them again they will get added back.
However, if your content has been ‘fixed’ the URL will automatically be removed from the relevant list when Google crawls that site, you removing it seems to be more for your own sanity and ease of seeing what is still to be sorted out.Fetch as Google
This is a useful little section that enables you to enter a page URL for your site and see what Google sees for that page when it is crawling the site.Sitemaps
If you have provided a sitemap.xml file to Google than this will provide further details on the number of the pages that the sitemap contains against the number of pages that Google has actually indexed.
Google says that it won’t guarantee to index all the sites pages, so don’t expect this to match up, but it does give you a good indication on the number of pages that Google is actually aware of.Other resources
To be honest, I haven’t looked through all the items in here yet, but the main one that I have used is the Pagespeed insights.
This is a great little tool that analyses your site URL and tells you how it can perform better and faster. This is always worth having a look at to see how your site is performing, as sometimes small changes can make a big difference.In Part 3...
I will analyse how data from Google Webmaster Tools helps me understand sites better and improve their standing in Google, complete with examples.Follow @deeson_labs for all the latest blogs!
Read moreGoogle Webmaster Tools - Part 2: Key areas in more detailBy Mike Davis | 30th June 2014
View modes by View provides a report that shows you which views are using which view modes.
View modes are great, but once you have more than one or two, it's difficult to remember where they're being used – and if you're coming onto an existing project, you don't have that history to rely on. This module supplies that bird's-eye view of where you view modes are being used.
As you may have read last week, we're starting up a Drupal 8 CX initiative which will feature a site for tracking the status of Drupal 8 module ports.
We'll be displaying a curated list of modules that we've identified as priorities for Drupal 8. But in order for others to build their own site to track their own priorities, we're building the site using an install profile.
Because I'm using an automated phing task to 'burn and reinstall' the site on a regular basis, I needed a simple lightweight solution for default content - for things like blocks (using bean) and basic nodes.
Read-on to see my approach.
Here at EchoDitto, we make extensive use of the Display Suite module, which means that we also use a lot of view modes. Today, I've released a module to help project managers, developers, and themers manage their view modes by providing a simple tool: a report that shows you which views are using which view modes. If you know what that means and why you'd want such a report, great! Install the module and be on your way. If not, read on.
A view mode is a particular combination of a content type's fields, laid out in a particular way. Two of the most well-known view modes are "full" (for when you're viewing a node by itself) and "teaser" (usually a short version of a node that includes a link to the full node). Drupal 7 ships with several view modes and Display Suite provides a UI for creating custom ones.
Almost every website makes some use of view modes. For instance, if you have a blog on your website, you probably want to feature those posts in at least three different ways:
- A short version of the post, that includes the title, the author, and the first few sentences, for use on the list of all posts in your blog. This would be the "teaser" view mode.
- An ever shorter version, that consists of just the title and the date it was published, for a "Posts by this Author" block on a user's profile. We could call this the "list" view mode.
- The post itself (you're looking at one now)! This is the "full" view mode.
In most cases, you would create the lists of posts (the blog itself, and the "Posts by this Author" block) using the Views module.
View modes are extremely useful for a number of reasons. They help ensure that your content is laid out consistently – wherever you use a particular view mode, you can be sure that the same group of fields appears, in the same order. Done right, the use of view modes can also cut down on theming time - style a view mode once, and you can display content using that view mode in many places on your site without needing to re-theme it.
While view modes allow for great flexibility, they also increase complexity. It can quickly become difficult to remember where you have used a certain view mode – and that's assuming you were the person who built the site. If you're coming on to an existing project, you won't have that option. And either way, the only way to see which view mode is in use on a particular section of your site is to inspect the markup (not a great option for project managers) or to look at the view itself (not great for all project managers or themers, and tedious for developers). Regardless of how you find out which view mode is being used, you still can't see all the places the view mode is in use at once.
The module that I released, View Modes by View, helps you manage your view modes by providing a report showing which views are using which view modes. It provides that bird's-eye view in a way that all site builders can understand and reference.
Let me know in the comments or in the issue queue how this module works for you.
XHProf is a great server-side performance profiler. And as we say in our Drupal community… "there is a module for that". Great as it is, the Drupal XHProf module comes with little documentation. So finding out how and where to install some of the unmentioned bits and pieces can be a chore. Especially when you find yourself faced with downloading and compiling various components on a machine that doesn’t have the full gamut of tools like pecl, apt-get or Homebrew, etc ready to go.
So this is what I normally do for Macs, greatly facilitated by Cameron Tod's very handy page.
o Let’s start on familiar Drupal grounds. Install the XHProf module. The module allows you to easily flick profiling on and off, without the need for defining an additional virtual host and accompanying special domain. The module also comes with some nice touches like selecting the verbosity of the XHProf output and not running XHProf on admin pages.
o The page ..../admin/reports/status/php on your Drupal site will tell you which PHP configuration file (php.ini file) your site has loaded. Edit that php.ini, adding these lines:
extension = xhprof.so
xhprof.output_dir = ...
On a Mac, typical candidates for filling out the above dots are /Users/USERNAME/Sites/xhprof/runs or /tmp/xhprof. Whatever you choose, make sure to create that directory or the xhprof module will spit the dummy. Keep in mind that the /tmp directory is automatically cleared upon startup, so you’ll have to create /tmp/xhprof again after a reboot.
o On https://github.com/cam8001/php-xhprof-mamp select the pre-compiled version of xhprof.so that corresponds to the PHP version you found above. Drop the xhprof.so in /Applications/MAMP/bin/php/php5.x.x/lib/php/extensions/no-debug-non-zts-200xxxxx/, replacing the x'es with your PHP version and date. If you've done this correctly then after restarting MAMP and refreshing the page .../admin/reports/status/php will display a xhprof section.
o In a Terminal window type these commands:
curl http://pecl.php.net/get/xhprof > xhprof.tgz
tar -xzf xhprof.tgz
mv xhprof-* xhprof
# or: mkdir /tmp/xhprof
o Visit .../admin/config/development/xhprof and tick the “Enable” box. Accept the remaining defaults for now. You can revisit these later.
o Visit the home page, or any other page of your site. Scroll UP to see a link “XHProf output” at the very bottom of your browser window. Click that link and a list of the top 100 suspects should come up.
In a follow-up article we'll demonstrate how XHProf can help you discover where exactly server-side performance is lost on your site and a handy module that came out of that.File under: Planet Drupal
This module adds a Rules Action that would allow posting to user's Facebook Wall.