rssubmit.com Webmasters-Blogs-Resources

Webmaster Level: All

You may have heard that here at Google we’re obsessed with speed, in our products and on the web. As part of that effort, today we’re including a new signal in our search ranking algorithms: site speed. Site speed reflects how quickly a website responds to web requests.

Speeding up websites is important — not just to site owners, but to all Internet users. Faster sites create happy users and we’ve seen in our internal studies that when a site responds slowly, visitors spend less time there. But faster sites don’t just improve user experience; recent data shows that improving site speed also reduces operating costs. Like us, our users place a lot of value in speed — that’s why we’ve decided to take site speed into account in our search rankings. We use a variety of sources to determine the speed of a site relative to other sites.

If you are a site owner, webmaster or a web author, here are some free tools that you can use to evaluate the speed of your site:

• Page Speed, an open source Firefox/Firebug add-on that evaluates the performance of web pages and gives suggestions for improvement.
• YSlow, a free tool from Yahoo! that suggests ways to improve website speed.
• WebPagetest shows a waterfall view of your pages’ load performance plus an optimization checklist.
• In Webmaster Tools, Labs > Site Performance shows the speed of your website as experienced by users around the world as in the chart below. We’ve also blogged about site performance.

• Many other tools on code.google.com/speed.

While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page. Currently, fewer than 1% of search queries are affected by the site speed signal in our implementation and the signal for site speed only applies for visitors searching in English on Google.com at this point. We launched this change a few weeks back after rigorous testing. If you haven’t seen much change to your site rankings, then this site speed change possibly did not impact your site.

We encourage you to start looking at your site’s speed (the tools above provide a great starting point) — not only to improve your ranking in search engines, but also to improve everyone’s experience on the Internet.

Posted by Amit Singhal, Google Fellow and Matt Cutts, Principal Engineer, Google Search Quality Team

Webmaster Level: All

We’ve been hearing this question for many years from webmasters. That’s why we built features such as the Safe Browsing API, the malware review form, and our Malware details Labs feature.

As of today, once we notice your site is infected, we’ll do our best to send an e-mail to the address you have associated with your account in Webmaster Tools. We believe malware is such an important issue for site owners that being quickly informed is beneficial to you and your website’s visitors.

In addition, we’ve promoted our Malware details feature out of Labs and placed it under Diagnostics. The malware data is now updated four times faster than before, we’ve updated our algorithms for identifying injected content, and we’re now able to identify exploits which we were unable to catch earlier.

We hope this allows you to stay up-to-date with any malware issues we detect on your site, and to fix them quickly.

As always, please let us know if you have any feedback or questions about how to fix malware-related issues in our Webmaster Help Forum.

Posted by Sagar Kamdar, Product Manager, Webmaster Tools Team

Webmaster Level: All

Sitemaps are an invaluable resource for search engines. They can highlight the important content on a site and allow crawlers to quickly discover it. Images are an important element of many sites and search engines could equally benefit from knowing which images you consider important. This is particularly true for images that are only accessible via JavaScript forms, or for pages that contain many images but only some of which are integral to the page content.

Now you can use a Sitemaps extension to provide Google with exactly this information. For each URL you list in your Sitemap, you can add additional information about important images that exist on that page. You don’t need to create a new Sitemap, you can just add information on images to the Sitemap you already use.

Adding images to your Sitemaps is easy. Simply follow the instructions in the Webmaster Tools Help Center or refer to the example below:

<?xml version="1.0" encoding="UTF-8"?>
  <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
   xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>http://example.com/sample.html</loc>
    <image:image>
        <image:loc>http://example.com/image.jpg</image:loc>
    </image:image>
  </url>
</urlset>

We index billions of images and see hundreds of millions of image-related queries each day. To take advantage of that traffic most effectively, take a moment to update your Sitemap file with information on the images from your site. Let us know in the Sitemaps forum if you have any questions.

Posted by Alkis Evlogimenos, Software Engineer

Webmaster level: All

