Welcome to the Q&A Forum

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

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

I think it would be something like:

<code>RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

RewriteCond %{HTTP_HOST} !^www\. [NC]

RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This would go in your .htaccess file, you should be sure to edit the file via FTP so that if you break it, you can restore the old version and fix the site in seconds (keep a backup of the old .htaccess file)

If you are on a windows-based server you'd need the equivalent rule for your web.config file as IIS doesn't use .htaccess

For most sites, you have a .htaccess file and it sits in the root of your FTP (the same place that your primary index.php file lives, where robots.txt and sitemap.xml also usually reside)</code>

It's true that the post may slant Google's view of what your site is about. That being said, removing the post won't make your other pages rank better and it may drop your PageRank. If you want to see those kinds of traffic levels, whilst having better qualified traffic (from more relevant keywords) then creating new successful content is the answer. Deleting stuff seldom leads to gains in Google's SERPs, it's seen as the easy way out and is not rewarded (9 times out of 10)

It's not that the post will block you from ranking where you want to rank, it's simply that none of your keyword 'aligned' content (for the terms which you do want to rank for) was proven to be 'as good' as the post which hogs all the rankings. I don't really see why a site couldn't rank confidently for yoga and visas. Look at the UK, look at sites like Visit London. That site ranks for loads of terms which you might assume weren't directly related. SEO is usually about confidently stepping forwards with effort and insights, rather than culling things and sweeping stuff under the carpet

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

Huh, that's a very clever idea. I don't think it will work though! What you are saying is that, only a few videos on a channel sit on that channel's main feed, which is where the channel most prominently links to them. Once videos get older, they kind of 'fall off' the channel's front-page feed, and thus get less link-juice. Is that right?

The thing is, your main (first) channel has inbound links pointing to it -right? And some of those videos also have backlinks too, if they are very popular. That's what makes them rank well (that and YouTube internal metrics like comments and shares and stuff).

If you move popular videos to a new channel, their URLs will change. That means that any backlinks pointed at your video (or the channel which links to the video) will be 'cut off' from the videos new placement. As such I'd expect this move, to see even worse rankings (not better ones)

It's a clever idea, I can see what you are saying - but no I wouldn't recommend it and I don't think it would work out as you had intended

Keep thinking in that way, it's smart. But on this particular occasion, no don't do it

Not a problem! I always like these kinds of Qs and responses as they cover a bit of the history of SEO

In SEO, most of the ranking factors are weighted relatively equally. It's less about cherry picking the easy-wins, and more about putting in volumes and volumes of effort (overall)

Moz does have some notes on top ranking factors: https://moz.com/learn/seo/on-page-factors - but they're not numbered, or in a particular order (as far as I know)

You can search Google for "top Google ranking factors" but you'll just get loads of different answers, ordered differently.

This list isn't awful: https://optinmonster.com/seo-ranking-factors/ - but I'm sure  many people here will take issue with it, as they would with any list that was posted

I actually think a number of Moz's Whiteboard Friday videos are pretty spot-on:

• https://moz.com/blog/how-to-create-10x-content-whiteboard-friday
• https://moz.com/blog/does-seo-boil-down-to-site-crawlability-and-content-quality-whiteboard-friday
• https://moz.com/blog/why-good-unique-content-needs-to-die-whiteboard-friday

^ These are my three go-to videos in terms of beginning to learn about (or teach) SEO

With web hosting companies it depends upon, whether you have literally just bought the hosting space alone (to save as much money as possible) or whether you have bought a bundle that contains other services. Even an automated backup solution is part of their product so usually it does cost extra (depending upon who you go with, of course!)

If a deal seems too good to be true, it usually is

I'm not sure about any of the auto-backup services you can plug onto a WordPress site, but I'd be extremely wary of any automated malware removal to be honest. On my desktop PC I often script little tools to help me out or make my workflow more efficient. Because they don't fit the 'mold' of what regular software is 'expected' to do, they often get flagged by my own AV (falsely) as malware

