Welcome to the Q&A Forum

Hey David, thanks a lot for your response, I'll definitely take that on board!

Hi there, I reviewed several pages that we're reporting as duplicates and none of them are canonicalized. If you don't want to change the content in the source code so it's not 95% similar to the other pages, you'll need to add canonicals. The Help Hub has some good info on how to do this. You can also run a search in the community. If we reported 404's in the initial crawl, it's because they existed at the time. The most recent crawl isn't showing any 404's so this shouldn't be an issue anymore. Again, there are no 404's reported in this week's crawl for your campaign so there will be no 404's in the crawl diagnostic csv. That is where you'll want to go if this comes up again though. -If the page on your site is linked to from anywhere on your site, we will crawl and report on it up to the page crawl limit set for the campaign. We're not going to report data for non-existent links as that isn't physically possible. I hope this helps clear things up.

You want your sitemap to include all your important URLs. Don't remove them from the sitemap just because you have been crawled.

Yes, unless you have a compelling reason to change them. By changing the names you are just creating more work for yourself. Was there a reason you were wanting to name them something different? Changing the name (if you choose to do so) of the sitemap is not going to have an effect on already-indexed URL's. I dont see any reason that you should modify the names unless you are trying to organize them better

Hi, Duplicate content is bad for search because it forces pages on your site to compete with each other for rank. If each tag only contains one post then you are duplicating every post twice - once in the original post and once in the tag which is displaying the same post and only that post. If you use a lot of the same tags for each post, for example you tag every post 'blog' and 'daily’, then those pages will contain the same posts and therefore be duplicate content. It may be worth checking your analytics to see if any of these pages are getting entrances from organic search, which will tell you if the 'duplicate' is outranking the original post. But often this is because that page contains a lot more information on the subject than a single blog post. So you may not be able to replicate that success with a smaller single blog post. As the previous answer stated using a robots.txt indicating Disallow: /tags/whatever2 will tell a spider not to crawl that page, you could do it selectively by disallowing only the tags which are being flagged as duplicates, or disallow all tagged pages from being crawled with Disallow: /tags/* But every site is different and you will need to decide for yourself if your 'duplicate' content is actually harming your site, you might find that those pages are full of keywords naturally and are attracting all your traffic. Hope that helps!

Hi Sam, Though we relay on  branding, social media, natural backlinks etc.., still RAW SEO helps websites to get traffic. That put me to raise this question. Got your points and inputs. Will sure use them. thanks for your time.

Mmm... if your site has not been translated yet, the correct should be rel="alternate" hreflang="en-FR", but - yes - that would mean that people searching in French from France won't see the /fr subfolder. On the other hand, using as hreflang "fr-FR" would not be correct. My best suggestion, in cases like this, is using the hrelang="x-default", where the href is the country selector page, so that people searching in French from France will be pointed to the selector page and, from there being able to click on the french version link. Another suggestion is to create personalized message telling the French people entering in the site but seeing it is in English that the site is going to be soon translated in their language, but that the products and services are already available for the French market, so inviting them to not bounce back, which should be the most common reaction the users can have.

Thanks for those answers, that's really useful. It sounds like this is not something to worry about too much, but something that is not ideal for the site's appearance in the search results!

Thanks for the update Keri

Your welcome. Interesting question. My answer is that if the HTML TITLE is set with client side JavaScript then it's has little change of being picked up as the title by crawlers or Google. Let's say we alter the node element Title value with like this: In this case it will alter the value after the hard coded HTML title was send to the browser. It would need the crawler to load the document in full and read the HTML title value only after fully rendering it as if it where a human user. This is not likely. Then we could also try a document write to construct the HTML HEAD tag Title as a string to use for the browser as the title like this: Will not work as the title text is not actually altered after evaluation of the script line. This does not work because the title is not set but because it's not actually printed to the browser as a string. The source code for the title still looks like this in to any browser: As you can see the script does not print the result string of the evaluation to the browser but still sets the value of the document object model node HTML TITLE to the value it evaluates to. Try it for yourself with this dummy page I made just to be certain. http://www.googlewiki.nl/test/seojavascripttest2.html And this is the DOM info for this page http://www.googlewiki.nl/seo-checker/testanchor.php?url=http://www.googlewiki.nl/test/seojavascripttest2.html&anchor=test Or am I missing something here? Hope this helps.

Yups, seeing the same thing in our Google Webmaster Tools accounts.

Hello! Thanks for the question. The simple answer is that you should have a different web property (root domain, subdomain, or subdirectory) for each of your target audiences. So, if your main website (home office, perhaps), is in the UK, then the main site should remain .co.uk (or wherever). Then, use a different property for each targeted country. There are three main methods: **1. Separate root domains.**This would be creating and using example.co.uk and (for the Philippines) example.ph. 2. Separate subdirectory/subfolder. Put the Phillippines at example.co.uk/ph/ 3. Separate subdomains. Put the Phillippines at ph.example.com SEOs and digital marketers will argue forever over which one is best. I'll point out some general differences and points since I don't know your specific situation. Separate root domains and subdomains are essentially entirely-separate sites in Google's eyes. This is good to use when you have a lot of specialized content for each targeted country. It's also usually easier to use different design templates on different domains and subdomains. The bad side is that links pointing to one root domain or subdomain may not "benefit" the other root domain or subdomain. Keeping everything on one root domain in other subdirectories/subfolders can be a lot more simple to manage. Plus, all links to everywhere on the root domain generally "help" everything on the root domain. However, you will often be limited to using the same overall design template. Regardless of what option you choose, you can configure the geographical targeting of each rootdomain, subdomain, or subdirectory in Google Webmaster Tools. There are additional things you can do regarding language targeting (if you so choose -- sometimes more than one language is spoken in a given country). For more information on all of this, I would review this page of introductory guidelines and the related links. Some more detail from Google. A Webmaster Support question. For an "international SEO checklist," I'd suggest this post by Moz Associate Aleyda Solís. Good luck!

that's a pretty cool tool Daniel Those you mentioned have worked for me along with adding schema to show the description.

Thanks guys! Trying to get to the next level, and this looks like a fantastic tool.

In general, it is best to do all of the changes (the domain, branding, and URL work) all on a development site (that is blocking search engines) and then release the new site only after everything is complete. If you space it out piecemeal over too long of a time, it will look very messy both to Google and your website visitors. Releasing a new, properly-migrated website all at once is the quickest way to mitigate any "SEO" damage and return to your prior traffic and ranking levels quickly. However, it'd be impossible for me or anyone to be more specific without doing a deep dive into your site. However, there are some general best practices for site migrations. For reference on all of these, I'd take a look at what Moz did when migrating from seomoz.org to moz.com. Moz has a webinar and associated blog post that goes through all of the technical details and results. Aleyda Solis also has a good migration checklist with links to more resources here. I hope that helps -- good luck!

We discussed using the canonical tag but wasn't sure it would be quite as good as using a 301. We will probably go with HT Access method. Thanks for the quick response, BTW! Cheers. Tom V