Advanced Page Title Tags Using Drupal Views

In Part 1 of Page Title Tags in Drupal we looked at setting your front page and individual page <title> tags.  But reviewing our Google Webmaster Tools report on HTML Improvements, we saw that it reported five Duplicate Title Tags.

Duplicate title tags

These are all Blog archive pages, generated by Views to show teasers of all our blog posts published in a single month.  They are all just using the default - <title>FireRoad Blog | FireRoad Digital</title>.  So we need to enable a Metatag sub-module to let us set <title> tags for pages created by Views.  Look under SEO in admin/modules and enable Metatag: Views.
Drupal metatag module enable Views
This will add a new option inside all of your Views to set Meta Tags.  Edit one of your Views and you should see this in the middle section of the initial admin edit screen:
Drupal Metatag settings link inside of a Views edit screen
Out of box it is set to use defaults, which if we click through shows us:
Drupal Metatag module Views defaults
So, similar to the default for individual nodes, but using the [view:title] token rather than the [node:title] token.  So what is the [view:title] token set to?  Click on the appropriate View Display and look under Title.  For our main /blog page, it is set to ..
Drupal View page title

If we look at the source for the /blog page, the title tag is then appropriately set to <title>FireRoad Blog | FireRoad Digital</title>, following the rule set under the Metatag config we saw above.  And that's fine for that page.  But we need to differentiate each of the archive pages.  Each situtation will be different - you may need to find a token that you can use that is specific to that page, like the date or a username.  We are using a contextual filter to restrict the view to just show blog posts for that month and setting the title using the name of that month an the year, so we get a unique <title> tag for each month.  Such as <title>FireRoad Blog: December 2014 | FireRoad Digital</title>.  Just figure out a token or such that will make each page title unique.  And no more duplicate page titles ... and complaints from Google Webmaster Tools!  You can see all the available tokens if you click on the Open Graph option on the View's Metatag configuration and click on Browse available tokens (not sure why it got put there...)
Don't forgot to do the same for the Description meta tag.  We'll cover that in a future post.

Page Title Tags in Drupal - Make Them Descriptive and Unique

Your page title tag might just be the most important factor in on-page SEO.  And yet most Drupal sites pay it little attention- leaving it to Drupal defaults and resulting in a site full of uncompelling and ununique page titles.  And I'm not sure either of those are actual words.

So besides not making up perfectly cromulent words in your page title, what should you do with it?  Well, first let's look at how Google and other search engines use the data in the <title> tag.  Here is what Google search was returning for "fire road digital" when we first set up our site earlier this year.

The first line is often going to come from the <title> tag on your home page, although for the past year or so Google may choose something else it thinks is more relevant to the search (also known as dynamic page titles).  But still best to deliberately set it the best you can. The lower line (or the snippet) is coming from our meta description tag (usually- same caveat as the page title) - we'll cover those in another blog post.

Is that a good page title?  Meh.  Our company name + a "|" thingy + most of a summary of what we do.  We can do better.

In general, a good page title should be very relevant to its page and contain keywords for which you want that page to be found.  You usually get found readily for your own company name (unless it is highly generic or competitive), so little need for that in your title.  Plus it is already in the URL below.  If you are a major recognizable brand, you might want to include it, or if you have room at the end, go ahead.  "Drupal Web Development" are good keywords for us.  "Internet Marketing" - maybe, somewhat generic and probably not what people search for.  Hint: you'd be surprised how often people add "best" to the front of their Google searches ... nudge nudge, wink wink.

So, figure out 65-ish characters of the top keywords that you want to be found for that page and assemble them into a coherent, non-spammy phrase with the most important keywords toward the beginning, and do so for each page on your website - each one should be unique, targeted and relevant to that page.  Do not keyword stuff - make it sound reasonable and relevant.  65 characters is around the most that Google will show.

Ok, so we need to update ours (or at least what we suggest Google uses).  By default, Drupal uses "<node title> | <site name>" for each page on your site, except the front, where it just uses <site name>.  So we are going to need some help from a contributed module to give us more options.  We are using the multi-purpose Metatag module - there is a more singlular-purpose Page Title module, but Metatag does everything it does and more, and the two can conflict, so just use Metatag.

