This depends upon several factors, one of those being how large your brand is online and how powerful your site / domain is in terms of SEO authority / aggregate link equity. If you have a really big eCommerce site with lots of authority, building it out with clean / permalink faceted navigation (which results in more URLs and also more internal links) can be a really good thing.

If you have lots of authority, the re-distributing some of it to clean up the long-tail through site build-out and link creation is an excellent idea. But those new links and addresses should serve a purpose for end users (such as giving them more control in terms of searching all of your products). Equally if you are a giant informational resource like Wikipedia which is innately trusted by many (and linked to billions of times across the web) - you have enough equity to interlink almost all of your articles. Again it helps Wikipedia to sweep up long-tail traffic with some of their less known articles by giving those a boost.

If you have a small amount of SEO authority or you're just starting out, then these enterprise-level tactics will only detract (at least initially) from your SEO strategy. If you only have fragments of SEO authority and they're all constantly in transit, flying around through links to hundreds of pages... It ends up being like having 2-3 coins in the bottom tray ('main table') of one of those coin machines you find at a fairground (or maybe in a gambling / amusement arcade). They're often referred to as a 'medal game' or a 'coin pusher' (see this resource: https://en.wikipedia.org/wiki/Medal_game)

These are the games you play where, you drop something like a 2-pence coin into the top. The coin falls down a segmented back-plate and ends up 'somewhere' on the main table. If that area of the main table is already full of coins, your additional coin can trigger a cascade where you get more cash back out than you put in. Link structure is quite similar to this. If your 'main table' has lots of SEO authority and you use deep linking to slot a coin to the bottom, long-tail and mid-body rankings can come out. If your table has barely any coins on, then you just throw that link equity (symbolised by the coin) away with no true benefit 'coming out' the other end.

Think about the size of your site / brand and what it has already achieved online. Is now the time for deep-linking with such volume? If not, reign it in until later - at which point such tactics could really benefit you.

Because different sites are necessarily different sizes (through the features and functions they need to supply users with), and because different domains have totally different levels of SEO-equity / authority behind them (different amounts of coins on their main tables) - there are no hard-and-fast rules about how many internal (or external) links to deploy per page.

It depends entirely upon who you are, what you're worth (in traffic terms) and what your site has to do.

Here's a video of someone playing a 'coin pusher' - https://www.youtube.com/watch?v=MMhPnPfB_CI, I'm pretty sure you will see that, it's a decent analogy for those starting out in terms of looking at internal link structure

This is a good reply.

Everyone gets really confused because Robots.txt has very minor, partial wildcard support and that makes people think that Robots.txt files use Regex, which they do not. Instead of having some weird half and half implementation, it would be much better IMO if the Robots.txt initiative / directive were updated to say "yes, you can use full regular expressions with regards to URL string matching".

Many people are left in a kind of silly guessing game because Google doesn't 'properly' elaborate or invest in expanding the definitions to their currently (publicly) assumed end-game.

People assume that if "*" will match any string of characters, "?" will match any individual character when used in a robots.txt file. This would make sense, but it's not the case. AFAIK there are only one or two supported wildcard characters in Robots.txt and that's why people get confused, looking for escape characters and the suchlike.

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!

There are several ways to do this but it does depend somewhat on the architecture of the site which is hosting the link you have placed. For example, you will want to navigate around a bit to see the difference between links in review and those which have gone live. Quite commonly you will submit a link and get a temporary URL like https://somelocaldirectory.com/review/my-clients-company.

Once the link goes live the address can sometimes actually change to something more like https://somelocaldirectory.com/listings/us/california/automotive/insurance/my-clients-company. If you can work out how the architecture changes, you can simply build a list of the final URLs that 'should' exist (but don't yet) and you can query them daily to determine when the link goes live (most likely when it returns status code 200 / OK). Note that for this method your URL syntax needs to be near perfect as, for example - if you end the URL string with a slash ("/") and the site uses 301 redirects to strip all trialling slashes, you will likely see the query turn from a 404 to a 301 instead of from a 404 to a 200 (so some common sense is needed).

You can build a spreadsheet with all your 'presumed' live links in and every day, run a VBA macro or use an Excel Add-In to return the status codes of the URLs housed within your query-column. You could install and utilise a plugin like SEO tools for Excel so that Excel's native formulae functionality is extended to return status codes (meaning you can write formulae such as "=HttpStatus(A1)"). The creator (Nimbasa I believe) has now made the plugin premium, but if you perform some advanced web searches you can still find the old version(s) from when the plugin was completely free. That version of the plugin (4.0.7 I believe) is fully compatible with Excel 2016 (32 or 64 bit) and it does have the status code checking function under the SEOTools->Onpage->HttpStatus menu entry.

