Welcome to the Q&A Forum

Have you run Google's fetch and Render tool to test and see what Google actually sees through the render process? That's a quick way to often determine what's happening.

Regarding 404/301 issues. The numbers I gave were for a small partial crawl of a hundred URLs. So a full Screaming Frog crawl would help to determine if it's worse.  Even if its not, think of the concept where a site might have a dozen core problems, and twenty problems that by themselves might seem insignificant. At a certain point, something becomes the straw that breaks the camels back.

Regarding content - how many courses offered are actually up against competitors that have entire sections devoted to the topic just a single course page has on that site? How many have entire sites devoted to that?  Understanding content depth requires understanding the scale of real and perceived competition. And if it's a course page, it may not be a "main" landing page, yet it's important in its own right.

Regarding panda timing - the site took the big hit three years ago.  Waiting for, and hoping that the next update is the one that will magically reflect whatever you've done to that point isn't, in my experience, a wise perspective.

While it's true that once Google has locked a data set to then be applied to a specific algorithmic update, not taking action at a high enough level, and with enough consistency is gambling.  Since true best practices marketing as a whole needs to be ongoing, efforts to strengthen on-site signals and signal relationships also needs to be ongoing. Because even if Panda weren't a factor, the competitive landscape is ever marching forward.

I'm going to go out on a limb here and say you have problems that you either aren't aware of, or don't realize the impact of.

1. The bottom of the main content area of your home page and your footer are spam central for the keyword stuffing.  The range of phrases you use that are obviously intended to boost rankings for specific phrase variations is off the charts severe.

2. The scale of topical dilution on the site is also a concern.  Individual product descriptions are almost non-existent.  Consider the impact of the left side "link to all the things" content, right side "related" and "recently viewed" widgets, and the lower page "Also viewed" content, (and again, that scary keyword stuffed footer), and the "uniqueness" of that page is seriously questionable and you're forcing Google to struggle to trust uniqueness.

3. The shear number of "categories", plus brand funnels, plus costume "Ideas" funnels, just reinforces to me that it looks like the site is trying to rank for "all the variations" (which that footer screams is actually what you are trying to do).

4. Your "Search" subdomain is typical of now proven to be failed "enhanced automated content" that was supposedly a way to get more search visibility a few years back, and yet where all it does is create more duplicate content mess, since it just links back to the main site and is not actual, best practices SEO.

Those are only the first few things I found in a quick check. There's almost certainly a full range of issues you will likely need to get cleaned up if you really hope to ever see a strong, sustainable organic presence.

Damon,

To start, let's be clear - Panda isn't a "penalty" - it's an algorithmic adjustment based on quality, uniqueness, relevance and trust signals.

Having audited many sites hit by the range of Panda updates, I have a pretty good understanding of what it usually takes. so having said that, I took a quick look at the site.  While Andy may be correct in that you may only need to wait and hope the next or some future Panda update acknowledges the changes you've made to this point, that very well may not be enough.

1st obvious problem - your site's response times are toxic.  - a crawl using Screaming Frog shows many of the pages have a response time of between 3 and 7 seconds. That's a major red flag - response times are the amount of time it takes to get to each URL.  If it takes more than 2 seconds, that's typically an indicator that crawl efficiency is very weak.  Crawl efficiency is a cornerstone of Panda because it reflects what is almost certainly a larger overall page processing time problem.  Since Google sets a standard "ideal" page processing time of between one and three seconds, if it takes more than that just to ping the URL, the total processing time is likely going to be significantly worse.

While it's not required to always get a one to three second total process time, if too many pages are too slow across enough connection types for your visitors, that will definitely harm your site from a quality perspective.

And if too many pages have severely slow response times, Google will often abandon site crawl, which is another problem.

Next, I checked Google Page Speed Insights.  Your home page scored a dismal 68 out of a possible 100 points for desktop users (85 is generally considered a good passing grade).  That reinforces my concern about crawl inefficiency and poor page processing. It was even worse for mobile - scoring only 53 out of 100 points.  In my second test, I got 63/100 for desktop and 49 for mobile.  The different results for the two tests is due to the fact that speeds are worse at different times than others.

Just one of the issues GPSI lists is server response time (which confirms the very poor response times I saw in Screaming Frog).

Next, a partial crawl using Screaming Frog crawled 20 URLs that resulted in 404 (not found) status, which means you have internal links on your site pointing to dead ends - another quality hit. And SF found 25 internal URLs that redirect via 301 - further reinforcing crawl inefficiency.  Since this was a partial crawl, those problems could be even bigger scaled across the site.

Then I poked around the site itself.  http://www.workingvoices.com/courses/presentation-skills-training/keynote-speaker/  is indexed in google, as it's one of your courses.  That page is possibly problematic due to the fact that there is hardly any content on that page overall.  So while you may think you've dealt with thin content already, I don't think you fully grasp the need for strong, robust depth of content specific to each topic you consider important.