Once installed by the method of your choosing, look under SEO on admin/modules and enable Metatag. Go ahead and enable the Metatag:Open Graph sub module- we won't talk about it this time, but it will help you with Facebook (more to come!).  Make sure that the Page Title module is not enabled - it can conflict.  Navigate to admin/config/search/metatags to configure.  If you expand the Global: Front page and Node (might instead say Content) sections, it should look something like this (same as default Drupal): 

Default settings for Drupal Metatag module

Being super-skilled Drupal people, we had already installed and done basic configuration of the Metatag module before we launched.  Here is our original configuration for the front page:

Let's update the front page first.  Click on Edit to the right of Global:Front page.  In the Page Title field, enter your front page page title.  We changed ours to "Drupal Web Development, Marketing Automation and SEO in Dallas, TX".  Our niche is highly-skilled technical Drupal development focusing on site configuration for optimal on-page SEO.  We also believe that marketing automation is going to explode in 2015 and we want to help small businesses use it, and we really like working with local Dallas companies.  So that's how we want to be found.  Edit yours and Save.

If you expand the Node (might be Content) link it will give you default options for individual content pages (via the Override link), using Tokens.  The default is probably ok for your site to get started.  If you are properly constructing the title of each of your content pages with keywords, then you will get a good <title> tag for those pages.  You may want to change the default to fit your particular site situation.  The Metatag module also now lets you super-optimize individual pages under the Metatag >> Page Title field on each content page.  Work on them one-by-one as you can.

Google Webmaster Tools is great for checking that sitewide all your page titles exist, are unique, the right size and informative.  Here is what it said about FireRoad:

All good except for five duplicate title tags !?  What did we do wrong?  Well, nothing really - but there is one more thing we need to do.  And it's a little more complex, so we will save it for another post.  Hint: it involves Views!

Drupal 101 Evening Course in Dallas in January

Now in its fourth year, Collin College Continuing Education is offering a 6 week, 18 total hour introductory course in Drupal Website Development 101.  Six consecutive Tuesdays, January 20th - Feburary 24th, from 6:30 to 9:30 pm.  The cost is $199.  More info.

What can you expect to learn?

  • Introductory Drupal website development concepts and building blocks
  • Drupal website hosting and maintenance
  • Installing modules and themes
  • Top 20 Drupal modules
  • Basic Drupal SEO principles and modules
  • and how to create several complete Drupal websites with different functionality

The only prerequisite is basic Internet and web usage experience, and a tolerance for the instructor's stupid sense of humor.  This 101 course won't have any software coding / programming.

The Drupal course will be taught at the Collin College Courtyard Campus in Plano, near Preston and Park.  Computers are provided.  Nice ones too.  Only while in the class though, you can't take them home.

More info and register!

Dealing With Email On Drupal Development Sites

Sometimes, even when you've worked with a system for a long time, you can still uncover surprising things that have been around for awhile but were previously unknown to you.

Such was the case for the Reroute Email module. Maybe you've already heard of it, but I had not. In fact, for years, I've dreaded working on email issues for existing sites with notification systems, fearing I would spam live site users. In at least one case, I've sent an inadvertent content update notification to a not-so-small user population. Fortunately, I wasn't using Samuel L Ipsum to generate dummy content or things could have gotten much more uncomfortable.

Recently, I had the great idea of writing a module to intercept site emails and redirect them to a different, safer address. I followed this with the thought, "I wonder if a module like that already exists," and as is so often the case with Drupal, the answer was, "of course." In fact, this functionality has been around since the days of Drupal 5, and appears to have been part of the devel module before splitting off on its own. That's a long time to fly under my radar, especially considering the are nearly 375,000 reported downloads.

Why You Might Want To Use It

Many sites use notification systems to send emails to users when you change existing content or publish new content. Some sites send out notification emails to users as content goes through a moderation workflow. A site may send out emails to e-commerce customers or in response to contact form submissions. The list goes on and on.

What happens, though, when you pull the database down to your local development environment? Maybe you were able to sanitize the database with Drush when you pulled it, or maybe not. You may think your sanitization caught every email address on your site, but it probably didn't (think Rules or contact form or update notifications). Are you really going to remember to change all those email addresses every time you sync the database? Maybe the first time and the second time, maybe even the third or fourth time. If you're like most people though, you'll eventually decide that it's not necessary, since you're "not working on email right now; plus, it's such a pain."

That's where Reroute Email comes in.

Installation and Configuration

