Panda Remediation and CMS Limitations – 5 Problems You Might Encounter

When you’ve been hit by Panda it’s extremely important to quickly identify the root causes of the attack. I typically jump into a deep crawl analysis of the site while performing an extensive audit through the lens of Panda. The result is a remediation plan covering a number of core website problems that need to be rectified sooner than later.

And for larger-scale websites, the remediation plan can be long and complex. It’s one of the reasons I tend to break up the results into smaller pieces as the analysis goes on. I don’t want to dump 25 pages of changes into the lap of a business owner or marketing team all at one time. That can take the wind out of their sails in a hurry.

But just because problems have been identified, and a remediation plan mapped out, it does not mean all is good in Panda-land. There may be times that serious problems cannot be easily resolved. And if you can’t tackle low-quality content on a large-scale site hit by Panda, you might want to get used to demoted rankings and low traffic levels.

When Your CMS Is the Problem

One problem in particular that I’ve come across when dealing with Panda remediation is the dreaded content management system (CMS) obstacle. And I’m using "CMS" loosely here, since some internal systems are not actually content management systems. They simply provide a rudimentary mechanism for getting information onto a website. There’s a difference between that and a full-blown CMS. Regardless, the CMS being used can make Panda changes easy, or it can make them very hard. Each situation is different, but again, it’s something I’ve come across a number of times while helping clients.

When presenting the remediation plan to a client’s team, there are usually people representing various aspects of the business in the meeting. There might be people from marketing, sales, development, IT and engineering, and even C-level executives on the call. And that’s awesome. In my opinion, everyone needs to be on the same page when dealing with an issue as large as Panda.

But at times IT and engineering has the task of bringing a sense of reality with regard to how effectively changes can be implemented. And I don’t envy them for being in that position. There’s a lot of traffic and revenue on the line, and nobody wants to be the person that says, "we can’t do that."

For example, imagine you surfaced 300,000 pages of thin content after getting pummeled by Panda. The pages have been identified, including the directories that have been impacted, but the custom CMS will not enable you to easily handle that content. When the CMS limitations are explained, the room goes silent.

That’s just one real-world example I’ve come across while helping companies with Panda attacks. It’s not a comfortable situation, and absolutely needs to be addressed.

Trapped With Panda Problems

So what types of CMS obstacles could you run into when trying to recover from Panda? Unfortunately, there are many, and they can sometimes be specifically tied to your own custom CMS. Below, I’ll cover five problems I’ve seen first-hand while helping clients with Panda remediation. Note, I can’t cover all potential CMS problems that can inhibit Panda recovery, but I did focus on five core issues. Then I’ll cover some tips for overcoming those obstacles.

1. 404s and 410s

When you hunt down low-quality content, and have a giant list of URLs to nuke (remove from the site), you want to issue either 404 or 410 header response codes. So you approach your dev team and explain the situation. But unfortunately for some content management systems, it’s not so easy to isolate specific URLs to remove. And if you cannot remove those specific low-quality URLs, you may never escape the Panda filter. It’s a catch 22 with a Panda rub.

In my experience, I’ve seen CMS packages that could 404 pages, but only by major category. So you would be throwing the baby out with the bath water. When you nuke a category, you would be nuking high-quality content along with low-quality content. Not good, and defeats the purpose of what you are trying to accomplish with your Panda remediation.

I’ve also seen CMS platforms that could only remove select content from a specific date forward or backward. And that’s not good either. Again, you would be nuking good content with low-quality content, all based on date. The goal is to boost the percentage of high-quality content on your site, not to obliterate large sections of content that can include both high- and low-quality URLs.

2. Meta Robots Tag

Similar to what I listed above, if you need to noindex content (versus remove), then your CMS must enable you to dynamically provide the meta robots tag. For example, if you find 50,000 pages of content on the site that is valuable for users to access, but you don’t want the content indexed by Google, you could provide the meta robots tag on each page using "noindex, follow." The pages won’t be indexed, but the links on the page would be followed. Or you could use "noindex, nofollow" where the pages wouldn’t be indexed and the links wouldn’t be followed. It depends on your specific situation.

But once again, the CMS could provide obstacles to getting this implemented. I’ve seen situations where once a meta robots tag is used and in the page’s code, it’s impossible to change. Or I’ve seen multiple meta robots tags used on the page in an effort to noindex content that’s low quality.

And beyond that, there have been times where the meta robots tag isn’t even an option in the CMS. That’s right, you can’t issue the tag even if you wanted to. Or, similar to what I explained earlier, you can’t selectively use the tag. It’s a category or class-level directive that would force you to noindex high-quality content along with low-quality content. And we’ve already covered why that’s not good.

The meta robots tag can be a powerful piece of code in SEO, but you need to be able to use it correctly and selectively. If not, it can have serious ramifications.

3. Nofollow

The proper use of nofollow crosses algorithms, and I’ll include it in this post as I’ve encountered nofollow problems during Panda projects. But this can help across link penalties and Penguin situations too. And let’s hope your CMS cooperates when you need it to.

For example, I’ve helped some large affiliate websites that had a massive followed links problem. Affiliate links should be nofollowed and should not flow PageRank to destination websites (where there is a business relationship). But what if you have a situation where all, or most of, your affiliate links were followed? Let’s say your site has 2 million pages indexed and contains many followed affiliate links to e-commerce websites. The best way to handle this situation is to simply nofollow all affiliate links throughout the content, while leaving any natural links intact (followed). That should be easy, right? Not so fast…