Change can happen—sometimes, as we saw in our previous post on URL removals, you may completely block or remove a page from your site. Other times you might only change parts of a page, or remove certain pieces of text. Depending on how frequently a page is being crawled, it can take some time before these changes get reflected in our search results. In this blog post we’ll look at the steps you can take if we’re still showing old, removed content in our search results, either in the form of a “snippet” or on the cached page that’s linked to from the search result. Doing this makes sense when the old content contains sensitive information that needs to be removed quickly—it’s not necessary to do this when you just update a website normally.

As an example, let’s look at the following fictitious search result:

To change the content shown in the snippet (or on the linked cached page), you’ll first need to change the content on the actual (live) page. Unless a page’s publicly visible content is changed, Google’s automatic processes will continue to show parts of the original content in our search results.

Once the page’s content has been changed, there are several options available to make those changes visible in our search results:

1. Wait for Googlebot to re-crawl and re-index the page
   This is the natural method for how most content is updated at Google. Sometimes it can take a fairly long time, depending on how frequently Googlebot currently crawls the page in question. Once we’ve re-crawled and re-indexed the page, the old content will usually not be visible as it’ll be replaced by the current content. Provided Googlebot is not blocked from crawling the page in question (either by robots.txt or by not being able to access the server properly), you don’t have to do anything special for this to take place. It’s generally not possible to speed up crawling and indexing, as these processes are fully automated and depend on many external factors.

2. Use Google’s public URL removal tool to request removal of content that has been removed from someone else’s webpage
   Using this tool, it’s necessary to enter the exact URL of the page that has been modified, select the “Content has been removed from the page” option, and then specify one or more words that have been completely removed from that page.

   

   Note that none of the words you enter can appear on the page; even if a word has been removed from one part of the page, your request will be denied if that word still appears on another part of the page. Be sure to choose a word (or words) that no longer appear anywhere on the page. If, in the above example, you removed “top secret velocitus incalculii capturing device,” you should submit those words and not something like “my project.” However, if the word “top” or “device” still exists anywhere on the page, the request would be denied. To maximize your chances of success, it’s often easiest to just enter one word that you’re sure no longer appears anywhere on the page.

   Once your request has been processed and it’s found that the submitted word(s) no longer appear on the page, the search result will no longer show a snippet, nor will the cached page be available. The title and the URL of the page will still be visible, and the entry may still appear in search results for searches related to the content that has been removed (such as searches for [velocitus incalculii]), even if those words no longer appear in the snippet. However, once the page has been re-crawled and re-indexed, the new snippet and cached page can be visible in our search results.

   Keep in mind that we will need to verify removal of the word(s) by viewing the page. If the page no longer exists and the server is returning a proper 404 or 410 HTTP result code, making us unable to view the page, you may be better off requesting removal of the page altogether.

3. Use Google Webmaster Tools URL removal tool to request removal of information on a page from your website
   If you have access to the website in question and have verified ownership of it in Google Webmaster Tools, you can use the URL removal tool there (under Site Configuration > Crawler access) to request that the snippet and the cached page be removed until the page has been re-crawled. To use this tool, you only need to submit the exact URL of the page (you won’t need to specify any removed words). Once your request has been processed, we’ll remove the snippet and the cached page from search results. The title and the URL of the page will still be visible, and the page may also continue to rank in search results for queries related to content that has been removed. After the page has been re-crawled and re-indexed, the search result with an updated snippet and cached page (based on the new content) can be visible.

Google indexes and ranks items based not only on the content of a page, but also on other external factors, such as the inbound links to the URL. Because of this, it’s possible for a URL to continue to appear in search results for content that no longer exists on the page, even after the page has been re-crawled and re-indexed. While the URL removal tool can remove the snippet and the cached page from a search result, it will not change or remove the title of the search result, change the URL that is shown, or prevent the page from being shown for searches based on any current or previous content. If this is important to you, you should make sure that the URL fulfills the requirements for a complete removal from our search results.

Removing non-HTML content