I'm assuming you already know how to install a Drupal module, so I'll spare you those particular details. The main idea is to configure things so Reroute Email is automatically setup in environments where you need it. In this case, we're talking about your local development environment.

The first thing to do is to ensure that the module gets enabled whenever you synchronize the database locally. This is easy if you use drush and sql-sync or sql-sync-pipe. Just add a target-command-specific element to your Drush alias:

'target-command-specific' => array(
 'sql-sync' => array(
   'enable' => array('reroute_email'),
 'sql-sync-pipe' => array(
   'enable' => array('reroute_email'),

After that, it's just a matter of setting variables in your local settings.php to configure it the way you want:

// This setting allows you to defeat Reroute Email even if 
// it's enabled in the Drupal system sense, so make sure it's
// set to "1"
$conf['reroute_email_enable'] = 1;

// Specify where you want to redirect emails. You can 
// define more than one email by separating them with
// spaces, commas or semicolons
$conf['reroute_email_address'] = 'me@mydomain.com';

// Adds an extra message to the body with information
// about the redirection
$conf['reroute_email_enable_message'] = 1;

Keep in mind that if you set these values in your local settings.php, you cannot override them by changing them in the UI (i.e., Admin >> Configuration >> Development >> Reroute Email).

You can send a test email through the module from Admin >> Configuration >> Development >> Reroute Email >> Test email form.


There is always a caveat, isn't there? Reroute Email uses hook_mail_alter() to do its work, so if any of your modules send mail in any way except through drupal_mail() (e.g., by calling drupal_mail_system()->mail() or PHP mail() directly), they will bypass this hook and thus not get redirected.

Of course, since it uses hook_mail_alter(), Reroute Email should work with any standard Drupal mail mechanism, whether you're using just the default Drupal mail or something more complex, like Webform with MailSytem, MimeMail and SMTP Authentication.

Note that if your site is setup with the default Drupal mail, you may also need to setup outgoing mail on your local development environment. It doesn't seem like this is something that would be that difficult, but it can get quite tricky.

Do One Thing Well

Reroute Email is a small module that has been around for a long time. It does one really useful thing and it does it simply and well. If only we could say that about more Drupal modules.

Get Insights from Google about your Drupal Website using Webmaster Tools

Webmaster Tools, according to Google, is a "free service offered by Google that helps you monitor and maintain your site's presence in Google Search results" and "can help you understand how Google views your site and optimize its performance in search results."  It is an invaluable tool that you should be using.

Some of the things you can do with Webmaster Tools:

  • receive messages from Google about issues it has found with your site (including crawling and security issues)
  • be sure that Google can properly view all your content
  • understand which search querries are leading viewers to your site
  • see which websites are linking to your site (backlinks)
  • confirm that Google is reading your sitemaps
  • see how Google views your semantic microdata
  • find out recommended HTML improvements
  • learn if you have duplicate or short meta descriptions and page titles
  • see how fast your web pages are loading

This information covers the core of modern SEO practices.  But to view it and use it, first, you need to verify your site ownership with Google to begin using Webmaster Tools.  Which we hve covered in a previous blog post - Verify your Drupal Site!.  Do that first, then wait a few days for some data to accumulate.  Then come back here and we'll walk through a few of the most important Webmaster Tools reports.

First, let's look at the home page.  You should see all the sites you have added and verified.  And hopefully a "No new messages or recent critical issues." message for each.

Google Webmaster Tools home page

Click on your website name link to bring up the dashboard for your site.  If you have any messages, check those first.  It could be that Google can't index your Drupal site, or worse, that it found malware or a security issue.  Take care of those first- a security issue could get you completely blacklisted from Google!

Our example site below shows no messages or site errors that Google tracks.  There are some 404 errors shown under URL Errors.  You can learn more about those errors so you know what to fix under Crawl >> Crawl Errors.

You want to see those pretty little green checkmarks.  A upward trend on your Search Queries is also a good thing.

There's too much to cover completely here, but you should definitely check :

  1. Search Traffic >> Search Queries.  What terms are Google users searching for that leads them to your site.  There is also data on your click-through rate and the average position you show up on search results (10 per page).  Are these the terms that you want to be found for?  Are people seeing you in search results, but not clicking?  Here at FireRoad we once wrote a blog post about configuring a certain type of complicated large computer monitor we were using.  We get tons of traffic to that post, but it really isn't useful traffic since we don't sell or service those monitors.
  2. Search Traffic >> Links to Your Site.  Which sites link to your site?  Lots of quality links (that is, from sites that Google thinks highly of) helps your SEO.  it shows those sites respect your site and content enough to link to it.  Lots of un-quality links (that is, from Estonian link farms) can really hurt your SEO.  If you've been using offshore "$100 gets you on the front page of Google" link building services ... stop.  That might have worked years ago, but now it does the opposite.  You can also disavow any links that you don't want and request Google not consider them.
  3. Search Traffic >> Mobile Usability. Having a mobile-friendly website is critical now.  Google will tell you if it thinks you have issues with mobile usability.
  4. Search Appearance >> Structured Data.  If you are using semantic microdata on your site to better tell Google what your content means, it will show up here, along with any errors.  We will have a guide to using microdata on Drupal websites out soon.  You can also use Search Appearance >> Data Highlighter to manually identify it.
  5. Search Appearance >> HTML Improvements.  It only shows a few suggestions, but on important issues it may find on your meta descriptions, page titles and non-indexable content.
  6. Google Index >> Index Status.  Make sure all your pages are being indexed.
  7. Google Index >> Content Keywords.  What does Google think are the most relevant keywords on your website?  Are they want you want?  If not, change your content.
  8. Crawl >> Sitemaps.  Do you have a XML Sitemap on your website?  It helps Google understand your site structure.  It should show up here, and make sure all your pages are included.  If not, see our post on Setting up an XML Sitemap in Drupal.
  9. Other Resources >> PageSpeed Insights.  How fast does your site load?  The faster it loads, the better you will rank.

With very little work, you will be up and running with Google Webmaster Tools and using its free tools to better understand and improve your Drupal website.

Setting up Goals in Google Analytics for your Drupal site

"Setting goals is the first step in turning the invisible into the visible."
        - Tony Robbins

Quick - what percentage of all the visitors to your website use your Contact Us page to request more information?  On your "Download our Guide to Norwegian Cheeses" landing page, how many people give you their imformation and submit the form, and how many aren't convinced and decide to get their Norway cheese info somewhere else?  Are those numbers going up ... or going down?

You can't tell how well your page design and marketing efforts are working if you aren't measuring goals and conversions.  Fortunately for Drupal sites, with a little help from Google it's easy to do.

Let's start with your Contact Us page, and assume you are using the core Contact module.  If not, first set one up.  You will also need to set up Google Analytics and the related Drupal module if not already installed.  Once those are working, head over to Google Analytics, click on Access Google Analytics on the upper right side, select your website and All Web Site Data to get to your home Analytics page.  Look under Conversions >> Goals >> Overview to see all your configured goals ... which at the moment is likely none.

First step in setting up goals in Google Analytics

So let's set some up by clicking on the Set up goals button.  You should see this:

Click on +New Goal.  Google Analytics provides many templates for configuring your goal - choose Contact us and then Next Step.  You should then see this:

Step 2 of configuring a goal in Google Analytics

It is asking you to configure how you will consider this goal met.  The default type, and only one that makes sense for our Contact Us page is Destination, meaning that Google Analytics will consider the goal met when the user visits a certain page.  Specifically we need a thank-you page - a page that is only reached after the user submits the Contact Us form.  We can't use the URL of the Contact Us page itself - that only tells us that the user viewed that page, not that she submitted it.  After she clicks the Send Message button, she should then be shown a new page that thanks her for sending the message, and perhaps has some additional sales and marketing info on it.  But the important thing is that it is a different page, so we can track it.

Which is now a problem for us, as the Drupal core Contact module doesn't have the option to specify a redirect page that the site viewer is shown after submitting the Contact Us form.  When a user submits the form, she simply sees a standard green Drupal status message and stays on the Contact Us page, like this:

Not an especially good User Experience, and more importantly, it doesn't give us what we need to trigger the goal.  Adding that important functionality has been discussed for many years, and there is work going on now to put it into Drupal 8 ... but what do we do for all our Drupal 8 sites now?  We could use the Webform module to create our Contact Us page, which does have the redirect page option as well as many other additional features, but at the cost of highercomplexity and effort to implement.

Fortunately there is a perfect module that adds just the functionality we need - Contact Plus.  Install in your preferred manner.  Now, when we edit our sitewide contact form (Structure » Contact form >> Edit), we see a new configuration field for Redirect path.  

The default is to redirect to the front page, but that isn't useful.  Instead, create a new Basic Page that thanks the site user for submitting her info, promising them to get back to her shortly, and any other marketing messages you may want.  Set the URL to something like http://yoursitename.com/thank-you-for-contacting-us.  Put that entire URL into the Redirect path field (the module can't handle a relative path unfortunately) and save.

We now have what we need to finish configuring our goal in Google Analytics.  Go back to that browser tab, make sure Destination is selected and click Next step.

Enter just the relative path of your thank-you URL (the part after the site name) and click Create Goal. You can leave the other advanced options set to off. If you use a social tracking system that adds more characters to the end of all your website URLs (like ?JK8uejshl), then change Equals to to Begins with or your goal won't trigger.

We are done!  Well, except for viewing the results on Google Analytics, which right now there won't be any.  Run a test on your Contact Us form, wait a day or so for Google Analyics to record the event, then check back at Google Analytics, Conversions >> Goals >> Overview to see your goal completion data.  We will go into more advanced Goals and Conversions methods in a future blog post, but for now you working toward a goal.

And be sure to use the FireRoad Digital Contact Us form to see what you get after pressing Send Message!

North Texas Drupal November Meetup

We had a great meetup tonight with lots of interesting discussions on Drupal security, hosting, tools, drush and more.  And a visit from a Drupler from LA!  No meetup in December - we will see everyone in 2015.
Here's the notes and links I have from the meetup.

Drupageddon related links




VPN Setup

Cheap bulk emailing

Verify your Drupal Site!

To use most of the major search engines tools and apps with your website (Google Webmaster Tools, Bing Webmaster Tools (which also works with Yahoo! search), Google for Work, others) first you must verify you own the domain.  This can be done in several ways - updating some settings with your domain registrar, uploading a specific file to the root of your website, and setting a specific meta field on the front page of your website are the most common.  The Drupal Site Verification module can help you quickly verify your site using the latter two methods.  Install it first in your preferred manner.

We will look at verifying your site Google Webmaster Tools.  First log in using your Google account.  Next click on the orange ADD A SITE button on the upper right.  You should see this.

Add a site dialog box on Google Webmaster Tools

Enter your sitename and click Continue.  At this point, you might see one of few different screens, depending on what Google thinks is the Recommended option for you to verify your site.  If the HTML file upload method isn't under Recommended method, then click on Alternate methods.

Google Webmaster Tools Recommended method to verify site ownership

To use this method, first click on the link to this HTML verfification file to download it.  Then in another browser tab, we will use the Drupal Site Verification module you installed earlier to upload it to your site.  Navigate to admin/config/search/verifications. Then click on the +Add Verification link.  Select Google from the drop-down list, then click on Next

Drupal Site Verification module configuration screen

You can upload the verification file Google gave you here.  If you chose the META tag option, you can cut and paste it from the Google page to the field here.  Click Save.  Go back to your Google Webmaster Tools tab and click on the red VERIFY button.  It should give you a confirmation screen.

That's it!  You are verified and have the Seal of Approval!  I'll bet you were wondering what the seal cover image had to do with site verification. We're funny, that's what!  Kinda funny anyway.

Drupageddon: Aftermath

By now you've heard about the Drupal core vulnerability commonly referred to as Drupageddon. Let's look at some common questions.

How Bad Was It?

The Drupal community freaked out. Actually, the Internet community freaked out. Was the freakout justified? Unfortunately, the answer is yes. The vulnerability allows anonymous users potentially unfettered access to PHP and the site database and as soon as the Drupal Security Team announced it, the world knew about it. Within seven hours of the announcement, there were already reports of automated attacks.

There was a report that "at least 12 million" sites had been compromised, but the report based this number on bad assumptions, so you should ignore it, much in the way you should ignore numbers in advertisements qualified with "up to" or "results not typical".

What Was It?

Essentially, the vulnerability allowed savvy site visitors to perform arbitrary operations on the site database. There is an excellent post explaining what the issue was if you're interested in the technical details. Once an attacker gained a foothold in the database, then that opened the door to executing arbitrary PHP code and from there, your world was his (or her) oyster.

Has It Been Fixed?

Yes, Drupal 7.32, released in conjunction with the security announcement, fixed it. Update your Drupal core to that version, or at least apply this patch.

Can I Tell If My Site Has or Hasn't Been Compromised?

You can check for some of the known attack patterns to prove that your site has been compromised, but unfortunately, you cannot prove that your site was not compromised. Attacks could have done their dirty work and then left no trace. They could have left a backdoor that didn't follow any of the known attack patterns. As with many things, it's difficult to prove a negative.

What Is The Safest Thing To Do?

The Drupal Security Team released a frightening (and accurate) PSA that recommended rebuilding your server and restoring your site (code, files and database) from a backup made before October 15. Yes, that means what you think it means.

Do I Really Have To Rebuild Everything?

Per the Drupal Security Team, that's the safest thing to do. You don't have to do it, you merely assume more risk if you don't. Fortunately, there are also some potentially mitigating circumstances. If you host your site with one of the big Drupal-centric hosts, then your risk could be reduced if your host rolled out protections along with the security announcement. Both Acquia and Pantheon posted they had done this. Other hosts may have implemented protective measures as well, but the less Drupal-centric your host, the less likely that would be.

You can also check for some of the known attack patterns. While their absence doesn't mean that your site has not been compromised, it could affect your decision with regard to the risk you are taking by not rebuilding.

  • If your source code is under version control (like git), check to see if your codebase has been modified or if there are new files that have been added.
  • Check your uploaded files (which are normally not under source control) to see if there are any PHP files.
  • If you don't have your source under version control, you can still check for any PHP files (not just in the uploaded files, but everywhere). Be aware that there are plenty of legitimate reasons for a PHP file to exist in your codebase, so don't delete indiscriminately.
  • If you have access to your database, either through the command line or a UI, check the menu_router table for suspicious callback values, like file_put_contents, php_eval, or assert.
  • Look for any suspicious users, especially ones with the administrator role.
  • Look for blocks or fields using the PHP Code text format. Inspect them for suspicious content.

It is likely that more patterns will emerge, so keep an eye on your favorite Drupal blogs for updates.

Want more options? Here's a flowchart detailing how you can evaluate your site along with some recommended actions.

Setting up an XML Sitemap in Drupal

Google and the other search engine crawlers do a decent job of finding their way around your website. But, sometimes they could use a little help, as well as to understand the relative importance of your web pages and how often they are updated.

This can be done with an XML Sitemap.  And of course, there is a very popular Drupal contrib module for it - aptly named, XML Sitemap. Installation is easy, but you will need to configure a few things before it starts doing its magic.  We will look at the Drupal 7 version.  And as always, it's good to have a site and database backup before you start.  We are using the currently released version- 7.20.

So, after installing the module in one of the usual ways, a new section in /admin/modules will appear - navigate down toward the bottom :

Enable XML sitemapXML sitemap engines, and XML sitemap node (as shown above).  And Save.

Now we need to prepare our content to be added to our XML sitemap.  Edit the structure of each content type you want added to the sitemap (such as a Basic page - admin/structure/types/manage/page), then click on the XML Sitemap vertical tab near the bottom left.  Then under Inclusion, select Included.  For most pages you can leave the default priority as is, or change it for frequently or infrequently updated pages.  Then click Save.  Do the same for any other Content Types you wish to include.

Drupal configuration screen to include content in an XML Sitemap

When the XML sitemap module was first installed, it will have created a default (but empty) XML sitemap.  Next we need to rebuild it so it will pick up all the new pages we configured the Content Types to include.  Navigate to /admin/config/search/xmlsitemap

Click on the Rebuild Links tab, then when it changes, click on the Rebuild sitemap button (even though it may tell you that you don't need to).  When done, you should see some numbers shown under Links and Pages.  See if this is about right for your site.  You can view more details on pages in your sitemap and priorities under the Settings tab.

The only thing left to do is tell it to submit your new sitemap to the search engines.  Click on Search Engines and check Google and Bing.  Save.  Done!  Wait a day and check on your Google Webmaster Tools account that it is receiving your XML Sitemap.  You don't use Webmaster Tools !?  You should!  It's free and packed full of information from Google on how your site works with its search.  Look for an article here soon on how and why.  You'll notice the module also suggests you verify your site using the Site Verification module.  Good advice!  We'll cover that soon too, although it's fairly easy to use.