All questions on Stack Exchange contain a numeric ID (28070 for this question) which is the only thing that uniquely identifies a question.
So when a question title is changed, the URL such as /28070/old-question-title still shows the question because the ID is still there. The ID is looked up and the new title returned, meaning that the new URL can be ...
According to RFC 2616 (HTTP/1.1), section 3.2.2, the URLs http://www.example.com and http://www.example.com/ are equivalent, and HTTP clients must normalize the former to the latter before sending the request to the server:
"If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2)."
Fragment identifiers are traditionally used to identify a portion of document for client-side applications. As stated in the specification Google adopted:
Traditionally, hash fragments (that is, everything after # in the URL)
have been used to indicate one portion of a static HTML document.
...hash fragments are not part of HTTP requests (and as a ...
If you don't specifically tell Google your preference you will probably have duplicate content issues. There is more then one way to inform Google of your preferred domain:
Do a 301 redirect to use the 'www' or no 'www'
Specify your preferred domain in Google Webmaster Tools
Use canonical URLs (although it isn't typically used in this situation)
Spaces in URLs should be encoded. That would eliminate foo abc.jpg as the canonical.
Here is a question that addresses how the space should be encoded: In a URL, should spaces be encoded using %20 or +? Spaces may only be encoded as a + in the query string portion of the URL, so that eliminates the foo+abc.jpg as the canonical.
Your canonical URL ...
URLs that differ in case in the query string are different URLs to search engines. They are not considered equal and would need canonical tags or redirects to tell search engines which you prefer.
Different parts of the URL are different in terms of case sensitivity:
Protocol (http) -- case insensitive
Host name (example.com) -- case insensitive
I don't think Canonical is the correct way as you are essentially that the correct url for that page is the new one, as it is different content I think it may conflict.
Personally I think the easiest way if you want to keep the old post is the link at the top of the page.
Also if you remove the page from google it will be removed and not replaced so you ...
No. The canonical element is supposed to resolve duplicate content issues on your site stemming from multiple URLs that pull up the same content. Telling the search engines to go to two different places off the same page totally defeats the purpose.
My guess is the company is having some issues internally. It might be their CMS builds composite pages from ...
Adding or omitting a trailing slash to canonical links really doesn't matter to search engines, providing they both work.
It maybe be best however to stick with one or the other because Google treats each of these URL's separately, which can lead to duplicate content. See this for more on that: Google Webmaster Central Blog: To slash or not to slash
Web browsers do not care about canonical URLs. It is for search engine use only (specifically Google).
Additionally, canonical URLs do not affect the loading or rendering of a web page. So no assets will be loaded over HTTP which is what would cause an insecure error message.
So, no, they will not display any error message.
No it is not legal. It is copyright infringement to copy and republish any article without the proper license to do so. Noting the source and adding a canonical does not in any way limit your legal liability.
It sounds like you want to republish all articles as if they were licensed under the Creative Commons attribution license. Content that is ...
About a year ago Google tackled this problem by creating Source Attribution meta tags:
syndication-source: this meta tag is used to point to the long-lived (bookmarkable) URL of the original article. This should be used on all pages that republish the syndicated content, but it can also be used on the original page to point to itself as the syndication ...
New sites often do drop in rank
Sadly the chances are that Google is repositioning to where it believes you should be, most often new sites and pages get temporary boosts to allow them to catch on so to speak. I've seen what your experiencing hundreds of times and can assure you what your seeing is most likely out of your control until your site becomes ...
I feel I should clear this up. Tim Fountain is correct in his comment.
Unlike directories, a domain with a trailing slash is exactly, 100% the same as one without. In other words, it's literally not possible to choose one or the other. So it makes zero difference which you put into your canonical.
Google will never index HTTPS while the canonicals point to HTTP. I switched my largest site over to HTTPS using the following protocol:
Enabled HTTPS for the site without switching canonicals for about two years. During this time period Google sent all traffic to HTTP.
Switched the canonical version to HTTPS. It has been running that way for about 8 ...
Query parameters can be used for many purposes. Some of them don't specify the page content and some of them do. If the query parameter is used to specify the content loaded onto the page, then it should be included in your canonical URL. If the query parameter is used for tracking or changes an insignificant part of the page, then it should be left out ...
You should not use the canonical this way, paginated listing are well understood by Google. You can help him to make it clear : http://googlewebmastercentral.blogspot.fr/2011/09/pagination-with-relnext-and-relprev.html
Personally I would do the opposite canonical - ie set /texas/houston as canon instead of /houston - the main reason being to avoid name clashes with identical names in other states. A URL of /springfield could be a little confusing, even if you are showing a specific Springfield page. You also get an extra keyword in the URL.
Secondly, I would always prefer ...
Canonical tags are no longer needed in the mark up for multilingual sites, you can see here where Google no longer recommends using canonicals in multilingual markup (the struck out section):
new markup for multilingual content (old blog post)
So this just leaves you with two options, use either rel="alternate" hreflang="x" tags or use the rel="alternate" ...
Two of the most widely used operating system file systems for serving web content have have very different settings for case sensitivity of URLs by default. Whether or not your URLs are case sensitive is likely a function of which you are using:
Microsoft IIS running on Windows - case insensitive URLs - shows the same content regardless of capitalization.
Putting the ID near the beginning of a URL is better than putting it near the end.
URLs often get truncated in emails or by CMS systems that show them to users. When the ID is at the end the truncation will often lop it off and cause 404 errors on your site. When it is near the beginning, your site can still redirect to the full URL.
When Googlebot ...
From the SEO prospective, i bet there might be a difference:
In you first example, the ID is separated from the title, making it clear to the crawler it is a different resource (as the / character does it naturally).
In your second example, the ID is mixed with the title. It requires more brains from the crawler to determine the meaning of it.
Imagine the ...
Early 2018 update to Google Search Console will now tell you if it's overridden a page with a different canonical:
Google chose different canonical than user: This URL is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical. Because we consider this page a duplicate, we did not index it; only the canonical page is ...
rewrite ^/$ ? permanent;
This would only match the document root (a valid request) - this isn't a URL that ends with a slash, but a URL that starts with a slash.
Try something like the following instead, to match any request URL that ends with a slash:
rewrite ^(.+)/$ $1 redirect;
$1 is a backreference to the original URL-path, less the trailing slash.
Here is what the HTML spec says about using unquoted attribute values:
An unquoted attribute value is specified by providing the following parts in exactly the following order:
an attribute name
zero or more space characters
a single = character
zero or more space characters
an attribute value
In addition to the general ...
Given the incredible popularity of Google (it is 90% of incoming traffic on Stack Overflow, for example), couldn't you simply check the referer?
Example referer strings from search engines:
That's a use of canonicalization, and arguably the most important one, but from the Webmaster Tools content guidelines, pagination:
You can also add a rel="canonical" link to the component pages to tell Google that the View All version is the version you want to appear in search results.
Even more specific to your example above, the use case is that the ...
They were right to do that although a canonical URL would have also sufficed. Technically speaking those are two different URLs and thus considered two different pages. So the 301 redirect, or canonical URL, tells Google that both are the same page and to handle it accordingly.
Your "SEO expert" might be a lying bastard, but this probably isn't the reason. He's absolutely right about this. This is a little known edge case in URL construction.
RFC 3986 is the official definition of the URL format and rules on how to encode and decode URL. Any URL parser should be following this as closely as possible to avoid errors and be ...
You can add canonical tags by editing your blog HTML template. (See this Google support article on how to edit the template HTML: https://support.google.com/blogger/answer/46870?hl=en)
Then add code like this to the <head> of the document:
<ItemPage><Blogger><link href="<$BlogItemPermalinkURL$>" rel="canonical"/></Blogger&...