If the changed content is not in (X)HTML (for example if an image, a Flash file or a PDF file has been changed), you won’t be able to use the cache removal tool. So if it’s important that the old content no longer be visible in search results, the fastest solution would be to change the URL of the file so that the old URL returns a 404 HTTP result code and use the URL removal tool to remove the old URL. Otherwise, if you chose to allow Google to naturally refresh your information, know that previews of non-HTML content (such as Quick View links for PDF files) can take longer to update after recrawling than normal HTML pages would.

Proactively preventing the appearance of snippets or cached versions

As a webmaster, you have the option to use robots meta tags to proactively prevent the appearance of snippets or cached versions without using our removal tools. While we don’t recommend this as a default approach (the snippet can help users recognize a relevant search result faster, and a cached page gives them the ability to view your content even in the unexpected event of your server not being available), you can use the “nosnippet” robots meta tag to prevent showing of a snippet, or the “noarchive” robots meta tag to disable caching of a page. Note that if this is changed on existing and known pages, Googlebot will need to re-crawl and re-index those pages before this change becomes visible in search results.

We hope this blog post helps to make some of the processes behind the URL removal tool for updated pages a bit clearer. In our next blog post we’ll look at ways to request removal of content that you don’t own; stay tuned!

As always, we welcome your feedback and questions in our Webmaster Help Forum.

Posted by John Mueller, Webmaster Trends Analyst, Google Switzerland

Webmaster Level: All

We try to communicate with webmasters in lots of different places. For example, when we send representatives to conferences we’re happy to participate in public site clinics where we share best practices on how to improve the crawlability and site architecture of websites suggested by the audience.

However, we also want to help users who can’t or don’t want to attend search conferences. To reach more people, we started doing free virtual site clinics in languages other than English. These site clinics help site owners make websites in such a way that they are more easily crawled, indexed, and returned by search engine crawlers, which in turn helps webmasters gain more visibility on the web.

We did a series of free virtual site clinics in Spanish last year which spanned 5 blog posts. The clinics covered real problems on real sites, and we posted the results on the Spanish Webmaster Central blog. If you read Spanish, I recommend you go read the different posts covering everything from issues with framed sites, to more technical domain setup.

In some countries we don’t have dedicated webmaster-focused blogs, but we still want to help webmasters in those countries. That means that you might occasionally see site clinic or webmaster-related posts on AdWords blogs such as the forthcoming ones on the Nordic AdWords blogs (which cover Danish, Finnish, Norwegian and Swedish). Recently when we posted some advice for webmasters on one of our AdWords blogs, we received questions about the relationship between Google’s search and advertising programs. We wanted to again reassure our users that the ranking of Google’s organic search results is entirely separate from our advertising programs. Furthermore, we do not give any preference to AdWords customers in our site clinics – everybody is welcome to participate. We’re simply posting this on local “AdWords” blogs because it’s the best way for us to reach webmasters in those communities and languages.

Written by Jonas Voss, Search Quality Team

Webmaster Level: Advanced

A few weeks ago, we introduced a new way of verifying site ownership, making it easy to share verified ownership of a site with another person. This week, we bring you another new way to verify. Verification by DNS record allows you to become a verified owner of an entire domain (and all of the sites within that domain) at once. It also provides an alternative way to verify for folks who struggle with the existing HTML file or meta tag methods.

I like to explain things by walking through an example, so let’s try using the new verification method right now. For the sake of this example, we’ll say I own the domain example.com. I have several websites under example.com, including http://www.example.com/, http://blog.example.com/ and http://beta.example.com/. I could individually verify ownership of each of those sites using the meta tag or HTML file method. But that means I’d need to go through the verification process three times, and if I wanted to add http://customers.example.com/, I’d need to do it a fourth time. DNS record verification gives me a better way!

First I’ll add example.com to my account, either in Webmaster Tools or directly on the Verification Home page.

On the verification page, I select the “Add a DNS record” verification method, and follow the instructions to add the specified TXT record to my domain’s DNS configuration.

