This means that Google believe there is an error with the landing pages which you have entered for your ads. 9 times out of 10, this comes down to someone putting the wrong URL into the Google Ads back-end and then having issues. This is especially the case for 3XX errors which usually indicate that redirects are at play. In your case, the story seems to be a bit different

Google is telling you that when they visit your landing URLs for your ads, instead of the ad connecting straight to the page, Google gets redirected:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304##targetText=The%20HTTP%20304%20Not%20Modified,redirection%20to%20a%20cached%20resource.

"The HTTP **304 Not Modified** client redirection response code indicates that there is no need to retransmit the requested resources. It is an implicit redirection to a cached resource."

So basically, Google cannot load your landing page because they are being redirected to a cache of the landing page instead of the live URL. This is unlikely to be down to someone entering the URL incorrectly in Google Ads (as that would be more likely to spawn a 301, 302 or 307). If you keep serving Google a cached version of your landing page, they can't know what's underneath of that redirect. As such, they can't trust the contents of the web-page

Some unscrupulous marketers, might use a 304 to get Google to evaluate a fake landing page, then send actual users to a completely different landing page (other than the one which Google evaluated). My guess is, this is a vulnerability which Google are unwilling to tolerate on their ads platform

The advice is no longer current. If you want to see what Google used to say about rel=next/prev, you can read that on this archived URL: https://web.archive.org/web/20190217083902/https://support.google.com/webmasters/answer/1663744?hl=en

As you say Google are no longer using rel=prev/next as an indexation signal. Don't take that to mean that, Google are now suddenly blind to paginated content. It probably just means that their base-crawler is now advanced enough, not to require in-code prompting

I still don't think that de-indexing all your paginated content with canonical tags is a good idea. What if, for some reason, the paginated version of a parent URL is more useful to end-users? Should you disallow Google from ranking that content appropriately, by using canonical tags (remember: a page that uses a canonical tag cites itself as non-canonical, making it unlikely that it could be indexed)

