14

Mobile to desktop version should be a choice the user initiates. Sometimes the user may want the mobile version due to: 1) A focused and less cluttered experience 2) Faster browsing for low-bandwidth users (e.g. laptop with a 3G connection) 3) Ability to fit on a small screen Whatever the reason, I don't think deciding for your users is right. Let the ...


6

Yes! In a recent blog post we mentioned: Your [rel-alternate-hreflang] annotations should be self-referential. Page A should use rel-alternate-hreflang annotation linking to itself.


4

Let the user choose. Few things are more frustrating than being forced to use a lacking mobile site. Consider allowing desktop users to choose mobile as well -- perhaps they're tethering their laptop to their unrooted iPhone and would appreciate the low-bandwidth alternative for their limited data quota. I think you will find the first problem case ...


3

I don't see why not. The question here is whether you think it will benefit your users or not. Personally speaking, I find it a tad bit annoying whenever I'm brought to the mobile version of a website, even though I'm using a desktop computer. Do note that you should create some sort of URL fragment that can be used whenever you do not want to be redirected (...


3

No you cannot do this using hreflang, they are primarily for language and location is optional, but you cannot just mark up the location: Do not specify a country code by itself! Google does not automatically derive the language from the country code. Use hreflang for language and regional URLs I think the other option here is to try and detect what ...


3

In short, no. The "Supported language/region codes" section of Google's hreflang guidelines is fairly unambiguous: The value of the hreflang attribute identifies the language (in ISO 639-1 format) and optionally the region (in ISO 3166-1 Alpha 2 format) of an alternate URL. The use of the word "region" there is perhaps confusing. ISO 3166-1 Alpha 2 codes ...


3

Hey @WarrenH and @Maximillian Laumeister, thx for your answers. I found this website: https://www.searchviu.com/en/hreflang-canonical/ and if i understand it. The solution is: Version blue: DE URL: ..de/kleidung/tshirt-de-blue <link rel="canonical" href="...de/kleidung/tshirt-de"> EN URL: ...de/en/fashion/tshirt-en-blue <link rel="canonical" ...


2

That answer is actually quite simple. Spiders retrieve a page and process that page and only that page. Links to other resources are queued for visiting by another spider. Search Engines ignore script tags that have a source. Javascript by design does NOT contain data, and search engines are hungry for data.. The main benefit over using json-ld over ...


2

I have worked with websites using the approach you are mentioning. Here's my take: Yes, it will be crawled and indexed (if you have internal links to all pages). They should be identical if you are telling search engines where the same alternative mobile page is located, and you are using a canonical link from mobile version. They should be as as identical ...


2

The best recommendation that I have is to be as explicit as possible for when you do have a mobile URL and for when you do not. The best method for this is to state this in your sitemap as is indicated in the official Google documentation here: https://developers.google.com/search/mobile-sites/mobile-seo/separate-urls#annotation-in-sitemaps. Per the Google ...


2

The canonical+hreflang markup for your urls should be like: www.example.com/en/main-content <link rel="canonical" href="www.example.com/en/main-content"> <link rel="alternate" href="www.example.com/en/main-content" hreflang="en" /> <link rel="alternate" href="www.example.com/fr/main-content" hreflang="fr" /> www.example.com/en/similar-to-...


2