When I click “Verify,” Google will check for the TXT record, and if it’s present, I’ll be a verified owner of example.com and any associated websites and subdomains. Now I can use any of those sites in Webmaster Tools and other verification-enabled Google products without having to verify ownership of them individually.

If you try DNS record verification and it doesn’t work right away, don’t despair!

Sometimes DNS records take a while to make their way across the Internet, so Google may not see them immediately. Make sure you’ve added the record exactly as it’s shown on the verification page. We’ll periodically check, and when we find the record we’ll make you a verified owner without any further action from you.

DNS record verification isn’t for everyone—if you don’t understand DNS configuration, we recommend you continue to use the HTML file and meta tag methods. But for advanced users, this is a powerful new option for verifying ownership of your sites.

As always, please visit the Webmaster Help Forum if you have any questions.

Posted by Sean Harding, Software Engineer

Webmaster level: All

There’s a lot of content on the Internet these days. At some point, something may turn up online that you would rather not have out there—anything from an inflammatory blog post you regret publishing, to confidential data that accidentally got exposed. In most cases, deleting or restricting access to this content will cause it to naturally drop out of search results after a while. However, if you urgently need to remove unwanted content that has gotten indexed by Google and you can’t wait for it to naturally disappear, you can use our URL removal tool to expedite the removal of content from our search results as long as it meets certain criteria (which we’ll discuss below).

We’ve got a series of blog posts lined up for you explaining how to successfully remove various types of content, and common mistakes to avoid. In this first post, I’m going to cover a few basic scenarios: removing a single URL, removing an entire directory or site, and reincluding removed content. I also strongly recommend our previous post on managing what information is available about you online.

Removing a single URL

In general, in order for your removal requests to be successful, the owner of the URL(s) in question—whether that’s you, or someone else—must have indicated that it’s okay to remove that content. For an individual URL, this can be indicated in any of three ways:

• block the page from crawling via a robots.txt file
• block the page from indexing via a noindex meta tag
• indicate that the page no longer exists by returning a 404 or 410 status code

Before submitting a removal request, you can check whether the URL is correctly blocked:

• robots.txt: You can check whether the URL is correctly disallowed using either the Fetch as Googlebot or Test robots.txt features in Webmaster Tools.
• noindex meta tag: You can use Fetch as Googlebot to make sure the meta tag appears somewhere between the <head> and </head> tags. If you want to check a page you can’t verify in Webmaster Tools, you can open the URL in a browser, go to View > Page source, and make sure you see the meta tag between the <head> and </head> tags.
• 404 / 410 status code: You can use Fetch as Googlebot, or tools like Live HTTP Headers or web-sniffer.net to verify whether the URL is actually returning the correct code. Sometimes “deleted” pages may say “404″ or “Not found” on the page, but actually return a 200 status code in the page header; so it’s good to use a proper header-checking tool to double-check.

If unwanted content has been removed from a page but the page hasn’t been blocked in any of the above ways, you will not be able to completely remove that URL from our search results. This is most common when you don’t own the site that’s hosting that content. We cover what to do in this situation in a subsequent post. in Part II of our removals series.

If a URL meets one of the above criteria, you can remove it by going to http://www.google.com/webmasters/tools/removals, entering the URL that you want to remove, and selecting the “Webmaster has already blocked the page” option. Note that you should enter the URL where the content was hosted, not the URL of the Google search where it’s appearing. For example, enter
   http://www.example.com/embarrassing-stuff.html
not
   http://www.google.com/search?q=embarrassing+stuff

This article has more details about making sure you’re entering the proper URL. Remember that if you don’t tell us the exact URL that’s troubling you, we won’t be able to remove the content you had in mind.

Removing an entire directory or site

In order for a directory or site-wide removal to be successful, the directory or site must be disallowed in the site’s robots.txt file. For example, in order to remove the http://www.example.com/secret/ directory, your robots.txt file would need to include:
   User-agent: *
   Disallow: /secret/