What seems like a quick fix via a content management system could turn out to be a real headache. Some custom CMS platforms can only nofollow all links on the page, and that’s definitely not what you want to do. You only want to selectively nofollow affiliate links.

In other situations, I’ve seen CMS packages only be able to nofollow links from a certain date forward, as upgrades to the CMS finally enabled selective nofollows. But what about the 400,000 pages that were indexed before that date? You don’t want to leave those as-is if there are followed affiliate links. Again, a straightforward situation that suddenly becomes a challenge for business owners dealing with Panda.

4. Rel Canonical

There are times that a URL gets replicated on a large-scale website (for multiple reasons). So that one URL turns into four or five URLs (or more). And on a site that houses millions of pages of content, the problem could quickly get out of control. You could end up with tens of thousands, hundreds of thousands, or even millions of duplicate URLs.

You would obviously want to fix the root problem of producing non-canonical versions of URLs, but I won’t go down that path for now. Let’s just say you wanted to use the canonical URL tag on each duplicate URL pointing to the canonical URL. That should be easy, right? Again, not always…

I’ve seen some older CMS packages not support rel canonical at all. Then you have similar situations to what I explained above with 404s and noindex. Basically, the CMS is incapable of selectively issuing the canonical URL tag. It can produce a self-referencing href (pointing to itself), but it can’t be customized. So all of the duplicate URLs might include the canonical URL tag, but they are self-referencing. That actually reinforces the duplicate content problem… instead of consolidating indexing properties to the canonical URL.

By the way, I wrote a post in December covering a number of dangerous rel canonical problems that can cause serious issues. I recommend reading that post if you aren’t familiar with how rel canonical can impact your SEO efforts.

5. Robots.txt

And last, but not least, I’ve seen situations where a robots.txt file had more security and limitations around it than the President of the United States. For certain CMS packages or custom CMS platforms, there are times the robots.txt file can only contain certain directives, while only being implemented via the CMS itself (with no customization possible).

For example, maybe you can only disallow major directories on the site, but not specific files. Or maybe you can disallow certain files, but you can’t use wildcards. By the way, the limitations might have been put in place via the CMS developers with good intentions. They understood the power of robots.txt, but didn’t leave enough room for scalability. And they definitely didn’t have Panda in mind, especially since some of the content management systems I’ve come across were developed prior to Panda hitting the scene!

In other robots.txt situations, I’ve seen custom changes get wiped out nightly (or randomly) as the CMS pushes out the latest robots.txt file automatically. Talk about frustrating. Imagine customizing a robots.txt file only to see it revert back at midnight. It’s like a warped version of Cinderella, only this time it’s a bamboo slipper and the prince of darkness. Needless to say, it’s important to have control of your robots.txt file. It’s an essential mechanism for controlling how search bots crawl your website.

What Could You Do?

When you run into CMS limitations while working on Panda remediation, you have several options for moving forward. The path you choose to travel completely depends on your own situation, the organization you work for, budget limitations, and resources. Below, I’ll cover a few ways you can move forward, based on helping a number of clients with similar situations.

1. Modify the CMS

This is the most obvious choice when you run into CMS functionality problems. And if you have the development chops in-house, then this can be a viable way to go. You can identify all of the issues SEO-wise that the CMS is producing, map out a plan of attack, and develop what you need. Then you can thoroughly test in a staging environment and roll out the new and improved CMS over time.

By tackling the root problems (the CMS functionality itself), you can be sure that the site will be in much better shape SEO-wise, not only in the short-term, but over the long-term as well. And if developed with the future in mind, then the CMS will be open to additional modifications as more technical changes are needed.

The downside is you’ll need seasoned developers, a budget, the time to work on the modifications, test them, debug problems, etc. Some organizations are large enough to take on the challenge and the cost, while other smaller companies will not. In my experience, this has been a strong path to take when dealing with CMS limitations SEO-wise.

2. Migrate to a New CMS

I can hear you groaning about this one already. :) In serious situations, where the CMS is so bad and so limiting, some companies choose to move to an entirely new CMS. Remember, Panda hits can sometimes suck the life out of a website, so grave SEO situations sometimes call for hard decisions. If the benefits of migrating to a new CMS far outweigh the potential pitfalls of the migration SEO-wise, then this could be a viable way to go for some companies.

But make no bones about it, you will now be dealing with a full-blown CMS migration. And that bring a number of serious risks with it. For example, you’ll need to do a killer job of migrating the URLs, which includes a solid redirection plan. You’ll need to ensure valuable inbound links don’t get dropped along the way. You’ll need to make sure the user experience doesn’t suffer (across devices). And you’ll have a host of other concerns and mini-projects that come along with a redesign or CMS migration.

For larger-scale sites, this is no easy feat. Actually, redesigns and CMS migrations are two of the top reasons I get calls about significant drops in organic search traffic. Just understand this before you pull the trigger on migrating to a new CMS. It’s not for the faint of heart.

3. Project Frankenstein – Tackle What You Can, and When You Can

