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).