Google may not find the parent URL as useful as the paginated variant which they might otherwise rank, so using canonical tags in this way could potentially reduce your number of rankings or ranking URLs. The effect is likely to be very slight, but personally I would not recommend de-indexation of paginated content via canonical tags (unless you are using some really weird architecture that you don't believe Google would recognise as pagination). The parameter based syntax of "?p=" or "&p=" is widely adopted, Google should be smart enough to think around this

If Search Console starts warning you of content duplication, maybe consider canonical deployment. Until such a time, it's not really worth it

And if people don't have Search Console access, they can always try queries like:

https://www.google.com/search?q=site%3Abbc.co.uk

... however, due to the difficulty in exporting all the listed URLs, and due to some anti-scraping measures by Google, this data tends to be inferior to that supplied by Search Console. Always use Google's official tools first

Personally I usually do this as well as robots.txt blocking them to save on crawl allowance, but you should no-index first as if Google is blocked from crawling (robots.txt) then how will they find the no-index tags? So it needs to be staggered

I find that the tag URLs result in quite messy SERPs so I prefer to de-index those and then really focus on adding value to 'actual' category URLs. Because categories have a defined structure they're better for SEO (IMO)

Categories are usually good for SEO if you tune and tweak them up (and if their architecture is linear) but tags are very messy

When you blend different architectures you WILL get contextual tag collisions (e.g: canonical tags don't work the same across both architectures, or Meta robots tags, or hreflangs). What you are suggesting is probably the best thing you can do, I stand behind WordPress quite firmly, even when it's used to augment another CMS (instead of replacing it). That being said, if you believe you are going to be able to predict all the issues which arise in advance - think again!

Do your best on that front (obviously) but you need to manage your client's expectations. There is going to be some fallout. There is going to be analysis needed. There is going to be dev work needed to create a seamless integration. It's good that you're being diligent and trying to predict everything, but with the complexities of the modern web (the same thing can be coded in thousands of different ways) you really need to accept there will be some problems that will need fixing. You'll need to hold some budget back for that stuff, or you'll be up a gum tree

That is a very weird situation and I think that, adding some canonical tags may not meet with your expectations. If Google have strong views about what is / is not a canonical URL, they will usually override canonical tags anyway (which is usually when you get the error you have described). I think we'd really need to see some examples of actual URLs to help you

PDF documents aren't written in HTML so you can't put canonical tags into PDFs. So that won't help or work. In-fact, if you are considering any types of tags of any kind for your PDFs, stop - because PDF files cannot have HTML tags embedded within them

If your PDF files have landing pages, just let those rank and let people download the actual PDF files from there if they chose to do so. In reality, it's best to convert all your PDFs to HTML and then give a download link to the PDF file in case people need it (in this day and age though, PDF is a backwards format. It's not even responsive, for people's pones - it sucks!)

The only canonical tags you could apply, would be on the landing pages (which do support HTML) pointing to the PDF files. Don't do that though, it's silly. Just convert the PDFs to HTML, then leave a download button for the old PDFs in-case anyone absolutely needs them. If the PDF and the HTML page contain similar info, it won't affect you very much.

What will affect you, is putting canonical tags on the landing pages thus making them non-canonical (and stopping the landing pages from ranking properly). You're in a situation where a perfect outcome isn't possible, but that's no reason to pick the worst outcome by 'over-adhering' to Google's guidelines. Sometimes people use Google's guidelines in ways Google didn't anticipate that they would

PDF documents don't usually pass PageRank at all, as far as I know

If you want to optimise the PDF documents themselves, the document title which you save them with is used in place of a <title>tag (which, since PDFs aren't in HTML, they can't use <title>). You can kind of optimise PDF documents by editing their document titles, but it's not super effective and in the end HTML conversions usually perform much better. As stated, for the old fossils who still like / need PDF, you can give them a download link</p> <p>In the case of downloadable PDF files with similar content to their connected landing pages, Google honestly don't care too much at all. Don't go nutty with canonical tags, don't stop your landing pages from ranking by making them non-canonical</p></title>

You need to clarify whether you mean images on their own page, or images on their own URL (two different things)

This is an image on its own page:

https://www.bloodstock.uk.com/events/boa-2019/gallery

Depending upon the nature of the page, you may or may not want to de-index URLs like this. In the example of Bloodstock festival, it would be crazy to de-index their gallery images which many people are explicitly looking for. In other circumstances, you get 'weird' pages which end users are never meant to see. Fragments which have minimal styling and just the image, those can usually be de-indexed. Sometimes an image on a single page is very useful for users (imagine if Pinterest banned all actual pins from the SERPs) but other times they're just back-end fragments which have escaped. Know the difference

This is an image on its own URL:

https://assets-bloodstock.s3.amazonaws.com/uploads/captioned_photo/image/8557/display_desktop_Ross_the_Boss_Bloodstock2109_KatjaOgrin-94.jpg

When you load this up, there's no container. No HTML, no site at all - JUST the image on its own. Don't de-index these, or Google can't see your images - even when they're embedded on a web-page!

Hope that helps

Firstly, PA / DA are shadow metrics. In the old days SEOs used to use TBPR (Toolbar PageRank) to evaluate the worth of pages, which was a publicly available (yet very watered down) variant of Google's official PageRank algorithm metric

When Google took away TBPR, the search industry needed a new metric to evaluate the worth of web pages. As such data suppliers like Moz (PA / DA), Majestic SEO (CF / TF) and Ahrefs (URL Rating / Domain Rating) stepped up to fill that gap. It's important to remember that Google still uses 'actual' PageRank (which SEOs have never seen) in their ranking algorithm, and not Moz's PA / DA metrics. They are meant to give a rough approximation of web-page worth, but Moz doesn't have the same digital infrastructure which Google has. Google can find way more links, way more web-pages

Moz's index of backlinks is probably 1/10 or less than what Google can see. But despite having loads of lucrative data, Google have been very stubborn in terms of making it usable for webmasters. As such we (in SEO) usually have to aggregate metrics from loads of backlink data suppliers (PA, DA, CF, TF, Domain Rating, URL Rating) and boil it down as we see fit. If you just go with one single data supplier you are usually operating your insights along very narrow data samples. It's only by drawing it all together, that you can get real conclusions!

Most ranking factors are relatively equally balanced. There's stuff like EAT, Google penalties (which can annihilate your ranking power, even with strong links), content quality etc. To say that one ranking factor is significantly larger than the others is, IMO, totally inaccurate. SEO is more about effort than it is about isolating magic bullet solutions (which pretty much don't exist in modern SEO!)

If your DA is under-inflated as a result of Moz's smaller backlink index (smaller than Google's) then your competitor's should be suffering from the same thing and it should (roughly speaking) balance out. At the end of the day though, DA is merely an indicator. Google don't use Moz's DA in their ranking algorithms. What really matters is your SEO traffic intake and what you do with it (CRO / UX)