Panda is algorithmic, and algorithms are all about percentages. In a perfect world, you would tackle every possible Panda problem riddling your website. But in reality, some companies cannot do this. But you might be able to still recover from Panda without tackling every single problem. Don’t get me wrong, I’ve written before about band-aids not being a long-term solution for Panda recovery, but if you can tackle a good percentage of problems, then you might rid yourself of the Panda filter.

Let me emphasize that this is not the optimal path to take, but if you can’t take any other path, then do your best with Project Frankenstein.

For example, if you can’t make significant changes to your CMS (development-wise), and you can’t migrate to a new CMS, then maybe you can still knock out some tasks in the remediation plan that remove a good amount of thin and low-quality content. I’ve had a number of clients in this situation over the years, and this approach has worked for some of them.

As a quick example, one client focused on four big wins based on the remediation plan I mapped out. They were able to nuke 515,000 pages of thin and low-quality content from the site based on just one find from the crawl analysis and audit. Now, it’s a large site, but that’s still a huge find Panda-wise. And when you added the other three items they could tackle from the remediation plan, the total amount of low-quality content removed from the site topped 600,000 pages.

So although Frankenstein projects aren’t sexy or ultra-organized, they still have a chance of working from a Panda remediation standpoint. Just look for big wins that can be forced through. And try and knock out large chunks of low-quality content while publishing high-quality content on a regular basis. Again, it’s about percentages.

Summary – Don’t Let Your CMS Inhibit Panda Recovery

Panda remediation is tough, but it can be exponentially tougher when your content management system (CMS) gets in the way. When you’ve been hit by Panda, you need to work hard to improve content quality on your website (which means removing low-quality content, while also creating or boosting high-quality content.) Don’t let your CMS inhibit a Panda recovery by placing obstacles in your way. Instead, understand the core limitations, meet with your dev and engineering teams to work through the problems, and figure out the best way to overcome those obstacles. That’s a strong, long-term approach to ridding Panda from your site.

(via)

Recover From Panda? Follow These 5 Steps to Avoid Future Panda Hits

For those dealing with a major drop in traffic due to an algorithm update, I’m not sure there’s a better feeling in the world than seeing recovery. The original algo hit typically feels like a punch in the gut, with serious confusion and frustration quickly following. Then you have months of recovery work with hope (and faith) that your hard work will pay off. And for some, recovery will never happen. That’s an unfortunate truth for sites that have pushed the limits of spamming repeatedly for a long time.

So, when you finally see something like the screenshot below, it’s hard not to throw your hands up in the air and dance in the streets. This trending is from a client that recovered during the 9/5 Panda update from a horrible hit this past spring. They had been working on recovery for more than four months and are up 81 percent since the 9/5 Panda update.

That’s awesome, but it’s at that point in time that I typically tell clients to stop celebrating, put down the piña coladas, and get ready to take action. You see, this is exactly the time to analyze that surge in traffic to ensure you aren’t feeding Google the same (or similar) problems that got you hit in the first place.

Just because traffic is surging doesn’t mean you can’t get hit again. Just read my post about thesinister surge in traffic before an algorithm hit to learn more about that phenomenon. And now that Panda is near-real-time, you can actually get hit again relatively quickly. I have seen a number of temporary recoveries over the past few months (especially since Panda 4.0).

Revisiting the Gray Area of Panda (and Algorithms in General)

To better understand why and how this can happen, let’s quickly revisit the gray area of Panda (and other algorithms). It’s an important point that I think many don’t understand. With any algorithm, there’s an inherent gray area. When you cross a threshold, you can get hit by the algo update. If you stay below that threshold, you will probably not experience the negative drop. So, within the range of the strike zone, there are various shades of danger.

I’ve provided an image below that depicts the various levels of danger when it comes to algorithm updates. You have the area in white, which is the safe zone. Then there’s the gray area, with various shades of gray. The closer you get to the strike zone, the darker the gray area becomes. And then you have the impact zone, where you clearly cross the algorithmic threshold. That actually begins in the darker gray area and leads to the zone that is blacked out (which is pure algorithmic hell).

The gray area is important to understand because you want to stay out of it. If you enter the gray area, either knowingly or unknowingly, you are in danger of being hit by Panda. And if you do get hit, and you remain in the gray area, you will never know how far you are to recovery. Google unfortunately doesn’t inform webmasters that they are being algorithmically demoted or how close they are to recovery. And if you don’t make enough changes, you can sit in the gray area forever. I’ve explained before that the gray area of Panda is one of the most frustrating places to sit when you are trying to recover.

Recovery-wise, if you only perform enough work to barely exit the gray area, you can recover, but only temporarily. Since you are on the fringe of the strike zone, you can easily get hit by subsequent algorithm updates. As I’ve explained before here on Search Engine Watch, SEO band-aids do not lead to long-term recovery. That’s because a site can jump in and out of the gray area, experiencing hit, then recovery, another hit, then recovery again, so on and so forth. It’s a horrible place to live.

Post-Recovery Checks to Ensure the Surge Remains

OK, now that I’ve covered why it’s important to analyze the surge in traffic based on recovery, it’s time to take action. As a webmaster experiencing Panda recovery, you want to make sure user engagement is strong, users from Google organic are happy, and your landing pages are as high-quality as possible. You don’t want to find a bunch of low-quality landing pages, blank pages, thin content, heavy ad problems, technical glitches, etc. Just like bamboo, they can attract the mighty Panda again.