Edit: I am not entirely sure that this answer is correct, as pointed out by WarrenH in the comments. However I am leaving it up because it (and Warren's comments) have some potentially useful info. The rel=alternate tag is used for specifying different representations of the same page, and the hreflang attribute is more specifically for specifying a ...


2

Yes it's perfectly fine to re-use the https://www.example.com host as both the en-us and the x-default hreflang. To be sure, you can use the International Targeting Report to debug possible issues after Google crawls your site: https://www.google.com/webmasters/tools/i18n It's not mentioned explicitly in the hreflang documentation, but you can use the same ...


1

Yes, this doesn’t seem to be correct. HTML defines that alternate+hreflang is for translations: If the alternate keyword is used with the hreflang attribute, and that attribute’s value differs from the root element’s language, it indicates that the referenced document is a translation. To be clear, the problem is not that the hreflang attribute is used ...


1

Generally, in terms of SEO it's better to host everything under the same roof, but if you do want to provide more personal approach using specific country top level domains then you can, using alternative and hreflang. If your content is English only then you need to specific en_XX, xx matching the ISO code of the country. For example, if you wanted to ...


1

If you have 'same' pages translated in different languages, their title and description should be translated too. Otherwise, this will be confusing to users and to search engines too. In other words, the title and description for http://site.lt/oliver-weber-auskarai-symbol-9919 should be in "lt-LT". If you don't use canonical, there is indeed a risk of (...


1

I'd be careful using 301 Moved Permanently if the original URIs are still valid. You risk search engines will unindex them and reindex your site with the redirected URIs only. I'd rather consider 302 Found or the 307 Temporary Redirect (These are HTTP 1.1). After all that's what you're doing - redirecting this current user temporarily as he requests another ...


1

If parameter is not affecting content than you need to specify passive typed parameter in URL Parameters tool and use your first solution: <link href="https://mywebsite.com/ru/some-page.php" rel="alternate" hreflang="ru" /> <link href="https://mywebsite.com/en/some-page.php" rel="alternate" hreflang="en" /> In that case you don't need to ...


1

Nope, you cannot link to Page A in your hreflang markup if page A says it's a duplicate of page B. You'll end up getting errors in Google Search Console for missing return tags.


1

It is always best to have a "rel=canonical" in the <head> of the HTML code in each page that you want the site crawled as. This means that if you are using a a separate site for desktop and mobile, and both pages point to the same content, always have the canonical link point to the address that you want the search engine to recognize and crawl. ie. ...


1

I think you should not do this (unless each English pagination page contains the same items like the Swedish pagination page with the same number). alternate+hreflang should only be used for translations. But if your English page 3 could contain the items {A, B, C, D} and your Swedish page 3 could contain the items {B, D, E, F}, they aren’t really ...


1

You should not be using rel=canonical or rel=alternate on page 2+. Instead you should be using rel=prev and rel=next. That will allow search engines to associate the text on all of the pages in the pagination with page 1 and only rank the first page.


1

You can definitely use the alternate, nothing stopping you from using the first example, you won't be penalized directly unless you try to canonical alternate a http area that defaults to SSL normally, causing obvious errors. I have nothing to cite this besides this is what rel="alternate" is for; whether or not services support then trigger stuff is up to ...


1

They have to be equivalent, not necessarily identical. Just don't get too crazy with the differences between the two pages. Google's John Mueller says... If these pages are equivalent, even if they're not 100% identical, I'd use a rel=canonical here. With that, all of the signals (such as links to those pages) that we have for the "set" of URLs will be ...


1

H1 on mobile pages should better exactly same as titles and h1 on their desktop counterparts. In fact mobile pages are marked up as canonical to send signal to Google, they have pretty same content as desktop pages, but for another devices. Indeed, the content on mobile pages COULD be slightly different, as on desktop pages, but this difference should lie ...


1

As Google don't appear to mention canonical images in their guidelines, I'd assume it is not going to be an SEO issue and not bother. The worst that I've seen happen to a page when no canonical tag is set is simply that Google pick the wrong URL as canonical and push the other one down the listings. If images were treated in a similar fashion and they ...


1

It sounds like you're trying to have /primary1 & /alt1 both indexed with the same content. This will appear to search engines as duplicate pages and have a negative effect on your ranking. Without fully understanding what you're doing, it sounds like you just want both URLs accessible, so you'd be better off setting the canonical for /alt1 to point to /...


1

I'm pretty sure the URL can be completely different, and that would also make sense as you might actually use the different languages in the URLs. Also you can use them cross domain where the entire domain would be different. I haven't seen in any of Google guidelines where they stipulate they must be similar. The idea is that the content on the pages is ...


1

I don't think that canonical is a good choise. Possible Solutions My suggestion is to set <meta name="robots" content="noindex" /> for the small galeries and rel="nofollow"for the links to them and index only the gallery which shows 600 photos, if I understand correctly you have the same photos in all the galeries and the only difference is the ...


1

Consider that you may want your canonical link to be logical/thematic rather than presentational. That would suggest using a single canonical place for all 600 pictures in the selection. This, as far as I know, would not stop google from indexing images that are further paginated. But if it indeed stops them, then you should have canonicals for the smallst ...


Only top voted, non community-wiki answers of a minimum length are eligible