A lot of malware shields these days look for 'unusual' items instead of 'harmful' items. This makes me wonder, if you innovated and designed  / developed something really cool on your site - would the malware shield strip it out? Then if your site gets hit and you have to restore it, you might lose out on some of your site's unique architecture and functionality just because it didn't fit the 'norm'

On a desktop environment I know that there are lots of spam-tools produced to solve problems that don't exist, which can often make a machine run worse than before. A good example of this are all the sh*tty driver update and registry 'mending' softwares which just leave your system a steaming pile of garbage. Anti-malware can be good but it does have the propensity to go OTT and for the devs to get extremely lazy, building tools that seek out unusual applications instead of damaging ones (prejudice in coding)

I would assume that for web-based software, the same problems would creep in. So personally I'd try to be smart in terms of what I installed and how I protected the site, but rather than having some half-ass malware-strip on backup - I'd probably just do the backups without any 3rd party intervention. When you back up your site, you know it's working. Why would you want to automatically alter the backup as it's saved, in a way which might break it upon restoring the site's image? Seems like an unnecessary risk sold as a product to me

I agree that with the information you have stated, that could well be the problem. One thing you should know, Google seldom 'rewards' good behavior 'after' you get caught.

What has happened isn't a penalty, it's known as an 'algorithmic devaluation'. Basically your client's site was ranking higher than it should have for a term, and it was getting more search traffic than it should have been (it's important to be clear on that point)

The action which Google applied was likely to the link / blog network(s) and not to your client's site. So why are you suffering then?

Imagine your client's site like a big water tank with pipes connecting to it. As the water flows in to the tank from external sources, it fills up right? That's like links piping SEO authority onto a domain

When Google detects that some websites should no longer be able to 'give' SEO authority to other websites, it's like the tap at the end of one of the pipes is turned off. What you have to ask yourself is, if Google was saying that authority was illegitimate, will disavowing that website - cause Google to artificially restore the SEO equity which it was previously sending to you? Obviously not, that doesn't happen. If Google were to allow that site to send you SEO authority again (knowing that the link seller was helping you game the system) they'd be willfully damaging their own search results (which they won't do)

So if nothing good can come of disavow work, why the heck does anyone do it!?

Simple - to stop an algorithmic devaluation from 'mutating' into a full blown penalty. It's like pleading guilty in court on the charges of fraud. Just because you handed yourself in, doesn't mean you get to keep what you stole. But you might get out of going to jail, you might get less jail time

The real solution is to replace the links which are being 'de-valued' with better links that will stand the test of time (which could be expensive)

Disavow work is necessarry, but it typically yields the same results or dips you very slightly lower. It does however, stop you losing everything! So that's good.

In terms of recovery though... Replace fool's gold, with real gold

Hope that helps

Meta keywords are not used by Google any more. Not for a decade - by the way!

If you fill out your Meta keywords tag for all your pages, anyone with an SEO crawler (like Screaming Frog) can effectively 'steal' all your keyword research. I'd say just don't fill out Meta keywords to be honest. At best it's a waste of time, at worst it's free research for all your competitors

So firstly, remember that Google's rankings are a competitive environment. It might be that others are rising as the query-space has been identified as lucrative by a number of competitors, rather than that you are 'dropping'

Another factor to consider is algorithmic devaluation. If you haven't had a message from Google within Search Console saying that you have had a penalty of some kind, then Google aren't adjusting your rankings to be lower than they were before.

When sites which previously gave you SEO authority are deemed as 'manipulative' by Google, the pipe from their site to your site (which was previously sending across ranking power) is switched off, so you drop. No one has edited your rankings to be lower, it's just that previously 'suspect' links have been switched off by Google. From Google's POV those links should never have contributed to your rankings, so it's not an attack on you - it's Google balancing the table to 'how things should always have been'

I recently wrote an in-depth post on this phenomenon, you can find it here as my primary answer to the asked question. I recommend you have a read of that one!

I can confirm that at our agency, from late Summer last year to the end of the year (Autumn to Winter period) we did notice an increase in terms of negative SEO attacks. 2-3 of our client's sites were hit and on one of our client's websites, the attack actually worked and drained some of their ranking positions a little. We recovered from it pretty fast via accurate disavow work. The main offending network was this crappy one which as you can see is just a series of spam domains linked together with billions of pages listed, in Google's least-favourite manipulative 'link-list' format

