Welcome to the Q&A Forum

Actually I think that GSC still reports on granular keywords. The reason I think this is that, some keywords which Google's keyword planner merges (as they are similar) still show as distinct in Search Console. What you are saying is possible, but I don't think there's enough evidence to conclusively state such an opinion at this juncture. If your rank tracker starts to mirror what GSC is seeing, I would be more concerned. GSC is known to regularly experience bugs for its performance-related metrics, e.g: https://searchengineland.com/bug-in-google-search-console-performance-reports-impact-google-discover-reporting-326487

You can also check here: https://support.google.com/webmasters/answer/6211453?hl=en#search_analytics

As it turns out, Robin's insights here (that HTTP redirects to HTTPS via 302 redirects, instead of 301s) turns out to be pretty much hitting the nail on the head

Here's the data for anyone who is interested (and can help OP more):

• https://d.pr/f/TskHsn.xlsx (spreadsheet download)

I spent a lot of time on this data. I compiled all of OP's backlinks from many sources (Ahrefs, Majestic etc) and then re-crawled using Screaming Frog. This shows all of OPs backlinks, their current status and critically how they 'land' on OP's pages / URLs (at the destination end)

Surprise surprise, almost all links point to HTTP (not to HTTPS) and are then 302 redirected instead of 301'd, thus cutting off almost all link equity post HTTPS migration

Whoever fked up here, did an epic job of messing up OP's internal SEO authority flow**. This is probably now, the leading on-site factor in terms of OP's site struggles on Google (so thanks for that Robin Lord!)

I still think there's an off-site element, but this needs fixing ASAP. All HTTP->HTTPS oriented 302 redirects must be converted to 301s with immediate effect

You kind of dropped a bit but not in a way which affects you very much (apparently, according to Ahrefs)

https://d.pr/i/HBzKpj.png (screenshot of estimated SEO keywords and traffic according to Ahrefs)

You did lose a lot of keywords, but many seem to have since recovered and it didn't seem it actually impact your SEO traffic estimates much at all

SEMRush has a neat (relatively) new tool which looks at more accurate traffic estimates across the board (not just limited to SEO):

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

Again it does show a bit of a dent around April 2018. If I was going to use SEMRush data to look at this, I'd use the traffic analytics tool not the 'normal' SEO estimate charts from SEMRush (which IMO aren't very good, hence using the Ahrefs one in place of that)

This is what your site looked like in Feb 2018 before the keyword drops:

https://web.archive.org/web/20180224042824/https://www.vtiger.com/

This is what your site looked like later in June 2018:

https://web.archive.org/web/20180606021616/https://www.vtiger.com/

Completely different!

This is what your site looks like now: https://www.vtiger.com/

Again radically different. Maybe you just have a bad case of 'disruptive behavior' where Google is unwilling to rank you well, because the site keeps radically changing in terms of design and content. Sometimes doing too many changes too fast can really put Google off! 3 different designs inside of 1 year is pretty crazy

After each change, your home-page's Page Title was completely different:

Feb 2018 version: Customer Relationship Management | CRM Software - Vtiger

June 2018 version: Vtiger CRM | Customer Relationship Management Software

Current version: CRM | Customer Relationship Management System - Vtiger CRM

In my opinion everything that was done around June 2018 was a huge mistake that you are suffering for now and recovering from gradually. The June 2018 design was horrible, way worse than the Feb 2018 or current one (both were better). If a designer doesn't do a good job, don't just 'go ahead' with a terrible site design just because you paid for it

In addition to that in June 2018 your page title didn't 'begin' with the term (or a synonym of the term) "CRM". In Feb 2018 and on the current version, you either opened with "CRM" or a synonym of "CRM" which is better for SEO. The June 2018 version of the site was really bad and also less well optimised as well (that seems really obvious to me)

Part of me actually feels that the Feb 2018 version of the site was best for SEO. It did a better job of making your USPs (value propositions) stand out to the user and search engines. It blended nice, app-styled UX with functionality that was more than just 'button links'

The current version isn't bad, it certainly looks nicer visually - but the June 2018 version was a bit of a house of horrors. It makes sense it would have been active within the boundaries of the times you got dented because, it's just a bit shocking to be honest. In the Feb 2018 version of your site, more of the individual product links were listed in the top-line nav. Now they are still there but 'hidden' in drop-downs, that could be affecting things too

If I look at the technical SEO of the Feb 2018 site I can see it was relatively streamlined in terms of resource deployment:

https://d.pr/i/957ZjP.png

... but by June 2018, there were way too many resources for one homepage to be pulling in. Not only did it look plainer and uglier than before (and less helpful, with worse SEO) it was probably also laggier to boot:

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

Ugh! 89 HTTP requests!? Get outta' here