It isn’t enough for the root of the directory to return a 404 status code, because it’s possible for a directory to return a 404 but still serve out files underneath it. Using robots.txt to block a directory (or an entire site) ensures that all the URLs under that directory (or site) are blocked as well. You can test whether a directory has been blocked correctly using either the Fetch as Googlebot or Test robots.txt features in Webmaster Tools.

Only verified owners of a site can request removal of an entire site or directory in Webmaster Tools. To request removal of a directory or site, click on the site in question, then go to Site configuration > Crawler access > Remove URL. If you enter the root of your site as the URL you want to remove, you’ll be asked to confirm that you want to remove the entire site. If you enter a subdirectory, select the “Remove directory” option from the drop-down menu.

Reincluding content

You can cancel removal requests for any site you own at any time, including those submitted by other people. In order to do so, you must be a verified owner of this site in Webmaster Tools. Once you’ve verified ownership, you can go to Site configuration > Crawler access > Remove URL > Removed URLs (or > Made by others) and click “Cancel” next to any requests you wish to cancel.

Still have questions? Stay tuned for the rest of our series on removing content from Google’s search results. If you can’t wait, much has already been written about URL removals, and troubleshooting individual cases, in our Help Forum. If you still have questions after reading others’ experiences, feel free to ask. Note that, in most cases, it’s hard to give relevant advice about a particular removal without knowing the site or URL in question. We recommend sharing your URL by using a URL shortening service so that the URL you’re concerned about doesn’t get indexed as part of your post; some shortening services will even let you disable the shortcut later on, once your question has been resolved.

Posted by Susan Moskwa, Webmaster Trends Analyst

Webmaster Level: Intermediate

In our recent post on the Google Online Security Blog, we described our system for identifying phishing pages. Of the millions of webpages that our scanners analyze for phishing, we successfully identify 9 out of 10 phishing pages. Our classification system only incorrectly flags a non-phishing site as a phishing site about 1 in 10,000 times, which is significantly better than similar systems. In our experience, these “false positive” sites are usually built to distribute spam or may be involved with other suspicious activity. If you find that your site has been added to our phishing page list (”Reported Web Forgery!”) by mistake, please report the error to us. On the other hand, if your site has been added to our malware list (”This site may harm your computer”), you should follow the instructions here. Our team tries to address all complaints within one day, and we usually respond within a few hours.

Unfortunately, sometimes when we try to follow up on your reports, we find that we are just as confused as our automated system. If you run a website, here are some simple guidelines that will allow us to quickly fix any mistakes and help keep your site off our phishing page list in the first place.

- Don’t ask for usernames and passwords that do not belong to your site. We consider this behavior phishing by definition, so don’t do it! If you want to provide an add-on service to another site, consider using a public API or OAuth instead.

- Avoid displaying logos that are not yours near login fields. Someone surfing the web might mistakenly believe that the logo represents your website, and they might be misled into entering personal information into your site that they intended for the other site. Furthermore, we can’t always be sure that you aren’t doing this intentionally, so we might block your site just to be safe. To prevent misunderstandings, we recommend exercising caution when displaying these logos.

- Minimize the number of domains used by your site, especially for logins. Asking for a username and password for Site X looks very suspicious on Site Y. Besides making it harder for us to evaluate your website, you may be inadvertently teaching your visitors to ignore suspicious URLs, making them more vulnerable to actual phishing attempts. If you must have your login page on a different domain from your main site, consider using a transparent proxy to enable users to access this page from your primary domain. If all else fails…

- Make it easy to find links to your pages. It is difficult for us (and for your users) to determine who controls an off-domain page in your site if the links to that page from your main site are hard to find. All it takes to clear this problem up is to have each off-domain page link back to an on-domain page which links to it. If you have not done this, and one of your pages ends up on our list by mistake, please mention in your error report how we can find the link from your main site to the wrongly blocked page. However, if you do nothing else…