For reference we purged a load of globe-related domains:

• https://d.pr/f/PLkscH.txt (list of globe-related domains we disavowed)

I'm giving you the above as our timelines somewhat converge for very similar issues, actually if you'd be open to it I'd like to compare lists of disavowed spam domains to see if it was part of the same attack

This list isn't exhaustive, we actually did a much more thorough job of the work than just that. We fetched tens or hundreds of thousands of backlinks from all relevant tools (SEMRush, Ahrefs, Moz Link Explorer, Majestic SEO, Google Search Console) and aggregated all the data. We then used Google Analytics (site-visits / sessions metrics) and URL Profiler (fetching metrics like Citation Flow, Trust Flow, Page Authority, Domain Authority, Ahrefs Rating - all from different data sources) and boiled each link down to a single 'SEO Authority' metric

Once we had that we began deciding which links were 'fake' ore 'negative SEO' links and we disavowed them in a very, very targeted way

The problem is that, when you get penalties or algorithmic devaluations, Google won't explicitly tell you which links are the problem. If you get too aggressive and do the disavow work in a non-data-led, non-targeted way, you can end up disavowing some links which were giving you some SEO ranking power. That makes you dip down further

Even with out solid tools and methodology, we _still _usually experience slight dips from disavow work. But after it's done, limiters on performance are removed and then you can begin to see it trend up again. Especially if you replace some of the bad links with good ones (or compensate for having less authority by introducing better content), you very quickly start to see the site recovering

IMO it sounds like you have had:

• Spammy inbound links and / or negative SEO
• Which led to algorithmic devaluations, not a penalty
• Which was then back-plated with low quality disavow work
• Which then hit you harder than was necessarry
• Which then nullified your content efforts

I'm not a gambling man, but if I had to roll some dice - that's what I'd say

This is the kind of lengths we were going to, in order to get an accurate disavow which killed negative links whilst preserving decent ones:

• https://d.pr/i/o4GM8p.png (screenshot of Excel)

This particular sheet has over 5,000 rows of data, but before we began our cull it had many more (into the tens or hundreds of thousands of rows of data, from memory)

A lot of the colouration is conditional formatting, designed to make stuff stand out. There were also rules saying stuff like, actually if this link is already a no-follow it therefore can't be a risk so don't disavow (basic logic)

If this doesn't look like the lengths to which your agency or freelance partner went to (with very sensitive disavow work) then the work wasn't done right

Sorry that I haven't provided a clear-cut, out of the box answer to your query. Hopefully the knowledge and resources which I have shared here, will be some use to you on your **quest for restored **rankings

Actually quite often there are links to pages of search results. Sometimes webmasters link to them when there's no decent, official page available for a series of products which they wish to promote internally (so they just write a query that captures what they want and link to that instead, from CTA buttons and promotional pop-outs and stuff)

Even when that's not the case, users often share search results with each other on forums and stuff like that. Quite often, even when you think there are 'no links' (internally or externally) to a search results page, you can end up being wrong

Sometimes you also have stuff like related search results hidden in the coding of a web-page, which don't 'activate' until a user begins typing (instant search facilities and the like). If coded badly, sometimes even when the user has entered nothing, a cloaked default list of related searches will appear in the source code or modified source code (after scripts have run) and occasionally Google can get caught up there too

Another problem that can occur is certain search results pages accidentally ending up in the XML sitemap, but that's another kettle of fish entirely

Sometimes you can have lateral indexation tags (canonical tags, hreflangs) going rogue too. Sometimes if a page exists in one language but not another, the site is programmed to 'do something clever' to find relevant content. In some cases these tags can be re-pointed to search result URLs to 'mask' the error of non-uniform multilingual deployment. Custom 404 pages can sometimes try and 'be helpful' by attempting to find similar content for end users and in some cases, end up linking to search results (which means if Google follows a 404, then ends up at the custom 404 URL - Googlebot can sometimes enter the /search area of a website)

