I don't know of an ootb solution, this is how I usually "fix" this issue:

1. Add a setting to the site definition that lists all available languages

2. Add a a processor to the httpRequestBegin pipeline after the language resolver:

   <httpRequestBegin> <processor patch:after="*[@type='Sitecore.Pipelines.HttpRequest.LanguageResolver, Sitecore.Kernel']" type="xxx.LanguageResolver, xxx" /> </httpRequestBegin>

3. In the processor:

• Detect if the request should be handled (no Sitecore requests, only in normal mode, ...) and get out asap if not (performance)
• Check if the language is available in the current site (based upon the setting created in 1) and redirect if it's not ok

You can find code for this on https://github.com/Gatogordo/EasyLingo

This will fix the first issue. For Sitecore recognizing urls you don't actually want, I usually don't block that but I do tell crawlers and such that I don't want those. You should do (at least) two things:

• Always set a canonical url with the exact link you want for that page in that language
• Add language headers to all pages, like <link rel="alternate" href="https://www.mycompany.de/ueber-uns" hreflang="de" /> and <link rel="alternate" href="https://www.mycompany.co.uk/about-us" hreflang="en" /> (do this for all languages in which the current page is available).

When using item language fallback, you can tweak the logic of the language headers and canonicals to your needs (hide pages that are a full fallback and set their canonicals to the original language).

I don't know of an ootb solution, this is how I usually "fix" this issue:

1. Add a setting to the site definition that lists all available languages

2. Add a a processor to the httpRequestBegin pipeline after the language resolver:

   <httpRequestBegin> <processor patch:after="*[@type='Sitecore.Pipelines.HttpRequest.LanguageResolver, Sitecore.Kernel']" type="xxx.LanguageResolver, xxx" /> </httpRequestBegin>

3. In the processor:

• Detect if the request should be handled (no Sitecore requests, only in normal mode, ...) and get out asap if not (performance)
• Check if the language is available in the current site (based upon the setting created in 1) and redirect if it's not ok

You can find code for this on https://github.com/Gatogordo/EasyLingo

This will fix the first issue. For Sitecore recognizing urls you don't actually want, I usually don't block that but I do tell crawlers and such that I don't want those. You should do (at least) two things:

• Always set a canonical url with the exact link you want for that page in that language
• Add language headers to all pages, like <link rel="alternate" href="https://www.mycompany.de/ueber-uns" hreflang="de" /> and <link rel="alternate" href="https://www.mycompany.co.uk/about-us" hreflang="en" /> (do this for all languages in which the current page is available).

When using item language fallback, you can tweak the logic of the language headers and canonicals to your needs (hide pages that are a full fallback and set their canonicals to the original language).

If you really want/need to block those (faulty) requests you will need the current language and the current item to verify whether the request is ok or not. To do that you could add another processor to the httpRequestBegin pipeline but this time after the ItemResolver, as you will need the current item. You could request the the url for the current item from the LinkManager and compare that to the raw url. Test this thoroughly as a small error might cause infinite redirects ;)

I don't know of an ootb solution, this is how I usually "fix" this issue:

1. Add a setting to the site definition that lists all available languages

2. Add a a processor to the httpRequestBegin pipeline after the language resolver:

   <httpRequestBegin> <processor patch:after="*[@type='Sitecore.Pipelines.HttpRequest.LanguageResolver, Sitecore.Kernel']" type="xxx.LanguageResolver, xxx" /> </httpRequestBegin>

3. In the processor:

• Detect if the request should be handled (no Sitecore requests, only in normal mode, ...)
• Check if the language is available in the current site (based upon the setting created in 1) and redirect if it's not ok

You can find code for this on https://github.com/Gatogordo/EasyLingo

This will fix the first issue. For Sitecore recognizing urls you don't actually want, I usually don't block that but I do tell crawlers and such that I don't want those. You should do (at least) two things:

• Always set a canonical url with the exact link you want for that page in that language
• Add language headers to all pages, like <link rel="alternate" href="https://www.mycompany.de/ueber-uns" hreflang="de" /> and <link rel="alternate" href="https://www.mycompany.co.uk/about-us" hreflang="de" /> (do this for all languages in which the current page is available).

When using item language fallback, you can tweak the logic of the language headers and canonicals to your needs (hide pages that are a full fallback and set their canonicals to the original language).

I don't know of an ootb solution, this is how I usually "fix" this issue:

1. Add a setting to the site definition that lists all available languages

2. Add a a processor to the httpRequestBegin pipeline after the language resolver:

   <httpRequestBegin> <processor patch:after="*[@type='Sitecore.Pipelines.HttpRequest.LanguageResolver, Sitecore.Kernel']" type="xxx.LanguageResolver, xxx" /> </httpRequestBegin>

3. In the processor:

• Detect if the request should be handled (no Sitecore requests, only in normal mode, ...) and get out asap if not (performance)
• Check if the language is available in the current site (based upon the setting created in 1) and redirect if it's not ok

You can find code for this on https://github.com/Gatogordo/EasyLingo

This will fix the first issue. For Sitecore recognizing urls you don't actually want, I usually don't block that but I do tell crawlers and such that I don't want those. You should do (at least) two things:

• Always set a canonical url with the exact link you want for that page in that language
• Add language headers to all pages, like <link rel="alternate" href="https://www.mycompany.de/ueber-uns" hreflang="de" /> and <link rel="alternate" href="https://www.mycompany.co.uk/about-us" hreflang="en" /> (do this for all languages in which the current page is available).

When using item language fallback, you can tweak the logic of the language headers and canonicals to your needs (hide pages that are a full fallback and set their canonicals to the original language).