Now things seem a lot better on that front:

https://d.pr/i/7olDcI.png

So I think this is more evidence that the short-lived June 2018 site was pretty sucky and you guys bailed on it at light-speed (rightly so it was terrible!)

The question: did you see ranking drops for "CRM" related keywords in the period surrounding April 2018? Say for example, in April, May, June and July of 2018?

I'd say that you did, according to an (extremely rough) ranking movements export from Ahrefs:

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

Actual data export (formatted) here: https://d.pr/f/pwnrIF.xlsx

So which CRM related URL, was responsible for the most CRM related ranking losses which Ahrefs happened to pick up on?

https://d.pr/i/rCQ8LF.png (table image)

https://d.pr/i/7SJPbt.png (ugly bar chart)

Clearly the URL most responsible for all the drops was this one:

https://www.vtiger.com/open-source-crm/

... so how has this URL changed?

Infuriatingly, the Wayback Machine has barely any records of this URL, so closest I can get to ... just before the end of April 2018, is actually December 2017:

https://web.archive.org/web/20171226021957/https://www.vtiger.com/open-source-crm/

... it looks basically the same as it looks now. No major changes. But wait! On the old version of your homepage,  the footer links to the open source CRM were bigger and more prominent than they are now. Another thing, those footer links used to be marked up with itemprop=url, now they are not (could that be making a difference? All I can say is that the coding is different)

Another question would be, between April and July 2018 - did you lose any CRM related links that were worth a lot?

Actually, apparently you did lose a few.  Check some of these out:

https://d.pr/i/Zg5XER.png (MEGA screenshot, but first page of results only)

https://d.pr/f/NetqVM.png (full export, lost links which may be about 'CRM', April through July 2018 - raw and unformatted export, open the CSV file in Excel!)

Losing a CRM related link from Capterra, online peer review software experts? Yeah that could hit you hard. Most of the Mashable ones are still there, they are just redirected - but the Capterra one:

https://blog.capterra.com/free-and-open-source-crm/

... that could sting. You used to have a link with anchor text like this:

"for a price starting at about $700" - but now it's gone!

You might be thinking, aha Effect - you silly sausage! Clearly it was a comment link that got pushed down or removed by admins / mods, not a 'real' link Google would have been counted. But no I say, and I have proof to back up that denial:

https://web.archive.org/web/20170930101939/http://blog.capterra.com/free-and-open-source-crm/

That is the same post in April 2018, if you Ctrl+F for "for a price starting at about $700" - you will FIND the in-content link, which actually did matter, which Capterra have removed from their content

I am sure that in the link data you will find other such examples of lost quality links. Some will be duds and false-positives (like the Mashable ones) but some will be legit removals