Here are five things you can do today to ensure the recovery surge is going to pay off, and not send you back to the gray area of Panda.

1. Analyze Top Landing Pages From Google Organic (via Google Analytics and Google Webmaster Tools)

When you’re hit by Panda, it’s important to analyze the top landing pages leading to the site prior to the Panda hit. That’s where Google is getting user engagement data from, and you can often find glaring issues while going through the process of checking those pages.

Well, now that Google traffic has returned based on recovery, it’s smart to analyze the top pages receiving that traffic to ensure all is OK from a content quality standpoint. The last thing you want to do is drive users from Google organic to thin pages, broken pages, pages with serious ad problems, etc.

I recommend comparing the post-recovery timeframe to the previous timeframe to determine the change in traffic level per url (from Google organic). You can do this via both Google Analytics and Google Webmaster Tools. Then dig into the content receiving the most traffic post-Panda recovery to ensure all is OK.

And make sure you keep an eye on the keywords leading to the various landing pages. Make sure they line up. For example, make sure your landing pages provide rich information based on what users are searching for. If not, those users might not be very happy. And if they aren’t, Google can certainly pick that up.

2. Check Mobile Versus Desktop Traffic (From Google Organic).

In my last post, I explained how mobile traffic could be impacting your Panda situation. For example, if 50 percent of your Google organic traffic is from smartphone users, then that’s 50 percent of the data Google is going to measure when it comes to Panda.

Therefore, it’s important to understand how much mobile traffic is hitting your site from Google, and where that traffic is going. Then you should analyze that traffic via mobile devices. Yes, that means using multiple mobile devices to test the top landing pages for smartphone users.

I just went through this process for several clients of mine that recovered during the 9/5 Panda update. You would be surprised what you can find. During my analysis, I found technical problems, content problems, ad problems, and more. I even found problems that were fixed after my initial audit that had returned. And my clients had no idea that was happening.

3. Use Fetch and Render

After Panda 4.0 (coincidentally or not), Google released fetch and render in Google Webmaster Tools. The tool enables you to fetch a URL on your site as Googlebot, but also view a snapshot of the rendered page. Googlebot can now fetch the necessary resources like JavaScript and CSS and actually render the page (like an actual user would).

I highly recommend testing a number of the top landing pages post-Panda recovery via fetch and render. Similar to what I explained earlier, you might be surprised what you find. I recently found a number of problems across companies that recovered, including landing pages that wouldn’t render at all, just the template rendering without the core content, ads that were broken or wouldn’t display, and more. Without using fetch and render, you might miss serious rendering problems that Googlebot is actually running into.

And by the way, you can use fetch and render as Googlebot (desktop) and Googlebot for Smartphones. This enables you to render top landing pages from desktop or mobile the way that users would see them.

4. Utilize Human Review (Yes, Real Human Beings.)

There are many Panda victims that never go through the process of having real people test their websites and provide feedback. Too many try to seek out simple technical problems that are causing issues versus trying to understand true user engagement. Don’t get me wrong, technical problems can definitely cause content quality issues, but Panda heavily takes into account user happiness. When performing audits, I often surface serious problems that impact user engagement (and cause users to bounce off the site.)

John Mueller from Google has explained this point a number of times, yet I still find Panda victims try to hunt down the silver Panda bullet. In my experience, Panda is rarely caused by one issue. There are typically a number of problems I surface during deep Panda audits. I know that might be frustrating for some people to understand, but it’s the truth.

Here’s a graphic representing the deadly Panda cocktail. And yes, it will definitely leave you and your site with a nasty hangover.

To better understand possible user engagement problems (even after recovery), I recommend having neutral third parties go through your website and provide objective feedback. Most business owners are way too close to their own websites to objectively review their content, user experience, ad situation, etc. And then they spin their wheels working on Panda recovery.

I recommend having a test group go through your website with a list of goals to achieve. Vary those goals and have them document everything. Make sure they understand you don’t want sugarcoated feedback. If something looks off, sounds weird, looks spammy, etc., they should document it. Have them jot down technical glitches, content issues, grammatical and spelling errors, advertising problems, usability issues, etc. Ask how they feel about the design of your website and how trustworthy the site is.

5. Perform a Crawl Analysis

In my previous posts about Panda, I explained how important a crawl analysis can be for hunting down Panda problems after getting hit by an update. And that’s especially the case for larger-scale websites. For example, sites with more than 500,000 pages indexed.

But crawls can help after recovery, too. If you have recently recovered from Panda, then it makes complete sense to crawl the top pages receiving traffic from Google organic post-recovery. This will enable you to gather data about those pages at scale. For example, hunting down thin content, finding soft 404s, URLs with poor page speed, funky redirects, duplicate content, etc.

There are times a solid crawl can lead you down interesting paths. Then it’s up to you and your SEO to analyze the situation to determine potential Panda problems. Some findings will definitely be benign, while others lead to serious bamboo. This is where human SEO intelligence and SEO tools combine to provide critical insights.

Tool-wise, there are several strong solutions for crawling websites. I like using Screaming Frog for small to medium-size websites, and DeepCrawl for larger-scale websites. And you can always use a combination of tools to slice and dice various sections of a website.

