Fetching, rendering, caching and indexing are all different. Sometimes they're all part of the same process, sometimes not. When Google 'indexes' images, that's primarily for its image search engine (Google Images). 'Indexing' something means that Google is listing that resource within its own search results for one reason or another. For the same reasons that Google rarely indexes all of your web-pages, Google also rarely indexes all of your images.

That doesn't mean that Google 'can't see' your images and has an imperfect view of your web-page. It simply means that Google does not believe the image which you have uploaded are 'worthy' enough to be served to an end-user who is performing a certain search on Google images. If you think that gaining normal web rankings is tricky, remember that most users only utilise Google images for certain (specific) reasons. Maybe they're trying to find a meme to add to their post on a form thread or as a comment on a Social network. Maybe they're looking for PNG icons to add into their PowerPoint presentations.

In general, images from the commercial web are... well, they're commercially driven (usually). When was the last time you expressedly set out to search for Ads to look at on Google images? Never? Ok then.

First Google will fetch a page or resource by visiting that page or resource's URL. If the resource or web-page is of moderate to high value, Google may then render the page or resource (Google doesn't always do this, but usually it's to get a good view of a page on the web which is important - yet which is heavily modified by something like JS or AJAX - and thus all the info isn't in the basic 'source code' / view-source).

Following this, Google may decide to cache the web-page or resource. Finally, if the page or resource is deemed worthy enough and Google's algorithm(s) decide that it could potentially satisfy a certain search query (or array thereof) - the resource or page may be indexed. All of this can occur in various patterns, e.g: indexing a resource without caching it or caching a resource without indexing it (there are many reasons for all of this which I won't get into now).

On the commercial web, many images are stock or boiler-plate visuals from suppliers. If Google already has the image you are supplying indexed at a higher resolution or at superior quality (factoring compression) and if your site is not a 'main contender' in terms of popularity and trust metrics, Google probably won't index that image on your site. Why would Google do so? It would just mean that when users performed an image search, they would see large panes of results which were all the same image. Users only have so much screen real-estate (especially with the advent of mobile browsing popularity). Seeing loads of the same picture at slightly different resolutions would just be annoying. People want to see a variety, a spread of things! **That being said **- your images are lush and I don't think they're stock rips!

If some images on your page, post or website are not indexed - it's not necessarily an 'issue' or 'error'.

Looking at the post you linked to: https://flothemes.com/best-lightroom-presets-photogs/

I can see that it sits on the "flothemes.com" domain. It has very strong link and trust metrics:

Ahrefs - Domain rating 83

Moz - Domain Authority - 62

As such, you'd think that most of these images would be unique (I don't have time to do a reverse image search on all of them) - also because the content seems really well done. I am pretty confident (though not certain) that quality and duplication are probably not to blame in this instance.

That makes me think, hmm maybe some of the images don't meet Google's compression standards.