If you can produce such a list of URLs you could also bulk query that list using Screaming Frog SEO Spider's list mode and just take the status codes from there. You could also write XPath expressions to check not only when those pages go live, but whether they are linking to your client's site, citing the URL in an unlinked way as well as detecting the nature of the link.

If all of that sounds like a lot of effort, I have found that running a 'backlink project' (not just checking via the front-end, setting up a backlink project for a specific site!) in Ahrefs seems to find most new links of reasonable value. It does rely on Ahrefs having indexed the site / URL in question, but as long as the site isn't pure spammy garbage their hyperlink indexation is really good. You can set up alerts via email to notify you of newly detected links! Once some new links are detected, you can check to see whether your assumed link is among those which was recently set live and then indexed by Ahrefs. This is much easier but is less accurate and usually your notifications of live links are a bit slower (3-10 days after the link 'really' goes live, Ahrefs usually finds it). You need an Ahrefs subscription, but it's a great tool - useful for many things.

For a solution that's quick, accurate and minimal hassle you really want to look at "Monitor Backlinks". There used to be free, downloadable tools which did pretty much the same thing.

One more flexible tool was the old freeware version of WebMon. It's a great tool for entering URLs and then receiving notifications when the HTML on a specified area of the page (could be the whole page, or just one link - etc) changes. Unfortunately the freeware version of the tool hasn't been updated in many years and for some reason it cannot support HTTPS URLs. This was no big deal at the time, but with most of the 'well-known' web shifting over to HTTPS, obviously this severely dampens the tool's utility.

Even if you don't want to purchase and utilise a tool like ScrapeBox, you may be interested to know that they released the handy (and free)ScrapeBox Link Checker. It's really very useful and may be just what you are after, but again it hinges on you knowing the URL (or URLs, plural) which your page / site is supposed to be receiving a hyperlink from. This tool is pretty neat and I end up using it now and then. To be fair you can do pretty much the same thing with Screaming Frog but it takes more XPath and / or Regex knowledge. I tend to use both as I find each tool finds some links that the other tool does not find (thus increasing my overall data integrity when checking thousands of backlinks for their live status).

Although it's primarily a link 'discovery' tool (much like Moz's Link Explorer), you can actually use Link Assistant's Power Suite SEO SpyGlass for this kind of work. You just start a project, once SEOSG pulls back some links - delete them all from the project. Then, import your own links and run the 'checker' which will query the specified URLs for links to your client's site. This one is pretty robust but it takes as few minutes to set up the project correctly and it's not extremely resource efficient. Again - I like to aggregate it with results from other tools to get a clearer, more realistic picture of who is (and is not) linking back.

All of these tools are great but they all work in different ways. Some will alert you to any new links to your site at the domain level (like Ahrefs) but rely on their own crawlers and indexation to keep up. Others can very quickly tell you exactly what's going on, but require being set up in a binary way - possibly with some coding know-how.

Try a few, see what you like. See what works for you!

Hope that helps

Oh dear what a kerfuffle. People are always searching for new negative-SEO assault deployments!

In February 2018 Moz actually covered the subject of cross-domain canonical tag usage:

• https://moz.com/blog/cross-domain-rel-canonical-seo-value-cross-posted-content

Apparently it can work but only under very specific circumstances:

• The content of the 'canonicaling' URL matches the canonical destination
• The headline of the 'canonicaling' URL's content matches that of the canonical destination
• In-Content Links of the 'canonicaling' URL match those of the canonical destination

So unless the content on their pages happens to be almost identical to the content on the page on your site which the tags are linking to; they're pretty much boneheads and this isn't a major concern.

In all likelihood nothing bad will happen but you could try using Google's Disavow tool (https://www.google.com/webmasters/tools/disavow-links-main) to send them a signal that you do not wish to be 'associated' with the spam-site in question. It is unknown (or at least I haven't heard) whether the disavow tool covers canonical links. I would think that it would at least prompt Google to fundamentally disassociate the two sites.

More than likely those behind the attack are fully aware that it is extremely unlikely to harm you. They probably have a network of machine-built sites launching the same (fake) attack against thousands of webmasters. My guess is that they are preying on ignorance, hoping that some webmasters will pay them to take the tags off.

DON'T fall for it