Just keep in mind that the reports won’t provide "Panda problems" on a silver platter. You’ll need to use your SEO knowledge to hunt down problems based on what the crawl surfaces.

Summary: Post Recovery Analysis Can Keep the Panda at Bay

Recovering from an algorithm hit is an amazing feeling. That said, you need to hold off on celebrating until you make sure your newly found Google organic traffic is happy with your content. Performing a post-recovery analysis can help identify problematic content, user engagement issues, technical problems, advertising issues, and more. And those problems can unfortunately provide a bamboo trail for Panda leading back to your website. Don’t fall victim to subsequent algorithm hits. Performing the proper analysis can keep the mighty Panda (and other algorithmic animals) at bay. And that’s exactly what you want to do.

(via)

Recover From Panda? Follow These 5 Steps to Avoid Future Panda Hits

For those dealing with a major drop in traffic due to an algorithm update, I’m not sure there’s a better feeling in the world than seeing recovery. The original algo hit typically feels like a punch in the gut, with serious confusion and frustration quickly following. Then you have months of recovery work with hope (and faith) that your hard work will pay off. And for some, recovery will never happen. That’s an unfortunate truth for sites that have pushed the limits of spamming repeatedly for a long time.

So, when you finally see something like the screenshot below, it’s hard not to throw your hands up in the air and dance in the streets. This trending is from a client that recovered during the 9/5 Panda update from a horrible hit this past spring. They had been working on recovery for more than four months and are up 81 percent since the 9/5 Panda update.

That’s awesome, but it’s at that point in time that I typically tell clients to stop celebrating, put down the piña coladas, and get ready to take action. You see, this is exactly the time to analyze that surge in traffic to ensure you aren’t feeding Google the same (or similar) problems that got you hit in the first place.

Just because traffic is surging doesn’t mean you can’t get hit again. Just read my post about thesinister surge in traffic before an algorithm hit to learn more about that phenomenon. And now that Panda is near-real-time, you can actually get hit again relatively quickly. I have seen a number of temporary recoveries over the past few months (especially since Panda 4.0).

Revisiting the Gray Area of Panda (and Algorithms in General)

To better understand why and how this can happen, let’s quickly revisit the gray area of Panda (and other algorithms). It’s an important point that I think many don’t understand. With any algorithm, there’s an inherent gray area. When you cross a threshold, you can get hit by the algo update. If you stay below that threshold, you will probably not experience the negative drop. So, within the range of the strike zone, there are various shades of danger.

I’ve provided an image below that depicts the various levels of danger when it comes to algorithm updates. You have the area in white, which is the safe zone. Then there’s the gray area, with various shades of gray. The closer you get to the strike zone, the darker the gray area becomes. And then you have the impact zone, where you clearly cross the algorithmic threshold. That actually begins in the darker gray area and leads to the zone that is blacked out (which is pure algorithmic hell).

The gray area is important to understand because you want to stay out of it. If you enter the gray area, either knowingly or unknowingly, you are in danger of being hit by Panda. And if you do get hit, and you remain in the gray area, you will never know how far you are to recovery. Google unfortunately doesn’t inform webmasters that they are being algorithmically demoted or how close they are to recovery. And if you don’t make enough changes, you can sit in the gray area forever. I’ve explained before that the gray area of Panda is one of the most frustrating places to sit when you are trying to recover.

Recovery-wise, if you only perform enough work to barely exit the gray area, you can recover, but only temporarily. Since you are on the fringe of the strike zone, you can easily get hit by subsequent algorithm updates. As I’ve explained before here on Search Engine Watch, SEO band-aids do not lead to long-term recovery. That’s because a site can jump in and out of the gray area, experiencing hit, then recovery, another hit, then recovery again, so on and so forth. It’s a horrible place to live.

Post-Recovery Checks to Ensure the Surge Remains

OK, now that I’ve covered why it’s important to analyze the surge in traffic based on recovery, it’s time to take action. As a webmaster experiencing Panda recovery, you want to make sure user engagement is strong, users from Google organic are happy, and your landing pages are as high-quality as possible. You don’t want to find a bunch of low-quality landing pages, blank pages, thin content, heavy ad problems, technical glitches, etc. Just like bamboo, they can attract the mighty Panda again.

Here are five things you can do today to ensure the recovery surge is going to pay off, and not send you back to the gray area of Panda.

1. Analyze Top Landing Pages From Google Organic (via Google Analytics and Google Webmaster Tools)

When you’re hit by Panda, it’s important to analyze the top landing pages leading to the site prior to the Panda hit. That’s where Google is getting user engagement data from, and you can often find glaring issues while going through the process of checking those pages.

Well, now that Google traffic has returned based on recovery, it’s smart to analyze the top pages receiving that traffic to ensure all is OK from a content quality standpoint. The last thing you want to do is drive users from Google organic to thin pages, broken pages, pages with serious ad problems, etc.

I recommend comparing the post-recovery timeframe to the previous timeframe to determine the change in traffic level per url (from Google organic). You can do this via both Google Analytics and Google Webmaster Tools. Then dig into the content receiving the most traffic post-Panda recovery to ensure all is OK.