- Don’t send strange links via email or IM. It’s all but impossible for us to verify unusual links that only appeared in your emails or instant messages. Worse, using these kinds of links conditions your users/customers/friends to click on strange links they receive through email or IM, which can put them at risk for other Internet crimes besides phishing.

While we hope you consider these recommendations to be common sense, we’ve seen major e-commerce and financial companies break these guidelines from time to time. Following them will not only improve your experience with our anti-phishing systems, but will also help provide your visitors with a better online experience.

Written by Colin Whittaker, Anti-Phishing Team

Webmaster Level: Intermediate

A multilingual website is any website that offers content in more than one language. Examples of multilingual websites might include a Canadian business with an English and a French version of its site, or a blog on Latin American soccer available in both Spanish and Portuguese.

Usually, it makes sense to have a multilingual website when your target audience consists of speakers of different languages. If your blog on Latin American soccer aims to reach the Brazilian audience, you may choose to publish it only in Portuguese. But if you’d like to reach soccer fans from Argentina also, then providing content in Spanish could help you with that.

Google and language recognition

Google tries to determine the main languages of each one of your pages. You can help to make language recognition easier if you stick to only one language per page and avoid side-by-side translations. Although Google can recognize a page as being in more than one language, we recommend using the same language for all elements of a page: headers, sidebars, menus, etc.

Keep in mind that Google ignores all code-level language information, from “lang” attributes to Document Type Definitions (DTD). Some web editing programs create these attributes automatically, and therefore they aren’t very reliable when trying to determine the language of a webpage.

Someone who comes to Google and does a search in their language expects to find localized search results, and this is where you, as a webmaster, come in: if you’re going to localize, make it visible in the search results with some of our tips below.

The anatomy of a multilingual site: URL structure

There’s no need to create special URLs when developing a multilingual website. Nonetheless, your users might like to identify what section of your website they’re on just by glancing at the URL. For example, the following URLs let users know that they’re on the English section of this site:

http://example.ca/en/mountain-bikes.html
http://en.example.ca/mountain-bikes.html

While these other URLs let users know that they’re viewing the same page in French:

http://example.ca/fr/mountain-bikes.html
http://fr.example.ca/mountain-bikes.html

Additionally, this URL structure will make it easier for you to analyze the indexing of your multilingual content.

If you want to create URLs with non-English characters, make sure to use UTF-8 encoding. UTF-8 encoded URLs should be properly escaped when linked from within your content. Should you need to escape your URLs manually, you can easily find an online URL encoder that will do this for you. For example, if I wanted to translate the following URL from English to French,

http://example.ca/fr/mountain-bikes.html

It might look something like this:

http://example.ca/fr/vélo-de-montagne.html

Since this URL contains one non-English character (é), this is what it would look like properly escaped for use in a link on your pages:

http://example.ca/fr/v%C3%A9lo-de-montagne

Crawling and indexing your multilingual website

We recommend that you do not allow automated translations to get indexed. Automated translations don’t always make sense and they could potentially be viewed as spam. More importantly, the point of making a multilingual website is to reach a larger audience by providing valuable content in several languages. If your users can’t understand an automated translation or if it feels artificial to them, you should ask yourself whether you really want to present this kind of content to them.

If you’re going to localize, make it easy for Googlebot to crawl all language versions of your site. Consider cross-linking page by page. In other words, you can provide links between pages with the same content in different languages. This can also be very helpful to your users. Following our previous example, let’s suppose that a French speaker happens to land on http://example.ca/en/mountain-bikes.html; now, with one click he can get to http://example.ca/fr/vélo-de-montagne.html where he can view the same content in French.

To make all of your site’s content more crawlable, avoid automatic redirections based on the user’s perceived language. These redirections could prevent users (and search engines) from viewing all the versions of your site.

And last but not least, keep the content for each language on separate URLs – don’t use cookies to show translated versions.

Working with character encodings

Google directly extracts character encodings from HTTP headers, HTML page headers, and content. There isn’t much you need to do about character encoding, other than watching out for conflicting information – for example, between content and headers. While Google can recognize different character encodings, we recommend that you use UTF-8 on your website whenever possible.