Check out these results (https://gtmetrix.com/reports/flothemes.com/xZARSfi5) for the page / post you referenced, on GTMetrix (I find it superior to Google's Page-Speed Insights) and click on the "Waterfall" tab.

You can see that some of the image files have pretty lard 'bars' in terms of the total time it took to load in those individual resources. The main offenders are this image: https://l5vd03xwb5125jimp1nwab7r-wpengine.netdna-ssl.com/wp-content/uploads/2016/01/PhilChester-Portfolio-40.jpg (over 2 seconds to pull in by itself) and this one: https://l5vd03xwb5125jimp1nwab7r-wpengine.netdna-ssl.com/wp-content/uploads/2017/04/Portra-1601-Digital-2.png (around 1.7 seconds to pull in)

Check out the resource URLs. They're being pulled into your page, but they're not hosted on your website. As such - how could Google index those images for your site when they're pulled in externally? Maybe there's some CDN stuff going on here. Maybe Google is indexing some images on the CDN because it's faster and not from your base-domain. This really needs looking into in a lot more detail, but I smell the tails of something interesting there.

If images are deemed to be uncompressed or if their resolution is just way OTT (such that most users would never need even half of the full deployment resolution) - Google won't index those images. Why? Well they don't want Google Images to become a lag-fest I guess!

**Your main issue is that you are not serving 'scaled' images **(or apparently, optimising them). On that same GTMetrix report, check out the "PageSpeed" tab. Yeah, you scored an F by the way (that's a fail) and it's mainly down to your image deployment.

Google thinks one or more of the following:

• You haven't put enough effort into optimising some of your images
• Some of your images are not worth indexing or it can find them somewhere else
• Google is indexing some of the images from your CDN instead of your base domain
• Google is having trouble indexing images for your domain, which are permanently or temporarily stored off-site (and the interference is causing Google to just give up)

I know there's a lot to think about here, but I hope I have at least put you on the 'trail' a reasonable solution

This was fun to examine, so thanks for the interesting question!

Google doesn't seem to have a problem with this:

https://developers.google.com/web/fundamentals/design-and-ux/responsive/images

"TL;DR

• Use relative sizes for images to prevent them from accidentally overflowing the container.
• Use the picture element when you want to specify different images depending on device characteristics (a.k.a. art direction).
• Use srcset and the x descriptor in the img element to give hints to the browser about the best image to use when choosing from different densities.
• If your page only has one or two images and these are not used elsewhere on your site, consider using inline images to reduce file requests.

-

Enhance imgs with srcset for high DPI devices

The srcset attribute enhances the behavior of the imgelement, making it easy to provide multiple image files for different device characteristics. Similar to the image-set CSS function native to CSS, srcset allows the browser to choose the best image depending on the characteristics of the device, for example using a 2x image on a 2x display, and potentially in the future, a 1x image on a 2x device when on a limited bandwidth network."

This part seemed most important to me:

"On browsers that don't support srcset, the browser simply uses the default image file specified by the src_ attribute. This is why it is important to always include a 1x image that can be displayed on any device, regardless of capabilities._ "

... so basically you define your srcset as per Google's documentation, but you must be sure to include a default fallback image that could work on all browsers and devices - that's what gets used if the browser is unable to interpret your srcset (or if your srcset doesn't include anything for the specified browser)

This is a really good question and something with which, I am at least personally experienced with - in terms of having done recent research on the subject

Recently we (at Effect Digital, UK) moved office. I say recently, it was probably nearly a year ago now. Previously we had been using Moz Local, but were shocked to find that simple features like 'changing' or 'updating' our business address were not supported. The problem comes down to directory aggregators (the main offender being Central Index) and how they interact with various listing suppliers

When Moz Local failed to update our business address, we tried to contact a lot of directory-owners (and directory aggregators like Central Index) manually. Trust me when I say, the largest ones (like Central Index, which handle the majority of your directory listings across local newspaper sites - at least here in the UK) do not want to hear from you at all

We submitted contact forms, spent hours browsing to hidden contact URLs, even found a phone number for them - which rang for a minute, then forwarded to a separate disconnected number. These guys don't care about receiving updates from Moz and they don't care about your update requests. They don't even want to listen to you, for 2 minutes

The problem with Moz local, as a Moz rep told us - is that when they push data (from Moz's Local database, to the databases of aggregate listing handlers like Central Index), there is no legal agreement requiring the aggregator(s) to accept Moz's update(s). They will accept Moz Local's first set of data, but if you ever want to change anything substantial - that rapidly becomes a massive problem. Moz Local is a great way to take your first steps into local listings handling, but the solution isn't end-to-end, or rigorous enough for on-going usage

Yext is much better, from the sounds of it. Myself and another experienced colleague spent some hours on the phone to their support people who seemed qualified and able to handle our complex queries. They stated to us that, they have a more 'direct' agreement with listing aggregators which directly pushes their data over the top of everyone else's. That tells me that, either their solution works well or - if it didn't work, you'd have recourse to push them to get things sorted out. They take more responsibility and really try to make sure that their updates 'actually' end up live in aggregator databases (which is great)

We didn't end up using Yext because, as an SMB the pricing was pretty severe. We were told that Yell basically re-sell Yext's technology to smaller businesses and that we'd have better luck with Yell. Whilst Yell may be based on the same technology, the support is woefully inferior and I'd never recommend working with Yell. We had one rep visit us to answer technical questions. He knew none of the answers to our questions, knew nothing about SEO and actually had the tenacity to try and 'steer' us toward purchasing some crappy directory listing on Yell which wasn't at all what we wanted (or were interested in)

Moz is great when you're starting out, but because the 'deals' they have with data aggregators aren't 'forceful' enough, it's not a good on-going solution (Moz know this and said as much to us over the phone). It's still the best place for you to 'start' as the prices are great and it does function well, until more crucial data changes are required (at which point it falls flat on its face)

At that point you really should be going with Yext if you can afford Yext. The product is superior, the support is very strong (Moz's support is actually great too, but hindered by the product which is defective under some specific circumstances). In-between the cheap and cheerful Moz and the very expensive Yext, there's nothing good enough to fill the void (which sucks!)

You may have some luck manually adjusting some listings. But for the ones controlled by central databases which fire their data out to many directories, your only real option to have a reasonable shot at getting them changed - is assuredly Yext

Tim Holmes gave a good answer but it does assume your redirects are being applied via a .htaccess file which is the usual method if your website is hosted on a Linux / Apache server.

If your website runs on a Windows / IIS server, then instead of implementing your redirect rules via .htaccess you'd be using web.config instead. Obviously most plugins (especially on common platforms like WordPress) are coded to interact with a .htaccess file. If you're running on IIS instead they could break stuff or at the least fail to function entirely.

On Google you can find many posts complete with web.config instructions:

https://www.google.com/search?num=100&q=https+redirect+for+web.config

This is the one which Google gives the knowledge-graph entry to:

https://www.ssl2buy.com/wiki/http-to-https-redirect-using-htaccess-or-web-config

The second part of the content deals with Windows.

Checking that your SSL certificate is correctly installed, valid and provided by a supplier which Google accepts is highly advisable. If browsing to an HTTPS URL on Chrome yields warnings or 'not secure' messages, it's safe to say that Google has not accepted your SSL certificate. If you can't even browse to HTTPS URLs, something is likely wrong with the install!

Hope that helps

Google can crawl JavaScript and its contents, but most of the time they are unlikely to do so. In order to do this, Google has to do more than just a basic source code scrape. Like everyone else seeking to scrape data from inside of generated elements, Google has to actually check the modified source-code, after all of the scripts have run (the render) rather than the base (non-modified) source code before any scripts fire

Google's mission is to index the web. There's no doubt that, non-rendered crawls (which do not contain the generated HTML output of scripts) can be done in a fraction of the time it takes to get a rendered snapshot of the page-code. On average I have found rendered crawling to take 7x to 10x longer than basic source scraping

What we have found is that Google are indeed, capable of crawling generated text and links and stuff... but they won't do this all the time, or for everyone. Those resources are more precious to Google and they crawl more sparingly in that manner

If you deployed the link in the manner which you have described, my anticipation is that Google would not notice or evaluate the link for a month or two (if you're not super popular). Eventually, they would determine the presence of the link - at which point it would be factored and / or evaluated

I suppose you could embed the script as a link to a '.js' module, and then use Robots.txt to ban Google from crawling that particular JavaScript file. If they chose to obey that directive, the link would pretty much remain hidden from them. But remember, it's only a directive!

If you wanted to be super harsh you could block Googlebot (user agent) from that JS file and do something like, 301 them to the homepage when they tried to access it (instead of allowing them to open and read the JS file). That would be pretty hardcore but would stand a higher chance of actually working

Think about this kind of stuff though. It would be pretty irregular to go to such extremes and I'm not certain what the consequences of such action(s) would be

How long has it been since you uploaded the images? Implementation in Google's SERPs isn't instant

There are three potential issues

1. You haven't waited long enough

2. Your organisation has had staff turn-over and through time multiple GMB listings were created for you. The one you have the logins to, might be the wrong one

3. Your brand's search entity is not yet considered to be important enough to solicit the "see photos" box for your knowledge panel

From the images it seems as if you represent the Specsavers inside of Broadway Sydney (a shopping mall, I think) in Australia (New South Wales?)

I actually am seeing the photos now, so maybe this issue is no longer a problem for you (most likely that #1 applied, at the time you authored your question - I think we can rule out #3 as it's Specsavers)

Check this

https://www.google.com.au/search?q=specsavers%20broadway%20sydney

• https://d.pr/i/OGO9eL.png (SERP screenshot)

That's using Australian Google (Google.com.au) but the screenshot is taken from a UK IP address

I switched to a Melbourne IP address (Aus) using Surfshark and I saw the same thing. My thought is, this is working now and you just hadn't waited quite long enough for the store images to be appended to your brand SERP

Ok let's have a look here.

So this is the URL of the page you want me to look at:

• https://www.nubalustrades.co.uk/

I can immediately tell you that, from my end it doesn't look like Google has even cached this page at all:

• http://webcache.googleusercontent.com/search?q=cache:https%3A%2F%2Fwww.nubalustrades.co.uk%2F (live)
• https://d.pr/i/DhmPEr.png (screenshot)

As you know I can't fetch someone else's web page as Google, but I do know Screaming Frog pretty well so let's give that a blast

First let's try a quick crawl with no client-side rendering enabled, see what that comes back with:

• https://d.pr/f/u3bifA.seospider (SF crawl file)
• https://d.pr/f/9TfNR5.xlsx (Excel spreadsheet output)

Seems as if, even without rendered crawling the words are being picked up:

• https://d.pr/i/426Ck9.png

Only the rows highlighted in green (the 'core' site URLs) should have a word count anyway. The other URLs are fragments and resources. They're scripts, stylesheets, images etc (none of which need copy).

Let's try a rendered crawl, see what we get:

• https://d.pr/f/ijprbx.seospider (SF crawl file)
• https://d.pr/f/c8ljoF.xlsx (Excel spreadsheet output)

Again - it seems as if the words are picked up, though oddly fewer are picked up with rendered crawling than with a simple AJAX source scrape:

• https://d.pr/i/y3Jv51.png

That could easily be something to do with my time-out or render-wait settings though (that being said I did give a pretty generous 23 seconds so...)

In any case, it seems to me that the content is search readable in either event.

Let's look at the homepage specifically in more detail. Basically if content appears in "inspect element" but not in "view source", **that's **when you know you have a real problem

• view-source:https://www.nubalustrades.co.uk/ - (you can only open this link with Chrome browser, it's free to download from Google)

As you can see, lots of the content does indeed appear in the 'base' source code:

• https://d.pr/i/8BzTjd.png

That's a good thing.

That being said, each piece of content seems to be replicated twice in the source code which is really weird and may be creating some content duplication issues, if Google's more simple crawl-bots aren't taking the time to analyse the source code correctly.

Go back here:

• view-source:https://www.nubalustrades.co.uk/ - (this link only works in Chrome!)

Ctrl+F to find the string of text: "issued by the British Standards Institution". Hit enter a few times. You'll see the page jump about.

On the one hand you have this, further up the page which looks alright:

https://d.pr/i/8AlJJ1.png

On the other hand you have this further down which looks like a complete mess, embedded within some kind of script or something?

https://d.pr/i/mJJaqa.png

Line 6,212 of the source code is some gigantic JavaScript thing which has been in-lined (and don't get me started on how this site is over-using inline code in general, for CSS, JS - everything). No idea what it's for or does, might be deferred stuff to boost page speed without breaking the visuals or whatever (there are many clever tricks like that, but they make the source code a virtually unreadable mess for a human - let alone a programmed bot!)

What really concerns me is why such a simple page needs to have 6,250 lines of source code. That's mental!

What we all forget is that, whilst the crawl and fetch bots pull information quickly - Google's algorithms have to be run over the top of that source code and data (which is a much more complex affair)

Usually people think that  normalizing the code-to-text ratio is a pointless SEO maneuver and in most cases, yes the return is vastly outweighed by the time taken to do it. But in your case it's actually very extreme:

• https://www.prepostseo.com/code-to-text-ratio

Put your URL in and you'll get this:

• https://d.pr/i/nXBu0S.png

I tried like 5-8 different tools and this was the most favorable result :')

It is clear that, even were the page successfully downloaded by Google, their algorithms may have trouble hunting out the nuggets of content within the vast, sprawling and unnecessary coding structure. My older colleagues had always warned me away from Wix... now I can see why, with my own two eyes

Ok. So we know that Google isn't bothering to cache the page, and that - despite the fact your content can 'technically' be crawled, it may be a marathon to do that and dig it out (especially for non-intelligent robots)

But is the content being indexed? Let's check:

• https://www.google.co.uk/search?q=site%3Anubalustrades.co.uk+%22issued+by+the+British+Standards+Institution%22
• https://www.google.co.uk/search?num=100&ei=q_MYXMj3EM_srgSNh6LYCQ&q=site%3Anubalustrades.co.uk+%22product+and+your+happy+with%22
• https://www.google.co.uk/search?num=100&ei=6vMYXPuLC4yYsAXAoKfAAg&q=site%3Anubalustrades.co.uk+%22Some+customers+like+to+have+more+than+one+balustrade%22
• https://www.google.co.uk/search?num=100&ei=CPQYXOmJFYu6tQXi8arwBA&q=site%3Anubalustrades.co.uk+%22installations+which+will+help+you+visualise+your+future+project%22
• https://www.google.co.uk/search?num=100&ei=KvQYXMyhC4LStAWopbqACg&q=site%3Anubalustrades.co.uk+%22Cleanly-designed%2C+high-quality+handrail+systems+combined+with+attention%22

Those are all special Google search queries, designed to specifically search for strings of content on your website from all the different, primary content boxes

Good news fella, it's all being found:

• https://d.pr/i/Zlb926.png

Let's make up an invalid text string and see what Google returns when text can't be found, to validate our findings thus-far:

• https://www.google.co.uk/search?num=100&ei=SfQYXJitEomwtQWRk43QDg&q=site%3Anubalustrades.co.uk+%22what+the+heck+I+don%27t+even+I+never+wrote+this+on+my+site+how+dare+you%22

If nothing is found you get this:

• https://d.pr/i/FGvT49.png

So I guess Google can find your content and is indexing your content

Phew, crisis over! Onto the next one...

I think what we really need to understand is, what is the purpose of hiding the link from Google? If it's to prevent the discovery of a URL or prevent the indexation of a certain page (or set of pages) - it's easier to achieve the same thing by using Meta no-index directives or wildcard-based robots.txt rules or by simply denying Gooblebot's user-agent, access to certain pages entirely

Is is that important to hide the link, or is it that you want to prevent access to certain URLs from within Google's SERPs? Another option is obviously to block users / sessions referred from Google (specifically) from accessing the pages. There's lots can be done, but a bit of context would be cool

By the way, no-follow does not prevent Google from following links. It actually just stops PageRank from passing across. I know, it was named wrong

This is really weird. Really really weird!

As you say, your site's source code seems to confirm that it is set to index. If we look here, we can plainly see that the coding syntax for a no-index directive is "noindex" (all one word).

Let's look at your source code:

• https://d.pr/i/RAYzE4.png

Yep, everything seems fine there! But what if a script is modifying your source code and including the directive - and Google's picking up on that?

If we look at the modified source code which I rendered and saved to a file here:

• https://d.pr/f/1ZKNfF.php

... we can see, there are no problems here either:

• https://d.pr/i/kcxO0z.png

Wow - that's really unhelpful!

Let's see what happens if we specifically search Google's live index for the URL:

• https://d.pr/i/944xFl.png

Interestingly, when we search Google's index for this page, we get this page returned instead.

It makes sense that Google would return that URL if it couldn't return the main URL, as one is nested inside of the other. If everything was healthy, we'd see Google listing both URLs instead of just one of them. Even if you edit my index query to remove the trailing slash, you still only get the nested URL (not the one you want to be showing, which is at a slightly higher-up level)

Another thought I had was, hmm maybe this is a canonical tag gone rogue. That bore no fruit either, as this page (which you want to index, yet won't) canonicals to this page - and both of those URLs are exactly the same. As such, it's obvious that we can't blame the canonical tag either! I even viewed the modified source to see if it got altered, no dice (the canonical tag is just fine)

Maybe the XML file is telling Google not to index the URL?

• https://d.pr/i/dvbCfy.png

Nope - that's fine too! No problems there...

Could the robots.txt file be interfering?

• https://d.pr/i/DmAN1t.png

No! Darn it, that's not the problem

I know that a no-index or blocking directive can also be sent through the HTTP header (usually via X-robots). Let's check the response header of your URL out:

• https://d.pr/i/cy0MoW.png

Nothing there that really raises my eyebrow. This is enabled and set to block, but to be honest that shouldn't affect Google's crawling at all. Anyone correct me if I am wrong, but defending your site against cross-site scripting (XSS) attacks doesn't impede crawling right?

Fudge it. Let's fling it through Google's Page-Speed Insights tool. Usually that will tell you if something is being blocked and why...

• https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.onlinemortgageadvisor.co.uk%2Fbad-credit-mortgages%2Fhow-to-get-a-mortgage-with-bad-credit%2F&tab=desktop

Nothing useful still!

Google's mobile friendly tool gives us some, semi-interesting information:

• https://search.google.com/test/mobile-friendly?view=fetch-info&id=g4uSC2GcoipwxKk-PtqN2Q

But it doesn't say the page can't be loaded. It only says some resources which the page pulls in can't be loaded! And guess what? They're all external things on other websites (other than a few theme related bits, but nothing IMO that should stop the whole page loading).

Let's try DeepCrawl's indexability checker (they make amazing software by the way... expensive though):

• https://d.pr/i/Iyrzq5.png

Sir... there is NO GOOD REASON why your URL shouldn't be indexed. I am 99.9% certain you have encountered a legit Google bug. Post about it here. Only Google can help you at this juncture

I haven't had experience with this personally, but I think it could be worth it to try

Firstly you have to entirely separate your view of North and South Korea's 'internet situation' as they are both radically different

North Korea

https://en.wikipedia.org/wiki/Internet_in_North_Korea

"Connection to the internet in North Korea is done via Naenara, a modified version of Firefox that can access approximately 1,000 to 5,500 websites in the internet. It runs on Red Star OS, a North Korean Linux distribution."

"Nearly all of North Korea's Internet traffic is routed through China."

... so you might think, hmm maybe it will be impossible. As you may know, the most popular search engine in China is Baidu (not Google).  Now I can personally tell you that signing up for Baidu tools (equivalent of Google Search Console) is virtually impossible if you're not native to China. If you can get through the (non-translated) login / setup steps AND provide a Chinese landline number for verification purposes (and collect on that number) you stand a sliver of a chance

I actually once set up one of my own sites on there, it took hours / days to do it. Then - in a few months, I was randomly un-added and removed. The truth is, they don't really want too many Western influences appearing in Chinese search results. Even being seen to promote certain Western ideologies (even if you're not slating or attacking the Chinese state, which I would never do) - you can still be removed 'just like that' with no explanation, no recourse and no means to address the situation (period)

So now you might be thinking, well since almost all of North Korea's internet activity is routed through China, and since Baidu are so impossible to work with - is it really worth even bothering?

There is a small ray of hope: https://dailycaller.com/2018/04/03/most-popular-internet-search-engine-in-north-korea/

Apparently, even though most of North Korea's internet traffic is routed through China, unlike China - North Korean web-users more frequently use Google. So actually the issues surrounding Baidu, aren't so relevant to North Korea

That being said, you might wonder - is there much point in trying to appear on Google's results there, since North Korean users can only access "approximately 1,000 to 5,500 websites in the internet" (a tiny section of the web's true content)

If users in North Korea can type things into Google and your site comes up. but then when users click on your site they are blocked from accessing it (as your site isn't not one of the state-approved 5.5k which are accessible) - then really what's the point?

IMO there's not much you can do here, not many ways to reach people and there are probably better ways to spend your marketing / web / SEO budget

South Korea

https://en.wikipedia.org/wiki/Internet_in_South_Korea

"About 45 million people in South Korea (or 92.4% of the population) use the Internet.The country has the world's fastest average internet connection speed. South Korea has consistently ranked first in the UNICT Development Index since the index's launch. The government established policies and programs that facilitated the rapid expansion and use of broadband."

A completely different situation!

http://gs.statcounter.com/search-engine-market-share/all/south-korea

Many people in South Korea have very fast broadband, access to much of the web's contents and they prefer Google over something like Baidu. The key thing is that when someone sees your Google result listed in South Korea, if they click it they are unlikely to be blocked from getting through to you

I'd say that the South Korean market and culture, which has such an involved and socially integrated web-sub-culture, could assuredly be worth targeting. You'd almost assuredly have to translate your keywords into the right language, and even the right alphabet - according to Google Trends which does seem to suggest that people in South Korea primarily search in their own language (not in English):

https://trends.google.com/trends/trendingsearches/daily?geo=KR

For North Korea you can't even get to or see similar data: https://trends.google.com/trends/trendingsearches/daily?geo=KP - "Daily search trends are not available for this region. Try a different region"

Keep in mind that in South Korea, many searches happen when people are out and about, in cyber / web cafes etc

Final Thoughts

North Korea is too difficult to penetrate from a search POV, even though Google is their primary search engine. For South Korea it's a different story, their population is very web-accessible and celebrates online / cyber culture. You would have to translate all your keywords into the South Korean alphabet and language, and use Google's Keyword Planner as a guide in terms of average monthly search volumes

I personally wouldn't invest time in trying to reach people in North Korea. I don't have a problem with the North, it's just simply that it is very, very hard to reach them and the cost of doing so would probably out-weight the potential financial gains

For South Korea, it's different - I'd certainly have a go

Really interested to see that others have been receiving this too, we have been having this flagged on a couple of sites / accounts over the past month or two

Basically, Google Data Studio's schema error view is 'richer' than that of Google's schema tool (stand-alone) which has been left behind a bit in terms of changing standards. Quite often you can put the pages highlighted by GSC (Google Search Console) into Google's schema tool,  and they will show as having warnings only (no errors) yet GSC says there are errors (very confusing for a lot of people)

Let's look at an example:

• https://d.pr/i/xEqlJj.png (screenshot step 1)
• https://d.pr/i/tK9jVB.png (screenshot step 2)
• https://d.pr/i/dVriHh.png (screenshot step 3)
• https://d.pr/i/X60nRi.png (screenshot step 4)

... basically the schema tool separates issues into two categories, errors and warnings

But Google Search Console's view of schema errors, is now richer and more advanced than that (so adhere to GSC specs, not schema tool specs - if they ever contradict each other!)

What GSC is basically saying is this:

"Offers, review and aggregateRating are recommended only and usually cause a warning rather than an error if omitted.  However, now we are taking a more complex view. If any one of these fields / properties is omitted, that's okay but one of the three MUST now be present - or it will change from an warning to an error. SO to be clear, if one or two of these is missing, it's not a big deal - but if all three are missing, to us at Google - the product no longer constitutes as a valid product"

So what are the implications of having schema which generates erroneous, invalid products in Google's eyes?

This was the key statement I found from Google:

Google have this document on the Merchant Center (all about Google Shopping paid activity): https://support.google.com/merchants/answer/6069143?hl=en-GB

They say: "Valid structured markup allows us to read your product data and enable two features: (1) Automatic item updates: Automatic item updates reduce the risk of account suspension and temporary item disapproval due to price and availability mismatches. (2) Google Sheets Merchant Center add-on: The Merchant Center add-on in Google Sheets can crawl your website and uses structured data to populate and update many attributes in your feed. Learn more about using Google sheets to submit your product data. Prevent temporary disapprovals due to mismatched price and availability information with automatic item updates. This tool allows Merchant Center to update your items based on the structured data on your website instead of using feed-based product data that may be out of date."

So basically, without 'valid' schema mark-up, your Google Shopping (paid results) are much more likely to get rejected at a higher frequency, as Google's organic crawler passes data to Google Shopping through schema (and assumedly, they will only do this if the schema is marked as non-erroneous). Since you don't (well, you haven't said anything about this) use Google Shopping (PLA - Product Listing Ads), this 'primary risk' is mostly mitigated

It's likely that without valid product schema, your products will not appear as 'product' results within Google's normal, organic results. As you know, occasionally product results make it into Google's normal results. I'm not sure if this can be achieved without paying Google for a PLA (Product Listings Ad) for the hypothetical product in question. If webmasters can occasionally achieve proper product listings in Google's SERPs without PLA, e.g like this:

https://d.pr/i/XmXq6b.png (screenshot)

... then be assured that, if your products have schema errors - you're much less likely to get them listed in such a way for for free. In the screenshot I just gave, they are clearly labelled as sponsored (meaning that they were paid for). As such, not sure how much of an issue this would be

For product URLs which rank in Google's SERPs which do not render 'as' products:

https://d.pr/i/aW0sfD.png (screenshot)

... I don't think that such results would be impacted 'as' highly. You'll see that even with the plain-text / link results, sometimes you get schema embedded like those aggregate product review ratings. Obviously if the schema had errors, the richness of the SERP may be impacted (the little stars might disappear or something)

Personally I think that this is going to be a tough one that we're all going to have to come together and solve collectively. Google are basically saying, if a product has no individual review they can read, or no aggregate star rating from a collection of reviews, or it's not on offer (a product must have at least one of these three things) - then to Google it doesn't count as a product any more. That's how it is now, there's no arguing or getting away from it (though personally I think it's pretty steep, they may even back-track on this one at some point due to it being relatively infeasible for most companies to adopt for all their thousands of products)

You could take the line of re-assigning all your products as services, but IMO that's a very bad idea. I think Google will cotton on to such 'clever' tricks pretty quickly and undo them all. A product is a product, a service is a service (everyone knows that)

Plus, if your items are listed as services they're no longer products and may not be eligible for some types of SERP deployment as a result of that

The real question for me is, why is Google doing this?

I think it's because, marketers and SEOs have known for a long time that any type of SERP injection (universal search results, e.g: video results, news results, product results injected into Google's 'normal' results) are more attractive to users and because people 'just trust' Google they get a lot of clicks

As such, PLA (Google Shopping) has been relatively saturated for some time now and maybe Google feel that the quality of their product-based results, has dropped or lowered in some way. It would make sense to pick 2-3 things that really define the contents of a trustworthy site which is being more transparent with its user-base, and then to re-define 'what a product is' based around those things

In this way, Google will be able to reduce the amount of PLA results, reduce the amount of 'noise' they are generating and just keep the extrusions (the nice product boxes in Google's SERPs) for the sites that they feel really deserve them. You might say, well if this could result in their PLA revenue decreasing - why do it? Seems crazy

Not really though, as Google make all their revenue from the ads that they show. If it becomes widely known that Google's product-related search results suck, people will move away from Google (in-fact, they have often quoted Amazon as being their leading competitor, not another search engine directly)

People don't want to search for website links any more. They want to search for 'things'. Bits of info that pop out (like how you can use Google as a calculator or dictionary now, if you type your queries correctly). They want to search for products, items, things that are useful to them

IMO this is just another step towards that goal

Thank you for posting this question as it's helped me get some of my own thoughts down on this matter

Both are directives to google. All of the "rel=" links are directives, including hreflang, alternate/mobile, AMP, prev/next

It's not really necessary to use a canonical tag in addition to any of the other "rel=" family links

A canonical tag says to Google: "I am not the real version of this page, I am non-canonical. For the canonical version of the page, please follow this canonical tag. Don't index me at all, index the canonical destination URL"

The pagination based prev/next links say to Google: "I am the main version of this page, or one of the other paginated URLs. Did you know, if you follow this link - you can find and index more pages of content if you want to"

So the problem you create by using both, is creating the following dialogue to Google:

1.) "Hey Google. Follow this link to index paginated URLs if they happen to have useful content on"

*Google goes to paginated URL

2.) "WHAT ARE YOU DOING HERE Google!? I am not canonical, go back where you came from #buildawall"

*Google goes backwards to non-paginated URL

3.) "Hey Google. Follow this link to index paginated URLs if they happen to have useful content on"

*Google goes to paginated URL

4.) "WHAT ARE YOU DOING HERE Google!? I am not canonical, go back where you came from"

*Google goes backwards to non-paginated URL

... etc.

As you can see, it's confusing to tell Google to crawl and index URLs with one tag, then tell them not to with another. All your indexation factors (canonical tags, other rel links, robots tags, HTTP header X-Robots, sitemap, robots.txt files) should tell the SAME, logical story (not different stories, which contradict each other directly)

If you point to a web page via any indexation method (rel links, sitemap links) then don't turn around and say, actually no I've changed my mind I don't want this page indexed (by 'canonicalling' that URL elsewhere). If you didn't want a page to be indexed, then don't even point to it via other indexation methods

A) If you do want those URLs to be indexed by Google:

1) Keep in mind that by using rel prev/next, Google will know they are pagination URLs and won't weight them very strongly. If however, Google decides that some paginated content is very useful - it may decide to rank such URLs

2) If you want this, remove the canonical tags and leave rel=prev/next deployment as-is

B) If you don't want those URLs to be indexed by Google:

1) This is only a directive, Google can disregard it but it will be much more effective as you won't be contradicting yourself

2) Remove the rel= prev / next stuff completely from paginated URLs. Leave the canonical tag in place and also add a Meta no-index tag to paginated URLs

Keep in mind that, just because you block Google from indexing the paginated URLs, it doesn't necessarily mean that the non-paginated URLs will rank in the same place (with the same power) as the paginated URLs (which will be, mostly lost from the rankings). You may get lucky in that area, you may not (depending upon the content similarity of both URLs, depending whether or not Google's perceived reason to rank that URL - hinged strongly on a piece of content that exists only in the paginated URL variant)

My advice? Don't be a control freak and use option (B). Instead use option (A). Free traffic is free traffic, don't turn your nose up at it

Am pretty sure that Moz just unifies DA stats in some circumstances when they have no 'actual' data for the subdomain in question. Sites which are very important, which have a number of sub-domains (but not hundreds or thousands) often render different results for DA metrics. For some blog platforms (blogger is a good example, also "blogname.wordpress.com" WordPress hosted blogs) - they have thousands or hundreds of thousands of sub-domains and Moz can't index all of them

In these situations, if Moz comes across a subdomain which is well-linked across the web it will separate it out and ascribe unique values. For the rest (of which Moz holds no data), it probably just unifies the DA metric with the root domain

It's a symptom of an incomplete index of the web. That being said, no one has a complete index of the web - you have to work with what you got