And make sure you keep an eye on the keywords leading to the various landing pages. Make sure they line up. For example, make sure your landing pages provide rich information based on what users are searching for. If not, those users might not be very happy. And if they aren’t, Google can certainly pick that up.

2. Check Mobile Versus Desktop Traffic (From Google Organic).

In my last post, I explained how mobile traffic could be impacting your Panda situation. For example, if 50 percent of your Google organic traffic is from smartphone users, then that’s 50 percent of the data Google is going to measure when it comes to Panda.

Therefore, it’s important to understand how much mobile traffic is hitting your site from Google, and where that traffic is going. Then you should analyze that traffic via mobile devices. Yes, that means using multiple mobile devices to test the top landing pages for smartphone users.

I just went through this process for several clients of mine that recovered during the 9/5 Panda update. You would be surprised what you can find. During my analysis, I found technical problems, content problems, ad problems, and more. I even found problems that were fixed after my initial audit that had returned. And my clients had no idea that was happening.

3. Use Fetch and Render

After Panda 4.0 (coincidentally or not), Google released fetch and render in Google Webmaster Tools. The tool enables you to fetch a URL on your site as Googlebot, but also view a snapshot of the rendered page. Googlebot can now fetch the necessary resources like JavaScript and CSS and actually render the page (like an actual user would).

I highly recommend testing a number of the top landing pages post-Panda recovery via fetch and render. Similar to what I explained earlier, you might be surprised what you find. I recently found a number of problems across companies that recovered, including landing pages that wouldn’t render at all, just the template rendering without the core content, ads that were broken or wouldn’t display, and more. Without using fetch and render, you might miss serious rendering problems that Googlebot is actually running into.

And by the way, you can use fetch and render as Googlebot (desktop) and Googlebot for Smartphones. This enables you to render top landing pages from desktop or mobile the way that users would see them.

4. Utilize Human Review (Yes, Real Human Beings.)

There are many Panda victims that never go through the process of having real people test their websites and provide feedback. Too many try to seek out simple technical problems that are causing issues versus trying to understand true user engagement. Don’t get me wrong, technical problems can definitely cause content quality issues, but Panda heavily takes into account user happiness. When performing audits, I often surface serious problems that impact user engagement (and cause users to bounce off the site.)

John Mueller from Google has explained this point a number of times, yet I still find Panda victims try to hunt down the silver Panda bullet. In my experience, Panda is rarely caused by one issue. There are typically a number of problems I surface during deep Panda audits. I know that might be frustrating for some people to understand, but it’s the truth.

Here’s a graphic representing the deadly Panda cocktail. And yes, it will definitely leave you and your site with a nasty hangover.

To better understand possible user engagement problems (even after recovery), I recommend having neutral third parties go through your website and provide objective feedback. Most business owners are way too close to their own websites to objectively review their content, user experience, ad situation, etc. And then they spin their wheels working on Panda recovery.

I recommend having a test group go through your website with a list of goals to achieve. Vary those goals and have them document everything. Make sure they understand you don’t want sugarcoated feedback. If something looks off, sounds weird, looks spammy, etc., they should document it. Have them jot down technical glitches, content issues, grammatical and spelling errors, advertising problems, usability issues, etc. Ask how they feel about the design of your website and how trustworthy the site is.

5. Perform a Crawl Analysis

In my previous posts about Panda, I explained how important a crawl analysis can be for hunting down Panda problems after getting hit by an update. And that’s especially the case for larger-scale websites. For example, sites with more than 500,000 pages indexed.

But crawls can help after recovery, too. If you have recently recovered from Panda, then it makes complete sense to crawl the top pages receiving traffic from Google organic post-recovery. This will enable you to gather data about those pages at scale. For example, hunting down thin content, finding soft 404s, URLs with poor page speed, funky redirects, duplicate content, etc.

There are times a solid crawl can lead you down interesting paths. Then it’s up to you and your SEO to analyze the situation to determine potential Panda problems. Some findings will definitely be benign, while others lead to serious bamboo. This is where human SEO intelligence and SEO tools combine to provide critical insights.

Tool-wise, there are several strong solutions for crawling websites. I like using Screaming Frog for small to medium-size websites, and DeepCrawl for larger-scale websites. And you can always use a combination of tools to slice and dice various sections of a website.

Just keep in mind that the reports won’t provide "Panda problems" on a silver platter. You’ll need to use your SEO knowledge to hunt down problems based on what the crawl surfaces.

Summary: Post Recovery Analysis Can Keep the Panda at Bay

Recovering from an algorithm hit is an amazing feeling. That said, you need to hold off on celebrating until you make sure your newly found Google organic traffic is happy with your content. Performing a post-recovery analysis can help identify problematic content, user engagement issues, technical problems, advertising issues, and more. And those problems can unfortunately provide a bamboo trail for Panda leading back to your website. Don’t fall victim to subsequent algorithm hits. Performing the proper analysis can keep the mighty Panda (and other algorithmic animals) at bay. And that’s exactly what you want to do.

(via)

Panda Has a Smartphone – Here Are 7 Things You Can Do to Test It Now

When companies are hit by Panda and see a huge drop in Google organic traffic, they often run to check their websites. They fire up Chrome or Firefox on their desktop computer and start looking around. That’s a smart thing to do, as deep Panda analysis is worth its weight in gold. But by spending so much time analyzing their websites via a desktop computer, they might be missing an extremely important segment of their traffic that’s growing every single day – MOBILE.