That's nowhere near a full audit, however the above are all examples of issues that absolutely relate to working toward a highly trusted site from Google's algorithmic perspective.

Gianluca

Thanks for jumping in on this one.  So if I'm reading your answer correctly, the bottom line here that there really should be one site per country, regardless of language spoken, correct?

Yeah inheriting previous work can be a challenge.

Since you are already planning on rolling out content in different languages, you will have not only the opportunity to set the hreflang tags for each, but also it will be important to ensure all of the content within each section is actually in that section's primary language for consistency. That too will help address the confusion Google has.

Yeah sequence of load is also important when its time to go granular to find the true opportunities. Because the up-front evaluation time that can identify issues, can often result in faster-easier-more template-driven ways to speed up everything on a larger scale with less effort needed.

That doesn't mean its okay to ignore other bottlenecks.  Just that the more clarity of understanding, the more likely real, sustainable success can be achieved.

Kingalan1

I'm not a programmer by trade - the way I begin even considering these things is by running tests on various tool platforms.

For example, put a page you think is slow into URIValet.com - test as Googlebot.  The resulting report has a block of information in it regarding total size of files processed.  It breaks that data down to file types.  Look at the CSS/JS lines - if they are more than 50k to 100k total for either CSS or JSS, there is almost certainly inefficiency in there, and likely unnecessary bloat.

Go to WebPageTest.org and do the same - put in the URL you want to check - choose a server location and DSL (which gives a fair mid-range speed evaluation), and Chrome as the browser emulator.  The resulting report gives you a lot of information, however the one page in that report that may be most helpful in this situation is the "Details" report - if you go there, and scroll down, you'll get to the section that lists, line by line, every single file, script, image and asset processed for that page, and all of the data on speed of processing each step of the way (such as First Byte Time, DNS lookup, SSL lookup, and more).  Those can reveal several individual bottleneck points.

Domaintools domain report shows no more info that could be helpful.  Leaving me at a complete loss as to what else to check.

More info.

Because Nitin was able to run a ping and traceroute without problem, I went to DomainTools.com - the worlds leading resource for forensic digital investigative research. I use it whenever I am doing investigations for expert witness work I do.

When I ran the domain there, it had a screen-capture of the home page from June. So I submitted a refresh, and it came back as not being able to provide a screen-shot of the home page.

While not a smoking gun issue, it further clouds my trust in regard to whether the domain is actually functioning properly in the hosting environment as I originally thought it might not be.

I will run a deeper test to see if I can get more information, however I wanted to post this update because I believe it relevant.

Nitin

Thanks for doing that - Now I'm stumped - I've never had Pingdom fail before with both ping and traceroute.  And I now wonder if it's a non-issue, or part of the confused mess that Ankit referenced somehow.

having the clearer understanding about the concept of having multiple "titles" on a single page (an H1 headline is the in-content "title" for that page), David is correct - while HTML 5 allows multiple H1 tags on a single page, this is bad because the H1 communicates "this is the primary topical focus of this unique page".

Because of that, if you have headlines within the content area for content elsewhere on the site, and link to that other content, then those are absolutely best served with H2 headline tags, or if not , then at the very least, "strong" tags if the topic of each target page is significantly different than the primary topic of the page they're all listed on.

1. Taking shortcuts that are not sound sustainable based methods to gain value somewhere else is almost certainly going to become a problem when you least expect it at some future date and this is a great example.  Moving CSS and or JS to below the proper location is a recipe for complete page display failure on any number of devices that may or may not current exist.

Have you tested your pages with Google's Fetch and Render to ensure they properly load, or where they may get a "partial" result? If they get a "partial" result, that's a red flag warning that you ignore at your own peril.

2. You haven't provided numbers - is the page speed improvement a case of going from 20 seconds to down to 5 seconds? Or is it going from 8 seconds to 6 seconds? Or what?  This matters when evaluating what to care about and expend resources on.

3. If just moving those to their proper place in the page header section is causing speeds to slow down dramatically, you have bigger problems. First one that comes to mind is "why do those scripts / CSS files cause so much speed slowdown? Its likely they're bloated and need to be reduced in size, or they're housed on a pathetic cloud server that is itself doing you more harm than good.

Have you set the different hreflang tags appropriately across your content?

You said "US" and "European" - so does that mean you have just one set of content for all of Europe? If so, that can be more difficult to deal with, however if you set all of the US pages with an hreflang of "en-us" and the European pages with an hreflang of en-gb, you can at least help Google understand "this set is for the U.S. and this set is not".