By the way, although the Mashable links to you are still live, Mashable have 302 redirected the old URLs for the blog posts instead of 301 redirecting them. This means those posts, if they were valued and accrued a lot of backlinks - have been cut off from their own backlinks (as 302s pass no SEO juice). As such links contained inside of them are largely nullified (d'oh! Thanks Mashable)

What this illustrates is that, your site changed too much, the way links are formed changed, the design went  through a really bad patch and also you've lost some high quality backlinks. An SEO legacy doesn't last forever, links get removed over time

In the end, these convergence of issues are almost assuredly leading your site through a tough spot. That's what I'd imagine, from a very very top-line look into this issue

Let's have a look here:

1. 301-redirect to the first page of the category - this would alleviate content duplication issues and it would consolidate SEO authority in a powerful way. The redirected pages would become completely inaccessible for users and search engines (the remaining pages would rank better, the footprint of potential ranking URLs would decrease - there may also be UX issues)
2. create canonical tag with URL of first page of the category - this would alleviate content duplication issues but would only consolidate SEO authority very weakly. If different pages gained different backlinks, you may end up with 1-2 averagely ranking URLs instead of one URL which ranked better. That being said, UX issues would be avoided as the other pages would still be navigable. Again though, this would decrease the number of 'rankable' pages (when a page uses a canoncial tag that points elsewhere, it tells Google not to index the active URL)
3. return 404/410 - If you return 404, Google will probably fill your search-console with 404 errors. Internally linking to 404 URLs is a no-no, it will impact site-health metrics. 410 will let Google know that the pages are 'gone for good' yet your internal link structure may continue to contradict that statement by linking to 410s. I wouldn't recommend either of these really, especially if you wouldn't update the site's link architecture
4. your suggestions? - because you're talking about paginated content (e.g: https://poweredtemplate.com/powerpoint/templates/next/25/1/index.html vs https://poweredtemplate.com/powerpoint/templates/next/25/2/index.html) - I would recommend using rel=prev/next instead of using any of the above. You could potentially use prev/next in combination with canonical tags, but it might not be necessarry. Tell Google which URLs are 'pagination' (page-based) addresses. Let Google determine how it wishes to handle them. If the problem spirals out of control and one category ends up containing literally thousands of variants based on pagination; use a wildcard-based robots.txt rule to support your pagination changes. You'd basically want to block pagination URLs, but ONLY when they started reaching ridiculous numbers (like page 1,507 or something)

Basically, if you identify a data anomaly you shouldn't trust any of the stats (as a group). Generally GSC (Google Search Console) can be trusted, but if you have identified an issue you should question the whole dataset

No - translations don't count as duplicate content, but you should ensure that your site has a proper multiregional build-out (e.g: site.com/press-releases/artice (EN) vs site.com/fr/press-releases/artice (FR)

You should properly 'build out' the site in an international way, don't use low quality auto-translate plugins or live-translation features. You will need all your hreflang tags set up properly, so Google knows they are alternate language page variants (see: https://yoast.com/hreflang-ultimate-guide/)

See this from 2011: https://www.youtube.com/watch?time_continue=2&v=UDg2AGRGjLQ&feature=emb_logo where Matt talks about whether translations are duplicate content. AFAIK Google's stance hasn't changed loads. The translation must add value and you must use human-translated content (written by someone competent enough, that it doesn't read as if it was written by a machine)

More recently John Mu (from Google) has said that auto-translated content won't gain penalties but the rankings will suck so basically still get humans to write stuff: https://www.seroundtable.com/google-auto-translating-content-penalty-28413.html

Interestingly Google recently said that they think there may come a time in the future where auto / machine-translated content is acceptable: https://www.seroundtable.com/machine-written-content-google-guidelines-28338.html

... but as of now, it's still considered poor and against guidelines!

This is very true for multi-section articles (which span multiple addresses), and less true of articles which have only one address yet break down into multiple addresses in terms of UGC comment-based pagination

1.) Understood loud and clear! So that makes a lot of sense, that actually makes redirect options more viable which is good

4.) Got it. If you're already doing that and still having problems, either consolidate (using the 301s idea) so that it won't be a big problem, OR leave things as they are but use robots.txt to 'sculpt' the depth which Google can crawl paginated URLs to

At this point I'm thinking 1 is sounding better all the time

If you want I can run your pages through a non-rendered (source only) crawler and see what gets picked up (would need the domain and the types of page you want me to look at, though). If you want to do it yourself I recommend picking up the free version of Screaming Frog SEO Spider which you can download here: https://www.screamingfrog.co.uk/seo-spider/ - even the free version, I think, let's you crawl 500 URLs in one project (or something like that). It would easily be enough to tell what's what

Yeah it will take a while but it's necessarily slow. Moz's crawler has to share bandwidth with your real, human users. If they crawl your site too fast they could lag your site or accidentally DDoS you or something

Since it's a paid for service, I'm guessing that Moz err on the side of caution with Rogerbot and don't crawl insanely fast. I know that Rogerbot supports adding a crawl delay to make the crawling even slower:

https://moz.com/help/moz-procedures/crawlers/rogerbot

But I don't think there are any 'go faster' commands. Whilst I really like Moz's crawler I tend to find that the SEMRush one is faster for on-site stuff, though it does have URL crawling caps

To be honest, just get Screaming Frog and learn how to use that. Now that it has a database storage mode (instead of maniacally trying to store all the crawl data in the RAM) - it probably could crawl all 50K URLs. It could probably do it faster than Rogerbot, though you wouldn't wanna go nutty as you could easily DDoS yourself :')

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

Read what EGOL wrote. It depends upon the nature of your blog pagination

There are a few reasons you could have pagination within the blog area of your site

1. Your articles have next buttons and different parts of the article are split across multiple URLs. The content across the paginated elements is distinct

2. Your post feeds are paginated, purely so people can browse to pages of 'older posts' and see what your wrote way back into your archives

3. Your blog posts exist on a single URL, but when users comment on your posts, your individual posts gain paginated iterations so that users to browse multiple pages of UGC comments (as they apply to an individual post)

In the case of 2 or 3 it's not necessarry to have unique H1s or Page Titles on such paginated addresses, except under exceptional circumstances. In the case of #1 you should make the effort!

This is almost assuredly a link-based architectural error. It will be something similar to this:

