Welcome to the Q&A Forum

Hi Alexandre,

Google should have no problem indexing URLs with Cyrillic characters, but it could be the mix of language that is causing Google to attempt to decode those characters.

But even if that were the case, this should not result in a 500 error but a 404 (not found) for those resultant decoded URLs.

It looks like there are 301 redirects in place for these URLs now, pointing to their EN counterparts - has that resolved this issue? Perhaps it was faulty redirect logic in the first place that caused the 500 errors?

Thanks,
Mike

Sitemap won't help you as there are no actual pages to index.

Not only are the pages called up via JavaScript, but they live inside an iFrame (which Google won't crawl).

Your best bet here is to scrap this site and build another one. Bottom line. The site is essentially invisible to Google.

I don't know of any instances of elements hidden on mobile causing a penalty or similar issue. So I can't give you criteria/examples.

With a truly responsive design, Googlebot and Googlebot Mobile are going to see the same source code. There should be no difference, just a difference in display settings based on viewport size.

Google publicly supports serving up entirely different source code for mobile users on the same URL - so hiding a few things with JavaScript/CSS based on viewport is relatively tame and has become a standard for delivering a fast-loading and usable mobile experience.

Hello,

As Martin suggested, it seems any option will require time and effort.

Are you sure these pages are causing an issue with duplicate content? Are they ranking and pulling traffic/sales?

I'm dubious these pages are having a negative impact. I would want to verify that as much as possible before expending the resource to canonical or take other action.

That said, canonical would be the recommended solution here - and should take no more effort than the "noindex" tag.

Best,
Mike

Hi Cesar,

1. Adding a canonical tag to the home page pointing to itself does nothing. It can help if someone scrapes your site and republishes it (they will probably scrape the canonical tag too, rendering their scraped/published URL unable to rank and effectively passing any link juice back to you). Otherwise, no need to canonical a page to itself.

2. The best method to send Google the proper signals about the corresponding link between desktop and mobile versions of your pages is to do the following:

• Add a rel="alternate" tag on the desktop version that points to the mobile version
• Add a rel="canonical" to the mobile version that points to the desktop version

Google uses rel="alternate" to serve up pages uniquely suited to particular users. It's used for language/regional specific pages as well as mobile.

Documentation is here: https://developers.google.com/webmasters/smartphone-sites/details

Best,
Mike

Hi Conor,

Sorry it's been so long without a response. This question was just assigned to me, but I haven't seen this issue before and can't offer any insight.

It's been a while now so you may have already sorted this.

If you're still stuck, let me know - I can flag this up to a wider group of people and see if anybody's seen this issue before. Worth a shot.

Best,
Mike

Hi Chris,

It's not entirely clear how this will impact SEO, but there is some indication hidden content could be weighted lower by Google.

Google has said in the past that such hidden content will not be weighted equally to visible content. In the early part of this blog post there's a helpful summary of Google engineering statements on this issue: https://www.freshegg.co.uk/blog/technical-seo/google/how-does-google-treat-hidden-content

It's at least somewhat likely that content contained in lightboxes will be weighted less than visible content. So while I'm not certain there is a downside, there could be and it's worth consideration for your new site design. There wouldn't be any kind of "penalty" for pages containing hidden content, but rankings for keywords/language contained in that content could be lower than they otherwise would be if the content were visible by default (without user interaction). I'd recommend planning for that.

Best,
Mike

Hi Thomas,

If I could jump in here - I think the two levels of 301 redirects won't sacrifice much. A small amount of link equity is lost through a 301, so you'll be doubling that, which isn't ideal, but if you are indeed anticipating hosting the job board at three separate locations, there won't be much of a way around this.

You could change the first level 301s (from the subdirectory) to skip the middle step and point right to the domain, and then 301 any pages on the subdirectory that built links to the domain, avoiding the multi-step 301s for the most part.

Provided your directory structure and page titles don't change much along the way, it shouldn't be too difficult to get the 301 redirects done, even if they're folder-to-subdomain-to-external-domain.

Best,
Mike

Hi Zack,

I think your concern here is valid (your render with Screaming Frog or any other client is unlikely to be precisely representative of what Googlebot will see/index). That said, I'm not sure there's much you can do to eliminate this knowledge gap for your QA process.

For instance, while we have seen Googlebot timing out JS rendering around the ~5s mark using the "Fetch & Render as Googlebot" functionality in Search Console (see slide 25 of Max Prin's slide deck here), there's no confirmation this time limit represents Googlebot's behavior in the wild.

Additionally, we know that Googlebot crawls with limited JS support - for instance, when a script uses JS to generate a random number, my colleague Tom Anthony found that Googlebot's random() JS function is deterministic (returns a predictable set) - so it's clear they have modified the headless version of Chrome they use to conserve computational expenses in this way. We can only assume they've taken other steps to save computing costs. This isn't baked-into Screaming Frog or any other crawling tool.

We have seen that with a 5s timeout set in Screaming Frog, the rendered result is pretty close to what "Fetch & Render as Googlebot" functionality demonstrates. And with the ubiquity of JS-driven content on the web today, provided links and content are rendered into the DOM fairly quickly (well ahead of that 5s mark), we've seen Google rendering and indexing JS content fairly reliable.

The ideal would be for your dev team to code these pages to degrade gracefully - so that even with JS support totally disabled, navigation and content elements are still rendered (they should be delivered in the page source, then enhanced with JS, if possible).

Failing that, the best you're likely to achieve here is reasonable confident that Googlebot can crawl, render and index these pages - there'll be some risk when you publish them to production.

Hope this helps somewhat - best of luck!

Thanks,
Mike

Hi Brad,

As others have indicated, there's no reason a 301 redirect on a missing image shouldn't work - it's all based on the URL request (not the actual resource served, since the server intercepts the request and forwards it to another URL along with the 301 status code).

I'd second Yaroslav's recommendation on a good WP plug-in for this (Redirection). You should be able to just use the URL string here to set the redirect where you want to point it.

I would also suggest double-checking that these are actual links pointing to the image URL, not embeds of that image on these pages (some tools will pick that up as a link). 
Finally, you may want to create a new page that includes a suitable replacement image if one is available, rather than redirecting to the replacement image file URL (bc this way the reclaimed PageRank will flow through to the rest of your site via your navigation).

Best,
Mike

I have not seen this particular problem with Facebook traffic before. You should only see Referral and Social traffic from Facebook.

Do you have any filters active on the Google Analytics profile in question that could be altering the Medium setting for this traffic?

Or is it possible that you have campaigns set up for Facebook traffic that have an incomplete use of UTM tracking parameters for Google Analytics?

One other possibility is that certain pages have been indexed by Google with the UTM tracking parameters included - this URL, for example, is indexed by Google, which is likely to be causing strange results in your analytics: http://www.wearyouwant.com/en/fb/?utm_source=Facebook&utm_medium=CPC&utm_term=free+shipping&utm_content=landing&utm_campaign=Facebook%2Blanding

Best,
Mike

seovp's advise is spot-on here.

I'd just add that "1-2 keywords per page" is really obsolete advice at this point, unfortunately. Google is doing a better job of every day of understanding synonyms and semantics and creating associations between language, pages and entities - this kind of granular keyword targeting is less impactful every day and also could flag you up for a Panda penalty.

You are entering a saturated market for sure. Outside of SEO, I'd be investing in creative ways to sell your products as well as get attention around your brand. Even in the long tail, you will find the competition fierce for these products, so you'll really have to find a unique way of doing things to get initial attention with a smart partnerships and promotions plan, which will translate into the links/shares/traffic that send the right signals to Google and raise your rankings across the board.

Best of Luck,
Mike

Hi Remko,

Apologies for the slow response here - the alert system that lets us know a question has gone unanswered broke down for a time.

The short answer: the ideal is to render the content/information as raw HTML, then use a JS library (whatever suits the animation or chart style you're after) to visualize and add animations.

Animations handled with jQuery, for example, won't be processed/"viewed" by Google, so if you're using such a library to add polish to your content, it's best that the page "degrades gracefully" - so that without JS support, the key content/information is still there in the HTML source.

While Google has made strides in their ability to render and index content delivered via JS resources, it is computationally expensive and we have seen that relying too heavily on JS to render the content itself is sub-optimal.

If you're following the above, any modern and widely-adopted JS animation/chart-building library should be fine.

Hope this helps,
Mike

Hi Roman,

John Mueller recently confirmed (though not very definitively as you'll see in the video) that Organization Schema only needs to be on the homepage.

From Google's Guidelines:

"Enable your company's contact information to prominently display customer service phone numbers in Google Knowledge Graph cards in some searches with corporate contact markup. Include the contact markup on one page in your official site."

Some disagree and suggest this is not the correct application of Schema (Oganization data should be included on all pages), but anecdotally (from what I've seen and heard) just the homepage seems to work fine for most sites.

Best,
Mike

Hi Kay,

These two example URLs do not seem to represent duplicate content - the listings are different for each page. I wouldn't want to set canonical tags on these pages as they are unique.

Did you see an error in an SEO tool of some kind indicating there was a duplicate content problem here?

For general applications, canonical tags should be added to the duplicate page(s) themselves, and those canonical tags should refer to the preferred/canonical page that you want to keep indexed (but no changes need to be made to the preferred/canonical page itself). So if these pages were true duplicates of your homepage, each duplicate would need the canonical tag  (but the homepage itself would not need to include the canonical tag).

From your examples, I'd just caution you may not be dealing with actual duplicate content - they look like valid pages to me.

Best,
Mike