Self-referencing hyperlinks ( <a>tags) are pretty much pointless for SEO and in general</a>

<a>For specific sets of Meta links (like hreflangs or canonical tags) - self-referencing URLs are often a requirement and are part of SEO best practice</a>

It's bad for SEO because Google might start ranking your landing pages instead of the actual product pages. Since it would take a user fewer clicks to convert from the product pages (shorter user journey) you really want to think - do I need these special landing pages? If my product pages aren't ranking, why? How can I take the best parts of my new landing pages and my product pages, and make one super product page that 'just works' for everyone?

Usually when people start producing additional versions of the same page, it's because something about their website or product template isn't wrong. Do you want multiple averagely ranking pages, or fewer pages which rank more highly? The second option there (smaller footprint better ranking positions), is almost always better. To some degree, when you start writing loads of different pages about the same thing it's a form of 'giving up' on the original, instead of working hard to fix it up. It seldom yields good results

There is a caveat here. Sometimes you might create landing pages which exist for other traffic sources - other than SEO. You might create PPC landing pages or FaceBook Ads landing pages, which are highly tailored to your paid ads. That's fine and you should create paid landing pages, but you shouldn't make them accessible to your normal users or allow them to be indexed on Google

Hope that helps

Hreflang means the tags that go between different pages and show Google the way to the same content in other languages. There are also your standard language tags, which perform a very similar function to the self-referencing hreflang. IMO, it should be enough to just use language tags e.g:

^ for French. You can even specify a region and a language like:

I would have thought this would be enough to tell Google what language and region a page is targeted at (you can come up with any number of combinations using the HTML ISO country codes and the HTML ISO language codes)

However, according to SEO best practice this is wrong. Even if you only target one language / country, and you do not require the utility of hreflang tags (pointing Google to other language variants of pages) - you are apparently still supposed to have a self-referencing hreflang tag on your pages (confirming the active language)

Since this is what language tags (which existed long before hreflangs) are supposed to do, it seems really stupid to me. But that's the way it is, for whatever reason

In summary, yes do use self referencing hreflangs AND the appropriate language tags in concert

I would gravitate to marking everything up and letting Google decide what they want to show. Most of the time when you try to 'sculpt' what Google can see in terms of structured data, it usually results in a structured data spam action. Sometimes it can take weeks, months or years for that to happen - but Google always want to be given the full picture.

Google don't take too kindly to being funneled in a certain direction. Schema and rich snippet spam have been a big headache for Google since they started utilising structured data more, some stuff (like author avatars for posts in SERPs) has been entirely taken away in the past (though someone has told me recently, they have been seeing these again for Google mobile layout only).

Google do have some official guidance here:

https://developers.google.com/search/docs/data-types/faqpage

They give a microdata example of implementation: https://search.google.com/test/rich-results?utm_campaign=devsite&utm_medium=microdata&utm_source=faq-page

In their example, nothing is missing or has been left out. Since that's how Google have illustrated their example, that's what I'd aim for myself

If the domain has already been redirected somewhere else and if the redirects were accepted by Google, much of the authority for that domain may now have moved to a new location. In modern times the practice of buying domains and 301 redirecting them for extra link juice, is ineffective unless you are operating under very specific circumstances (and even then it's usually considered black-hat)

Nowadays Google often checks to see if the new content and pages are similar to the old ones. If they're not then quite often the redirect doesn't work for SEO purposes

Only if it's marked up properly and has distinct, unique content. Even if you do it right, the difference is only slight (depending on industry of course). If you're just thinking of clone stamping a US site with exactly the same content to a UK sub-folder and then expecting to get loads of free rankings, think again