You'd be surprised at the number of search results URLs which are linked to on the web, internally or externally

Remember: robots.txt doesn't control indexation, it only controls crawl accessibility. If Google believes a URL is popular (link signals) then they may ignore the no-crawl directive and index the URL anyway. Robots.txt isn't really the type of defense which you can '100% rely upon'

This is a great answer.

From the sounds of it OP has:

1. A scraper site gone wrong, creating malformed links to your site
2. Some kind of shady negative SEO attack trying to create garbage URLs on your site
3. A data pollution attack trying to mess up your analytics
4. A hack-attack
5. Any mixture of the above

If a site has been hacked, sometimes it can take some proper dev work to pull it out at the roots. A hacked site is a liability to Google and Google don't like to rank hacked sites / content

I would suggest checking whether the site has been hacked with some urgency and back everything Gaston has said

The next trick will be trying to ascertain if these results are a categorised search entity (e.g: news results, shopping results, image results, movie listings carousel) or whether Google has just noticed that certain search entities are thematically related and is front-ending them

When knowledge graph pulls through a slot of information or you get quite a generic looking insertion of universal search elements, often it's just Google crawling the web and putting 2 and 2 together by itself (without user / webmaster input). For some things though (shopping results, news results etc) there are specific methodologies for getting 'entered' into the results (for example unless you pay Google, you aren't getting in the shopping results period)

Next things I advise you to do:

1. see if you can work out whether it's a pre-determined listing type (or if it's something new)

2. take the top 5 sites linked to by this new carousel. Put them all into this tool: https://search.google.com/structured-data/testing-tool - see if they share any common schema features. If they do, it might be something you can add to your own site

It can vary. Sometimes it just strips off the rich snippets, other times (if the infringement is quite sever, in Google's eyes) - all pages which have a rich snippet result, can be entirely dropped from the rankings. That's the most severe version of the penalty which I have personally come across

There's a kind of internal disagreement at Google (IMO) in terms of how to implement structured data. Some Googlers vouch for the JSON-LD approach because it's faster and technically more efficient. Whilst this is undoubtedly true, it doesn't 'force' webmasters, devs and practical SEOs to mark up stuff which is 'actually on the page'. This opens the doorway to accidental infringements of this penalty

This is why I always push for the microdata implementation. You can still technically get penalised but it's much harder. Some from Google's anti-spam team, have historically pushed webmasters to adopt microdata over JSON-LD

My preference is, just use microdata. Maybe it is slightly slower and slower to implement, but that forces people to 'think about what they're doing' which is 10x more valuable IMO

I'd say leave them indexed unless you notice related performance issues

These are good answers, however if your site has a blog and other content which frequently changes (e.g: you are an eCommerce site and you have hundreds of products that go up and down every day) - there is no point re-submitting your product sitemap(s) every 15mins when one product changes. Let Google just digest that stuff naturally

For your posts sitemap (which should be separate and linked in your sitemap index), if you only post once or twice a week - but the posts are high quality and in-depth, then yes - re-submit your post sitemap as needed

I honestly think if you're going to pick one of the two (though neither is quite right), event makes much more sense than product does. It's not like someone is physically buying the actual cruise ship, instead they're paying to spend 'time' at a 'venue', the venue just happens to be mobile instead of stationary

Someone else went on a similar journey of discovery in 2017, here: https://www.webmasterworld.com/html/4844938.htm

... kind of interesting. It highlighted that Ticket schema might be one possible option: https://schema.org/Ticket. There are actually lots of references to "ticket" within Google's event schema documentation: https://developers.google.com/search/docs/data-types/event (ctrl+F for "ticket")

Apparently lots of cruise operators do use event schema, never heard of any of them using product schema

I agree with Robin, I don't think there's a solid way to do what you want - or one that is infinitely superior to GA (which also doesn't damage conversion rates). IP addresses by and large, are sometimes inaccurate at the city / town level but they are 'usually' accurate at the national level. The only other option you have in GA is looking at browser language settings and that's incredibly misleading due to most PCs being shipped on US English by default