If your tongue gets twisted…

Now that you know all of this, your tongue may get twisted when you speak many languages, but your website doesn’t have to!

For more information, read our post on multi-regional sites and stay tuned for our next post, where we’ll delve into special situations that may arise when working with global websites. Until then, don’t hesitate to drop by the Help Forum and join the discussion!

Written by Xavier deMorales, Google Search Quality

Webmaster Level: All

Members of the Google Search Quality Team have participated in site clinic panels on a number of occasions. We receive a lot of positive feedback from these events and we’ve been thinking of ways to expand our efforts to reach even more webmasters. We decided to organize a small, free of charge pilot site clinic at Google in Dublin, and opened the invitation to webmasters from the neighborhood. The response we received was overwhelming and exceeded our expectations.

Meet the Googlers who hosted the site clinic: Anu Ilomäki, Alfredo Pulvirenti, Adel Saoud, Fili Wiese, Kaspar Szymanski and Uli Lutz.

It was fantastic to see the large turnout and we would like to share the slides presented as well as the takeaways.

These are some questions we came across, along with the advice shared:

1. I have 3 blogs with the same content, is that a problem?

   If the content is identical, it’s likely only one of the blogs will rank for it. Also, with this scattered of an effortwith this scattered of an effort chances are your incoming links will be distributed across the different blogs, instead of pointing to one source. Therefore you’re running the risk of both users and search engines not knowing which of your blogs is the definitive source. You can mitigate that by redirecting to the preferred version or using the cross domain canonical to point to one source.

2. Should I believe SEO agencies that promise to make my site rank first in Google in a few months and with a precise number of links?

   No one can make that promise; therefore the short answer is no, you should not. However, we have some great tips on how to find a trustworthy SEO in our Help Center.

3. There are keywords that are relevant for my website, but they’re inappropriate to be shown in the content e.g. because they could be misunderstood, slang or offensive. How can I show the relevance to Google?

   Depending on the topic of your site and expectations of the target group, you might consider actually using these keywords in a positive way, e.g. explaining their meaning and showing your users you’re an authority on the subject. However if the words are plain abusive and completely inappropriate for your website, it’s rather questionable whether the traffic resulting from these search queries is interesting for your website anyway.

4. Would you advise to use the rewrite URL function?

   Some users may like seeing descriptive URLs in the search results. However, it’s quite hard to correctly create and maintain rewrites that change dynamic URLs to static-looking URLs. That’s why, generally speaking, we don’t recommend rewriting them. If you still want to give it a try, please be sure to remove unnecessary parameters while maintaining a dynamic-looking URL and have a close look at our blog post on this topic. And if you don’t, keep in mind that we might still make your URLs look readable in our search results no matter how weird they actually are.

5. If I used the geo-targeting tool for Ireland, is Northern Ireland included?

   Google Webmaster Tools geo-targeting works on a country basis, which means that Northern Ireland would not be targeted if the setting was Republic of Ireland. One possible solution is to create a separate site or part of a website for Northern Ireland and to geo-target this site to the United Kingdom in Webmaster Tools.

6. Is there any preference between TLDs like .com and .info in ranking?

   No, there is none. Our focus is on the content of the site.

7. I have a website on a dot SO (.so) domain name with content meant for the Republic of Ireland. Will this hurt my rankings in the Irish search results?

   .so is the Internet country code top-level domain for Somalia. This is one factor we look into not pointing to the desired destination. But we do look at a larger number of factors when ranking your website. The extension of the domain name is just one of these. Your website can still rank in the Irish search results if you have topic-specific content. However, keep in mind that it may take our algorithms a little bit longer to fully understand where to best serve your website in our search results.

We would like to thank all participants for their time and effort. It was a pleasure to help you and we hope that it was beneficial for you, too. For any remaining questions, please don’t hesitate to join the community on our GWHF.

Posted by Kaspar Szymanski, Search Quality Strategist, Dublin