• You load a page on EN
• You click the EN flag or language icon
• Instead of just reloading the page you are already on (since you're already on EN) the link is coded wrong and adds another /EN/ layer to the URL
• Once the new URL loads, the problem can be repeated
• This creates infinity URLs on your site
• Bad for Google, and Moz's crawler

Bet you it's something like that. If you give me the exact URL I might even be able to find the flaw and detail it for you via email or something

This post from Jan 2020 seems to assume that you can still use &pws=0

https://www.business2community.com/seo/keyword-ranking-report-google-search-differ-heres-why-02275972

... but I don't know how reliable it is!

Big question here is, are any other tools giving 5XX errors on those PDF URLs (ending in .pdf) or just Moz on its own? Moz is known to have issues crawling URLs which contain certain characters, which other crawlers may not have a problem with - so you need a second opinion here

Install this on Chrome: https://chrome.google.com/webstore/detail/redirect-path/aomidfkchockcldhbkggjokdkkebmdll?hl=en (mainly for tracking redirects, but also tells you status info in a handy way from a pop-out button)

Visit one of the URLs directly which Moz is saying gives a 5XX. Does it on Chrome? Note: sometimes a page will look like it has rendered properly, but for some reason the server will still send an invisible 5XX response - this Chrome plugin would pick that up!)

Also check the URL with this second plugin: https://chrome.google.com/webstore/detail/seo-indexability-check/olojclckfadnlhnlmlekdihebmjpjnoa?hl=en-GB

If both those plugins agree the page loads fine on a 200, then Moz has an error. If they both agree that the page is a 5XX even though it looks legit, then you have a server response error

If you get mixed results we have a mystery to look deeper into...

Unfortunately yes. We have a number of clients who went 'geo-mad' and in almost all situations, it has caused problems for them. Sometimes it has created colossal site footprints which Google doesn't care to index (unless you're a household name, don't expect Google to care about your hundreds of thousands of URLs). Sometimes that has also caused server-load issues for them too, irrespective of Google

Other issues include Google ignoring their canonical tags and setting one language URL as the 'canonical' result (and thus de-indexing the other language URLs). This can happen due to link signals and similar content, stuff like that

Many clients in such a position have **seen their pages devalued as a result of them going against Google's content guidelines **(and simplicity guidelines). If you're not super important, Google don't want to waste 4x, 6x or 20x crawl budget in your site just because you decide to serve in more combinations of language and geo-location. Even with perfect Hreflang deployments, a lot can go wrong if you go nutty so cherry-pick your language/geo combinations and don't be greedy with it

If your brand is powerful online and you have loads of SEO authority / ranking power, then you can deploy hreflangs extensively and usually you can make real gains. Not everyone is in that position, most aren't

Having unique content (not powered by some crappy auto-translate plugin) per deployment is strongly, strongly recommended. By the way if you have less ranking power than most sites which have 'successful' broad-reaching hreflang deployments, you need to adhere to Google's guidelines more strictly than those sites do. You need to make up for you lack of trust and authority, by doing things by the book

Too many people look at big international sites and say: "well Google lets them use relatively thin content so I should be alright too". Nope, you are likely standing upon a platform of radically different stature to those guys, so don't over-reach too quickly or you'll stumble and fall

Also if you are planning to use canonical tags to 'canonical' from one language to another, don't do that. If a page points to another, separate URL with its canonical tag - then it tells Google that it (the active page) is the non-canonical version and usually de-indexes itself

Be very careful how you proceed. If you increase your footprint too far, all the great authority you have built up may bleed out over a sprawling site and you could end up with nothing

Not here, but many of our clients are well established and highly authoritative. I would anticipate that for smaller sites trying to build up (and survive online) the impact would be higher

Site speed impact is where I see this becoming a real problem, unless the setup is done correctly

To be honest I found Google Data Studio pretty horrible and was able to work much more easily with Microsoft's Power BI, though for corporations it's not free and the price-tag is steep

One feature that Power BI had was that, in addition to connecting to set platforms like Google Analytics, it could also connect to custom objects like an SQL database

If Google have been smart and kept up, I'd expect this to be a feature by now in Data Studio...

https://support.google.com/datastudio/answer/7020436?hl=en

Looks like I was right!

This could make your life really easy as long as your rank tracking supplier provides an API for their tool. You can make requests to the API and build your own SQL database of that same data for your own records. The server holding the SQL database would have to regularly run API-based tasks to pull the data from your ranking supplier, into itself

Once that was done, you could then just connect to your SQL database via GDS

1. You'd need a developer to build the database and the tasks which updated it (API fetches)
2. If your ranking supplier changed their API significantly you'd have to pay to get it updated
3. You'd need to pay to host your database online somewhere

Other than that... Seems like a good solution. Sorry it's not super cheap and simple - though!

Even if your ranking supplier provides back-end exports only and no API, you can still do what you want. You'd just have to create a script that uses a headless browser to export the data and then push the CSV exports to your database. Again you'd assuredly need a developer's help! Using something like Python's Selenium or Windmill modules might be feasible

Hope that helps