Panda and Engagement

In a nutshell, Google’s Panda algorithm is trying to understand how happy users are with your site. It’s more about engagement than some technical problem (although I have seen technical problems impact content quality). Sites hit by Panda often have serious problems from a user engagement standpoint, a credibility standpoint, and even a deception standpoint. You can read my previous posts about Panda to learn more about what I’m referring to.

So, understanding that Panda focuses on engagement, webmasters impacted by our bamboo-eating friend need to hunt down problematic content, functionality, usability issues, advertising issues, etc.

But while analyzing a site impacted by Panda, you may have to take a different angle with your review. Depending on your audience, you may need to stop looking at your beautiful site in Chrome on that 24-inch flat screen. Instead, you may need to pull out your phone with a 4- to 5-inch screen. Mobile traffic just might be providing Google a boatload of negative user engagement data, and that data can absolutely lead to a Panda attack.

The Mobile Connection With Recent Panda 4.0 Victims

Panda 4.0 was a huge update. I won’t go crazy here detailing the update, since I’ve already written several posts about the recoveries and fresh hits. Since May 20, I’ve been helping a number of companies with large-scale Panda attacks.

While analyzing websites impacted by P4.0, it wasn’t long before I noticed an interesting connection for some clients. One of the first things I do when jumping into a Panda audit is to perform a search history analysis. That’s where I analyze the site over time from a number of viewpoints. And one area I’ve been focusing on heavily is the percentage of mobile traffic leading to a website over time.

We all know mobile is growing rapidly, but there are still many sites with less than 20 percent mobile traffic. Don’t get me wrong, that’s still a good percentage of traffic from smartphones, but it’s not a majority. Then there are other websites in a much different situation. For example, I’m helping several large-scale websites now with Panda hits that have 50 percent mobile traffic from Google organic. Yes, 50 percent.

(Hint, the Most Important Line of This Column Is Coming Up…)

So, if Google’s Panda algorithm is measuring user experience, and your site gets 50 percent of its visits from mobile, then that means 50 percent of those Panda metrics are from mobile users. I’ll give you a second to read that last line again. Yes, half of the data Google has access to while analyzing your site from a Panda standpoint would be from mobile users.

Can you see why a heavy-duty analysis of your site via desktop might not cut it while analyzing a serious Panda hit? You would be only viewing half the problem. And depending on your technical setup, fixing half the problem might not lead to recovery.

The Mobile Panda - What You Can Do Now

If you have been hit by Panda and you’ve been focused on analyzing your site via desktop only, then you might feel like eating your smartphone now. Don’t, I’m here to help. This post can get you moving in the right direction from a mobile Panda standpoint, and quickly.

Below, I’ve listed seven things you can do today to better understand how mobile users are experiencing your website. Warning, what you find might scare you. And if it scares you, then think about what it does to a Panda with a smartphone. Note, I’m not going to cover each step in great detail. The post would get way too long. Instead, my goal is to get you moving in the right direction so you can identify potential Panda problems for mobile users. Then it’s your job to dig in and fix those problems.

1. Segment Mobile Data in Google Analytics

The first thing you need to do is to hop over to Google Analytics and check out your mobile reporting. Click the Audience tab in the left menu, click Mobile, and then Overview. Then set the timeframe to before the Panda attack. I recommend checking a good six to eight weeks prior to the drop in traffic. The report will show you the total sessions broken down by desktop, tablet, and mobile.

Again, what you find might shock you. There are some clients I have that see more than 50 percent of their overall traffic from mobile devices. But don’t stop there. You want to see the percentage of mobile traffic from organic search. Click the Segmentation drop down, which should currently read "All Sessions." Then choose Organic Traffic from the System list of segments, which will filter your reporting by organic search traffic hitting your site. Click the Apply button at the bottom of the menu to apply the filter.

Quick Tip: You can create your own segment for just Google Organic traffic to see how much mobile traffic is hitting your site (just from Google). I won’t cover the steps in this column, but creating custom segments is a powerful thing to do when analyzing websites.

The big takeaway here is that you now understand how much mobile traffic Google is using to measure user engagement. If you’ve been impacted by Panda, and it’s a high percentage, then you absolutely need to better-understand how mobile users are engaging with your site and content.

2. View Mobile Reporting in Google Webmaster Tools (GWT)

Let’s move to Google Webmaster Tools. I still find many webmasters don’t know that you can segment mobile search traffic directly in the Search Queries reporting in Google Webmaster Tools. You can, and it’s important to analyze.

Once you access Google Webmaster Tools, click Search Traffic from the left menu, and then Search Queries. The default report will be filtered by Web (for Web search). If you click the "Filters" button, you can choose "Mobile" instead.

By selecting Mobile, you can check your trending over the past 90 days for mobile search queries. That includes the number of impressions, clicks, click-through rate (CTR), and average position. The most important columns for our purposes today are impressions and clicks. You want to take note of how many you are receiving from mobile search and compare that to desktop. Again, you are looking for the percentage of mobile traffic to see how much bamboo you are feeding users.

Once you better-understand the percentages, you can drill into the search queries and top landing pages from mobile traffic. Talk about hunting down potential problems Panda-wise...You can match queries with landing pages and then directly visit those landing pages from the reporting in GWT.

