Welcome to the Q&A Forum

I currently manage a site which is localized per region, as opposed to country. For some regions, like US and Australia, it is 1:1 with country, so we do not have issues there. But for Europe, that is where we do have some issues currently. We took the following approach (below), but I have to first say that it is quite problematic and has not performed very well so far (implemented about 1 year ago). The approach we took was to implement HREFLANG within our sitemap, and for Europe, we generate specific alternate locations for each of the countries where we do business in that region, all with the same URL. Here (below) is a redacted version of one page's LOC node in our sitemap (I've only included a partial list, and only showing English, as the full list of alternate URLs for this one LOC has 150 alternate links to cover every EU country x 5 languages we support). But, the general approach is that for Europe, we create one alternate link for each EU country, in each of our supported languages (we support 5 languages). So, we don't assume, for example, that German speakers are only in Germany, or that English speakers are only in the UK. We cover every country/language combination and point many of these to the exact same alternate link. Again, as I mentioned, this hasn't achieved all we had hoped. But sharing the approach for a reference point here, as an option, and open to any other ideas from the community. We also struggle with EU in terms of Google Search Console geographic targeting. Unfortunately, Google does not allow a property to be targeted to "Europe". And they only allow one single country per property. In our case, we really need to target a single domain to "Europe", not to a specific country. But we can't, and that is a problem currently. Here is the example from our Sitemap (partial cut-and-past of the first few entries from one URL node): <loc>https://www.example.com/example-page-path</loc> <priority>1</priority> ... remainder of alternate links removed to shorten list here |   |

So as long as the questions are in the related searches at the bottom, in the search bar at the top google or in Moz keyword tool I am ok correct ? and like you said if I am not an expert on pregnancy and biking lets not talk about it because it is a YMYL kind of answer.

Thanks for offering the help. Please check below pages as sample: https://www.vtiger.com/all-in-one-crm/contact-management/ https://www.vtiger.com/docs/contacts

Hi there, I know it's been a while, but were you able to figure it out? What happened after you requested a fetch? I'd love to do some type of case study on this with you if you still didn't recover.

As I understand it, the way Moz crawls means it won't pick up HTML that is added dynamically. Without knowing which site you are talking about, I can't check, but I worked with a client who had a site that dynamically generated areas of the page after the first draw and that caused some issues with the Moz crawler correctly identifying issues on the site. I would suggest checking with Search Console "Fetch as Google" tool just to make sure Google is "seeing" the page correctly, and, if so, ignore the alerts in Moz.

It's a tricky lesson to learn as Google often release posts and content which over-burdens developers with false-confidence (it's not the developer's fault). Basically, website owners and company owners often ask broad brush questions and pressure Google to respond with simple, succinct answers (like in Matt's old Webmaster videos). Google cave into this pressure and say stuff like "yeah doing redirects for your migration is good", but in some (not all) of their published content, completely neglect to mention that some redirect types are more worthy than others within the context of certain situations. Developers read posts written by Google and just think "ok fine that's how it is now so we just do that" and, of course - unless you make a livelihood studying all this stuff, you end up pretty far wide of the mark. I recently answered this question by a webmaster whom had taken it for granted that, because Google 'can' crawl JS they always will (under all circumstances). He made a move in terms of technical on-site architecture and saw loss as well Just ask the guys who know! And yes, do the redirects, you may as well. You might still get something back from it (probably not a lot though)

Thank you,

Google is probably not going to take any manual action based upon your complaint.   Keyword stuffing and hidden keywords have been around since the beginning of Google and they have algorithms that look for it.  These algorithms sometimes find it, sometimes don't find it, sometimes demote it and sometimes don't demote it. I would not spend time trying to report this type of action.  I would spend that time instead working on my website.

Hi Martijn, I checked my FIrefox, and not seeing any plugins or addons that would cause that issue. It is strange that it is only that one page. None of my other similar pages do that... Did it happen on your computer? Any other ideas? Greg

Many thanks, Donna. I'm seeing things completely different to you. Screwfix does use both variations on-page (METAs and content). They also rank #1 for both variations. Strange! I am searching from the UK, but the ranking Screwfix pages should be the same regardless. Lee

ehh. unless reposting to the other website naturally creates more backlinks (e.g. each site has its own separate audience that would increase the total number of backlinks) keeping the articles on separate sites and interlinking with keyword anchor text is probably the better strategy. content syndication works best when republishing to a new audience, on domains you don't already own.

Eccountant is Online Invoicing Software for small businesses. Create and send invoices and estimates, track time and expenses and accept online payments.

1. Good! 2. You are confused for good reason. There has not been clear direction for here for some time. If you used HREFLANG between the two, it seems for the last number of years the content would not be seen as duplicative. You are telling Google that the content is the same but in different languages inherently. 3. There is so much that goes into this, but I can tell you with years of experience under my belt that the numbers don't ever tell the whole story.

From my understanding of mobile-first indexing, your mobile site will become the primary version Google crawlers see when they are looking at your website. So in terms of the impact of hiding the breadcrumbs on your mobile site, Google will see that you've hidden them and may or may not see them on the desktop version because they may or may not bother to crawl the desktop version. My question to you would be - what value are you seeing from the breadcrumbs on desktop? Can you check your analytics data to see whether users are using these breadcrumbs for navigation? Do you mark up your breadcrumbs with schema to allow them to show up in rich snippets? If the breadcrumbs do not currently add much value to your users and if they don't serve an SEO purpose, you may not need to bother including them on mobile. On the other hand, if you know that they add to a better UX, you may see a benefit from adding them to the mobile version of the site. This is because Google likes to reward sites with a better UX for mobile users. If you are using them more for search engines to have easier crawl access, I would suggest revisiting your site structure more broadly to ensure that no important page is further than 3-4 clicks from the homepage; and/or ensure that you keep your sitemaps up to date with all important pages and submit in GSC and BWT.

Thanks for your advise..  That  clears up the mis-conception for me since i would have thought the content actually stays the same other than the products shown.    we're having some minor dramas with some parameters being indexed despite having parameters configured in search console. hence i was wondering if the canonical setup was something to do with it.   I'm thinking i try and look into no-index follow system instead for paginated series.

Hi there. What we know for certain is that these kinds of signals show up in manual warnings delivered via Search Console, and are a signal that a human quality reviewer would pay attention to. Everything about exactly what Google is doing algorithmically has some element of guesswork to it, but this is a machine-detectable pattern that I would think would be very likely to be detected automatically and the links discounted. [Sidenote: it wouldn't be the crawler that did this - it would happen at some stage after that - just a semantic difference, but thought it was worth adding for clarity.]

Thanks for confirming my thoughts. Some of these page _do _rank, but either for seemingly irrelevant terms or for terms that also rank the main lander page. Also, after checking the analytics, they drive almost no traffic.

You will want to set up multilingual hreflang tags across all pages. This will essentially tell crawlers "each of these URLs are actually the same 'page'. You should show the correct version based on the location of the visitor" which prevents them from treating it as duplicate content.

if the domain expired, then there wouldn't be a backlink to your website (Moz's index might just be out of date for that backlink). if thats the case, no need to worry about it.