What I always recommend if you're not targeting individual countries with your content (the "Europe" reference you made says you are not for that content), is to at the very least, split out content to two different domains.  Have a .com domain for US content, and a separate .eu or .co.uk or .de or whatever other domain for your European content.  That, while also setting up hreflang tagging, is really more helpful in communicating what should show up in which search results higher up.

You'll also need to accumulate inbound geo-relevant links to point to the appropriate content set to help reinforce this.

And if you split out domains, you can set country targeting more readily in Google Search Console.

For more info:

https://support.google.com/webmasters/answer/182192?hl=en

 https://support.google.com/webmasters/answer/189077?hl=en

UPDATE TO MY ORIGINAL COMMENT

I initially found a problem doing a ping and traceroute test using Pingdom.com - both returned an "invalid host name" error, something I have not seen previously for both ping and traceroute simultaneously.

Nitin (see his comment below) did a similar test locally and found both to be okay.  Though he has other thoughts.

I just wanted to clarify here now, that my original finding may not be a key to this issue, though I want to understand why my test came back that way...

In regard to shorter URLs:

The goal is to find a proper balance for your needs.  You want to group things into sub-groups based on proper hierarchy, however you also don't want to go too deep if you don't have enough pages/individual listings deep down the chain.

So the Moz post you point to refers to that - at a certain point, having too many layers can be a problem. However there is one one single correct answer.

The most important thing to be aware of and consider is your own research and evaluation process for your situation in your market.

However, as far as what you found most people search for, be aware that with location based search, many people don't actually type in a location when they are doing a search.  Except Google DOES factor in the location when deciding what to present in results.  So the location matters even though people don't always include it themselves.

The issue is not to become completely lost in making a decision either though - consider all the factors, make a business decision to move forward with what you come up with, and be consistent in applying that plan across the board.

What I mean in regard to URLs and Breadcrumbs:

If the URL is www.askme.com/dehli/saket/pizza/pizza-hut/  the breadcrumb should be:

Home > Dehli > Saket > Pizza > Pizza Hut

If the URL is www.askme.com/pizza-huts/saket-delhi/ the breadcrumb should be

Home > Pizza Hut > Saket-Delhi

Proximity to root is not a valid best practice, especially in this instance.

Here's why:

More people search based on geo-location than actual business name when looking for location based businesses.  So by putting "Pizza Hut" first, that contradicts this notion. It implies "more people look for Pizza Hut than the number of people looking for all the different businesses in this geo-location".

Also, by using the URL you suggest, that's blatant over-optimization - attempting to stuff exact match keywords into the URL. In reality, people use a very wide range of keyword variations, so that's another conflict that harms your overall focus needs.

All of the individual factors need to reinforce each other as much as is reasonable for human readability. So URL, breadcrumb both should match the sequence.  If one has one sequence, and the other has a different sequence, that confuses search algorithms.

Local pack exists, yet is far from complete or consistently helpful.  Business directories thrive even in an age of local packs.  It's all about finding the best way to provide value, and the internet is large enough that many players can play in the game.

Business listing directory environments have a big challenge when it comes to URL structure / information architecture and content organization because:

1. Many businesses are searched for based on geo-location
2. Many of those require hyper-local referencing while many others can be "in the general vacinity"
3. Many other businesses are not as relevant to geo-location

So what is a site to do?

The best path is to recognize that as mobile becomes more and more critical to searcher needs, hyper-local optimization becomes more critical.  It becomes the most important focus for SEO.

As a result, URL structure needs to reflect hyper-local first and foremost. So:

• www.askme.com/delhi/
• www.askme.com/delhi/saket/
• www.askme.com/delhi/saket/pizza/
• www.askme.com/dehli/saket/pizza/pizza-hut/

This way, if someone searches for "Pizza Hut Dehli", all of the Dehli Pizza Huts will show up, regardless of neighborhood, while anyone searching for "Pizza Hut Saket" will get more micro-locally relevant results.

And for those businesses that serve a wider geo-area, even though they too will be assigned a hyper-local final destination page, they will still be related to their broader geo-area as well.  So someone searching "plumbers in Dehli" will get the right results and then they can choose any of the plumbers in Dehli regardless of what neighborhood they are in.

Note how I removed /search/ from the URL structure as well. It's an irrelevant level.

I the examples Kristina offered.

It's really important to understand that integrating competitor product information into your site needs to be done artfully as much as scientifically.

Get the message wrong, and you expose the company to DMCA takedown vulnerability, as well as potential lawsuits for business-damaging misinformation, or worse, having governmental agencies come after you.

In other words, there are several "right" ways to go about it, and several "wrong" ways.

Please be sure a professional is involved in this process, whatever the "method" or "style" of your approach might be - someone who understands the legal issues involved enough to avoid those vulnerabilities.