Also, by clicking the Top Pages report, you can view all of the landing pages receiving impressions and clicks from mobile users. Remember, Google is getting a lot of its engagement data from users visiting these pages. You can often find glaring problems by visiting those top pages… And if you catch a Panda hit quickly, you can click the "With Change" button to compare the current timeframe to the previous time frame.

This is similar to what I explained about running a Panda report in Google Analytics. You can identify the core content seeing the largest drops in organic search traffic after the Panda hit. I recommend exporting the reporting to further analyze in Excel.

3. Test Your Site Via Multiple Devices (and Operating Systems)

Now that you know you have a lot of mobile traffic, and that mobile traffic can be impacting you Panda-wise, it’s time to fire up multiple mobile devices. This is where it’s smart to invest in several devices for testing purposes. I always have a number of devices accessible so I can test websites across various phones, tablets, sizes, operating systems, etc.

This is where the rubber hits the road. There’s nothing like testing a website via real mobile devices. You can get an amazing feel for usability, readability, load times, advertising issues, etc.

Bonus: Once you test your site across various devices, you can check the Devices report in Google Analytics to view engagement metrics tied to specific devices. For example, does the site lag on iPhones? Are Android users experiencing weird issues causing them to bounce off the site? Look for high bounce rates, low time on site, and low pages per visit for various smartphone models or operating systems. You might uncover some interesting things.

Also, remember the reports we ran earlier to find top landing pages from mobile? Well, visit those urls via your devices! That’s where mobile users from Google are going…so you should, too. Follow the bamboo trail.

4. Use Fetch and Render in Google Webmaster Tools

Google recently released fetch and render functionality in Google Webmaster Tools (coincidentally right after Panda 4.0). In the announcement, Google explained that Googlebot can fetch the resources necessary for rendering a page and provide reporting directly in Google Webmaster Tools. In addition, Google will provide a snapshot of the rendered page so you can view how it looks. By running fetch and render, you can identify resources being blocked, like JavaScript and CSS, and view a snapshot of the page as rendered by Googlebot. Awesome.

But it gets even better. You can choose a specific crawler to view how your pages are rendered via desktop, smartphone, and feature phone. You can fire up GWT and select Crawl from the left menu, and then Fetch as Google to access the functionality. For our purposes, you can enter a URL in the text field and then select "Mobile: Smartphone" from the drop-down to the right. When you click "Fetch and Render," Google will fetch the page and render it using the necessary resources to build the page content.

Once the render is complete, you will see a note under the "Status” column. It will say complete, partial, or error. Then you can click the status message to view the page details and to view a snapshot of the rendered page.

At this point, you might notice some strange things going on in the snapshot. Did your page render correctly? Is all the content present? Are blocks of content missing, including ads? What does Google list as blocked resources and did you know you were blocking them?

And most importantly, did you realize your mobile users are seeing those problems?

As Google notes, you should not block JavaScript and CSS via robots.txt. If you do, it can’t accurately render the page. Depending on what you find, you might need to dig deeper to debug and fix problems. And that’s a good thing. You’ll at least be in the know.

5. Test Your Site Via User Agent Switcher

Although testing via actual mobile devices is the best way to go, you can absolutely supplement your analysis with various Chrome and Firefox extensions. I often use the extension called User Agent Switcher to accomplish this task. There are a boatload of user agents you can download from the Web that you can import into User Agent Switcher. Then you can easily change your user agent on the fly to view websites like you would via mobile devices.

Note, I wouldn’t rely on this method fully, but it’s a quick way to get a feel for how websites are handling mobile traffic. For example, you can see if websites have faulty redirects being triggered by user agent. You can check if blocks of content are missing when switching user agent, if the navigation breaks, or if specific user agents are triggering other problems.

6. Crawl as Googlebot for Smartphones

Performing a crawl analysis of a website is an important and scalable way to supplement your manual audits. If a large percentage of your traffic is from smartphones, then you definitely want to know how Googlebot for Smartphones views your website.

Luckily, some of the most popular spidering tools enable you to do this. For example, both Screaming Frog and DeepCrawl enable you to change the user agent for your crawl.

Once you crawl your site as Googlebot for Smartphones, you can view the various issues being flagged. For example, you might see all requests being redirected to the homepage (faulty redirects). You might see many errors showing up during the crawl (that aren’t showing up when you run a standard crawl of the site). You might find the word count and file size to be low when crawling as Googlebot for Smartphones. And more.

All of these flags could lead to website rendering problems or the mishandling of mobile traffic. And if a large percentage of your traffic is experiencing these problems, then poor user engagement signals could be picked up by Google. And if that happens, the mighty Panda may not be happy.

7. Use Google’s PageSpeed Insights Tools

Last, but not least, is to test your webpages via Google’s PageSpeed Insights. When you run URLs through the tool, you can view a number of important recommendations and changes directly from Google. The tool fetches each url twice, once by a desktop user agent and the second via a mobile user agent.

There is an entire section labeled "Mobile" where Google provides recommendations for speeding up the page, enhancing the user experience, etc. You might find a number of issues that Google flags that you didn’t know were problematic. You will also see a screenshot of the page as rendered on a smartphone.

(via)