Tuesday, December 9th, 2014

6 Dangerous Rel Canonical Problems Based on Crawling 11M+ Pages in 2014

Dangerous Rel Canonical Problems

Based on helping clients with Panda work, Penguin problems, SEO technical audits, etc., I end up crawling a lot of websites. In 2014, I estimate that I crawled over eleven million pages while helping clients. And during those crawls, I often pick up serious technical problems inhibiting the SEO performance of the sites in question.

For example, surfacing response code issues, redirects, thin content, duplicate content, metadata problems, mobile issues, and more.  And since those problems often lie below the surface, they can sit unidentified and unresolved for a long time. It’s one of the reasons I believe SEO technical audits are the most powerful deliverable in all of SEO.

Last week, I found an interesting comment from John Mueller in a Google Webmaster Hangout video. He was speaking about the canonical url tag and explained that Google needs to process rel canonical as a second or third step (at 48:30 in the video). He explained that processing rel canonical signals is not part of the crawling process, but instead, it’s handled down the line. And that’s one reason you can see urls indexed that are canonicalized to other pages. It’s not necessarily a problem, but gives some insight into how Google handles rel canonical.

When analyzing my tweets a few days later, I noticed that specific tweet got a lot of eyeballs and engagement.

Tweet About Rel Canonical and John Mueller of Google


That got me thinking that there are probably several other questions about rel canonical that are confusing webmasters. Sure, Google published a post covering some common rel canonical problems, but that doesn’t cover all of the issues webmasters can face. So, based on crawling over eleven million pages in 2014, I figured I would list some dangerous rel canonical issues I’ve come across (along with how to rectify them). My hope is that some readers can leave this post and make changes immediately. Let’s jump in.


1. Canonicalizing Many URLs To One
When auditing websites I sometimes come across situations where entire sections of content are being canonicalized to one url. The sections might contain dozens or urls (or more), but the site is using the canonical url tag on every page in the section pointing to one other page on the site.

If the site is canonicalizing many pages to one, then it will have little chance of ranking for any of the content on the canonicalized pages. All of the indexing properties will be consolidated to the url used in the canonic al url tag (in the href). Rel canonical is meant to handle very similar content at more than one url, and was not meant for handling many pages of unique content pointing to one other page.

When explaining this to clients, they typically didn’t understand the full ramifications of implementing a many to one rel canonical strategy. By the way, the common reason for doing this is to try and boost the rankings of the most important pages on the site. For example, webmasters believe that if they canonicalize 60 pages in a section to the top-level page, then that top-level page will be the all-powerful url ranking in the SERPs. Unfortunately, while they are doing that, they strip away any possibility of the canonicalized pages ranking for the content they hold. And on larger sites, this can turn ugly quickly.

Rel Canonical Many URLs to One
If you have unique pages with valuable content, then do not canonicalize them to other pages… Let those pages be indexed, optimize the pages for the content at hand, and make sure you can rank for all of the queries that relate to that content. When you take the long tail of SEO into account, those additional pages with unique content can drive many valuable visitors to your site via organic search. Don’t underestimate the power of the long tail.


2. Daisy Chaining Rel Canonical
When using the canonical url tag, you want to avoid daisy chaining hrefs. For example, if you were canonicalizing page2.htm to page1.htm, but page 1.htm is then canonicalized to page3.htm, then you are sending very strange signals to the engines. To clarify, I’m not referring to actual redirects (like 301s or 302s), but instead, I’m talking about the hrefs used in the canonical url tag.

Here’s an example:
page 2.htm includes the following: <link rel=“canonical” href=“page1.htm” />
But page1.htm includes this: <link rel=“canonical” href=“page3.htm” />

Daisy Chaining Rel Canonical

While conducting SEO audits, I’ve seen this botched many times, even beyond the daisy chaining. Sometimes page3.htm doesn’t even exist, sometimes it redirects via 301s or 302s, etc.

Overall, don’t send mixed signals to the engines about which url is the canonical one. If you say it’s page1.htm but then tell the engines that it’s page3.htm once they crawl page1.htm, and then botch page3.htm in a variety of ways, you might experience some very strange ranking problems. Be clear and direct via rel canonical.


3. Using The Non-Canonical Version
This situation is a little different, but can cause problems nonetheless. I actually just audited a site that used this technique across 2.1M pages. Needless to say, they will be making changes asap. In this scenario, a page is referencing a non-canonical version of the original url via the canonical url tag.  But the non-canonical version actually redirects back to the original url.

For example:
page1.htm includes this: <link rel=“canonical” href=“page1.htm?id=46” />
But page1.htm?id=46 redirects back to page1.htm

Rel Canonical to Non-Canoncial Version of URL

So in a worst-case scenario, this is implemented across the entire site and can impact many urls. Now, Google views rel canonical as a hint and not a directive. So there’s a chance Google will pick up this error and rectify the issue on its end. But I wouldn’t bank on that happening. I would fix rel canonical to point to the actual canonical urls on the site versus non-canonical versions that redirect to the original url (or somewhere else).


4. No Rel Canonical + The Use of Querystring Parameters
This one is simple. I often find websites that haven’t implemented the canonical url tag at all. For some smaller and less complex sites, this isn’t a massive problem. But for larger, more complex sites, this can quickly get out of control.

As an example, I recently audited a website that heavily used campaign tracking parameters (both from external campaigns and from internal promotions). By the way, don’t use campaign tracking parameters on internal promotions… they can cause massive tracking problems. Anyway, many of those urls were getting crawled and indexed. And depending on how many campaigns were set up, some urls had many non-canonical versions being crawled and indexed.

Not Using Rel Canonical With Campaign Parameters

By implementing the canonical url tag, you could signal to the engines that all of the variations of urls with querystring parameters should be canonicalized to the original, canonical url. But without rel canonical in place, you run the risk of diluting the strength of the urls in question (as many different versions can be crawled, indexed, and linked to from outside the site).

Imagine 500K urls indexed with 125K duplicate urls also indexed. And for some urls, maybe there are five to ten duplicates per page. You can see how this can get out of control. It’s easy to set up rel canonical programmatically (either via plugins or your own server-side code). Set it up today to avoid a situation like what I listed above.


5. Canonical URL Tag Not Present on Mobile Urls (m. or other)
Mobile has been getting a lot of attention recently (yes, understatement of the year). When clients are implementing an m. approach to mobile handling, I make sure to pay particular attention the bidirectional annotations on both the desktop and mobile urls. And to clarify, I’m not just referring to a specific m. setup. It can be any mobile urls that your site is using (redirecting from the desktop urls to mobile urls).

For example, Google recommends you add rel alternate on your desktop urls pointing to your mobile urls and then rel canonical on your mobile urls pointing back to your desktop urls.

Not Using Rel Canonical With Mobile URLs

This ensures Google understands that the pages are the same and should be treated as one. Without the correct annotations in place, you are hoping Google understands the relationship between the desktop and mobile pages. But if it doesn’t, you could be providing many duplicate urls on your site that can be crawled and indexed. And on larger-scale websites (1M+ pages), this can turn ugly.

Also, contrary to what many think, separate mobile urls can work extremely well for websites (versus responsive or adaptive design). I have a number of clients using mobile urls and the sites rank extremely well across engines. You just need to make sure the relationship is sound from a technical standpoint.


6. Rel Canonical to a 404 (or Noindexed Page)
The last scenario I’ll cover can be a nasty one. This problem often lies undetected until pages start falling out the index and rankings start to plummet. If a site contains urls that use rel canonical pointing to a 404 or a noindexed page, then the site will have little shot of ranking for the content on those canonicalized pages. You are basically telling the engines that the true, canonical url is a 404 (not found), or a page you don’t want indexed (a page that uses the meta robots tag containing “noindex”).

I had a company reach out to me once during the holidays freaking out because their organic search traffic plummeted. After quickly auditing the site, it was easy to see why. All of their core pages were using rel canonical pointing to versions of that page that returned 404 header response codes. The site (which had over 10M pages indexed) was giving Google the wrong information, and in a big way.

Rel Canonical Pointing to 404 or Noindexed Page
Once the dev team implemented the change, organic search traffic began to surge. As more and more pages sent the correct signals to Google, and Google indexed and ranked the pages correctly, the site regained its traffic. For an authority site like this one, it only took a week or two to regain its rankings and traffic. But without changing the flawed canonical setup, I’m not sure it would ever surge back.

Side Note: This is why I always recommend checking changes in a staging environment prior to pushing them live. Letting your SEO review all changes before they hit the production site is a smart way to avoid potential disaster.


Summary – Don’t Botch Rel Canonical
I’ve always said that you need a solid SEO structure in order to rank well across engines. In my opinion, SEO technical audits are worth their weight in gold (and especially for larger-scale websites.) Rel canonical is a great example of an area that can cause serious problems if not handled correctly. And it often lies below the surface, wreaking havoc by sending mixed signals to the engines.

My hope is that the scenarios listed above can help you identify, and then rectify canonical url problems riddling your website. The good news is that the changes are relatively easy to implement once you identify the problems. My advice is to keep rel canonical simple, send clear signals, and be consistent across your website. If you do that, good things can happen. And that’s exactly what you want SEO-wise.



Wednesday, November 26th, 2014

Panda Analysis Using Google Analytics Segments – How To Isolate Desktop, Mobile, and Tablet Traffic From Google

Segments in Google Analytics to Isolate Traffic

In previous posts about Panda analysis, I’ve mentioned the importance of understanding the content that users are visiting from Google organic. Since Google is measuring user engagement, hunting down those top landing pages can often reveal serious content quality problems.

In addition, I’ve written about understanding the devices being used to access your site from the search results. For example, what’s the breakdown of users by desktop, mobile, and tablets from Google organic? If 50% of your visits are from smartphones, then you absolutely need to analyze your site through that lens. If not, you can miss important problems that users are experiencing while visiting your website. And if left unfixed, those problems can lead to a boatload of horrible engagement signals being sent to Google. And that can lead to serious Panda problems.

Panda Help Via Segments in Google Analytics
So, if you want to analyze your content by desktop, mobile, and tablet users through a Panda lens, what’s the best way to achieve that? Well, there’s an incredibly powerful feature in Google Analytics that I find many webmasters simply don’t use. It’s called segmentation and enables you slice and dice your traffic based on a number of dimensions or metrics.

Segments are non-destructive, meaning that you can apply them to your data and not affect the source of the data. Yes, that means you can’t screw up your reporting. :) In addition, you can apply new segments to previous traffic (they are backwards compatible). So you can build a new segment today and apply it to traffic from six months ago, or longer.

For our purposes today, I’m going to walk you through how to quickly build three new segments. The segments will isolate Google organic traffic from desktop users, mobile users, and tablet users. Then I’ll explain how to use the new segments while analyzing Panda hits.


How To Create Segments in Google Analytics
When you fire up Google Analytics, the “All Sessions” segment is automatically applied to your reporting. So yes, you’ve already been using segments without even knowing it. If you click the “All Sessions” segment, you’ll see a list of additional segments you can choose.

Google Analytics All Sessions Segment

You might be surprised to see a number of segments have been built for you already. They are located in the “System” category (accessed via the left side links). For example, “Direct Traffic”, “AdWords”, “Organic Traffic”, and more.

Google Analytics System Segments


We are going to build custom segments by copying three system segments and then adding more dimensions. We’ll start by creating a custom segment for mobile traffic from Google organic.

1. Access the system segments by clicking “All Sessions” and then clicking the link labeled “System” (located on the left side of the UI).


Google Analytics System Segments


2. Scroll down and find the “Mobile Traffic” segment. To the far right, click the “Actions” dropdown. Then choose “Copy” from the list.


Copying a System Segment in Google Analytics


3. The segment already has “Device Category”, “exactly matches”, and “mobile” as the condition. We are going to add one more condition to the list, which is Google organic traffic. Click the “And” button on the far right. Then choose “Acquisition” and the “Source/Medium” from the dimensions list. Then choose “exactly matches” and select “google/organic” from the list. Note, autocomplete will list the top sources of traffic once you place your cursor in the text box.


Creating a Segment by Adding Conditions


4. Name your segment “Mobile Google Organic” by using the text box labeled “Segment Name” at the top of the window. It’s easy to miss.


Name a Custom Segment in Google Analytics


5. Then click “Save” at the bottom of the create segment window.


Save a Custom Segment in Google Analytics


Congratulations! You just created a custom segment.


Create The Tablet Traffic Segment
Now repeat the process listed above to create a custom segment for tablet traffic from Google organic.  You will begin with the system segment for “Tablet Traffic” and then copy it. Then you will add a condition for Google organic as the source and medium.


Desktop Traffic (Not a default system segment.)
I held off on explaining the “Desktop Traffic” segment, since there’s an additional step in creating one. For whatever reason, there’s not a system segment for isolating desktop traffic. So, you need to create this segment differently. Don’t worry, it’s still easy to do.

We’ll start with the “Mobile Traffic” segment in the “System” list, copy it, and then refine the condition.

1. Click “All Sessions” and the find “Mobile Traffic” in the “System” list. Click “Actions” to the far right and then click “Copy”.


Copying a System Segment in Google Analytics


2. The current condition is set for “Device Category” exactly matching “mobile”. We’ll simply change mobile to “desktop”. Delete “mobile” and start typing “desktop”. Then just select the word “desktop” as it shows up.

Creating a Desktop Segment in Google Analytics


3. Since we want Desktop traffic from Google Organic, we need to add another condition. You can do this by clicking “And” to the far right, selecting “Acquisition”, and then “Source/Medium” from the dropdown. Then select “exactly matches” and enter “Google/Organic” in the text box. Remember, autocomplete will list the top sources of traffic as you start to type.


Creating a Google Organic Desktop Segment in Google Analytics


4. Name your segment “Desktop Google Organic” and then click “Save” at the bottom of the segment window to save your new custom segment.


Quickly Check Your Segments
OK, at this point you should have three new segments for Google organic traffic from desktop, mobile, and tablets. To ensure you have these segments available, click “All Sessions” at the top of your reporting, and click the “Custom” link on the left. Scroll down and make sure you have all three new segments. Remember, you named them “Desktop Google Organic”, “Mobile Google Organic”, and “Tablet Google Organic”.

If you have them, then you’re good to go. If you don’t, read through the instructions again and create all three segments.


Run Panda Reports by Segment
In the past, I’ve explained the importance of running a Panda report in Google Analytics for identifying problematic content. A Panda report isolates landing pages from Google organic that have dropped substantially after a Panda hit. Well, now that you have segments for desktop, mobile, and tablet traffic from Google organic, you can run Panda reports by segment.

For example, click “All Sessions” at the top of your reporting and select “Mobile Google Organic” from the “All” or “Custom” categories. Then visit your “Landing Pages” report under “Behavior” and “Site Content” in the left side menu in GA. Since you have a specific segment active in Google Analytics, the reporting you see will be directly tied to that segment (and filter out any other traffic).

Creating a Google Panda Report Using Custom Segments


Then follow the directions in my previous post to run and export the Panda report. You’ll end up with an Excel spreadsheet highlighting top landing pages from mobile devices that dropped significantly after the Panda hit. Then you can dig deeper to better understand the content quality (or engagement) problems impacting those pages.

Combine with Adjusted Bounce Rate (ABR)
User engagement matters for Panda. I’ve documented that point many times in my previous posts about Panda analysis, remediation, and recovery. The more poor engagement signals you send Google, the more bamboo you are building up. And it’s only a matter of time before Panda comes knocking.

So, when analyzing user engagement, many people jump to the almighty Bounce Rate metric to see what’s going on. But here’s the problem. Standard Bounce Rate is flawed. Someone could spend five minutes reading a webpage on your site, leave, and it’s considered a bounce. But that’s not how Google sees it. That would be considered a “long click” to Google and would be absolutely fine.

And this is where Adjusted Bounce Rate shines. If you aren’t familiar with ABR, then read my post about it (including how to implement it). Basically, Adjusted Bounce Rate takes time on page into account and can give you a much stronger view of actual bounce rate. Once you implement ABR, you can check bounce rates for each of the segments you created earlier (and by landing page). Then you can find high ABR pages by segment (desktop, mobile, and tablet traffic).

Combining Adjusted Bounce Rate with Custom Segments


Check Devices By Segment (Smartphones and Tablets)
In addition to running a Panda report, you can also check the top devices being used by people searching Google and visiting your website. Then you can analyze that data to see if there are specific problems per device. And if it’s a device that’s heavily used by people visiting your site from Google organic, then you could uncover serious problems that might lie undetected by typical audits.

GA’s mobile reporting is great, but the default reporting is not by traffic source. But using your new segments, you could identify top devices by mobile and tablet traffic from Google organic. And that’s exactly what you need to see when analyzing Panda hits.

Analyzing Devices with Custom Segments in Google Analytics

For example, imagine you saw very high bounce rates (or adjusted bounce rates) for ipad users visiting from Google organic. Or maybe your mobile segment reveals very low engagement from Galaxy S5 users. You could then test your site via those specific devices to uncover rendering problems, usability problems, etc.


Summary – Isolate SEO Problems Via Google Analytics Segments
After reading this post, I hope you are ready to jump into Google Analytics to create segments for desktop, mobile, and tablet traffic from Google organic. Once you do, you can analyze all of your reporting through the lens of each segment. And that can enable you to identify potential problems impacting your site from a Panda standpoint. I recommend setting up those segments today and digging into your reporting. You might just find some amazing nuggets of information. Good luck.



Monday, October 27th, 2014

Penguin 3.0 Analysis – Penguin Tremors, Recoveries, Fresh Hits, and Crossing Algorithms

Penguin 3.0 Analysis and Findings

Oct 17, 2014 was an important date for many SEOs, webmasters, and business owners. Penguin, which we’ve been waiting over an entire year for, started to roll out. Google’s Gary Illyes explained at SMX East that Penguin 3.0 was imminent, that it would be a “delight” for webmasters, that it would be a new algorithm, and more. So we all eagerly awaited the arrival of Penguin 3.0.

There were still many questions about the next version of Penguin. For example, why has it taken so long to update Penguin, would there be collateral damage, would it actually have new signals, would it roll out more frequently, and more?  So when we saw the first signs of Penguin rolling out, many of us dug in and began to analyze both recoveries and fresh hits. I had just gotten back from SES Denver, where I was presenting about Panda and Penguin, so the timing was interesting to say the least. :)

Since the algorithm is rolling out slowly, I needed enough time and data to analyze the initial update, and then subsequent tremors. And I’m glad I waited ten days to write a post, since there have been several interesting updates already. Now that we’re ten days into the rollout, and several tremors have occurred, I believe I have enough data to write my first post about Penguin 3.0. And it’s probably the first of several as Penguin continues to roll out globally.

“Mountain View, We Have a Problem”
Based on the long delay of Penguin, it was clear that Google was having issues with the algo. Nobody knows exactly what the problems were, but you can guess that the results during testing were less than optimal. The signature of previous Penguin algorithms has been extremely acute up to now. It targeted spammy inbound links on low quality websites. Compare that to an extremely complex algorithm like Panda, and you can see clear differences…

But Panda is about on-site content, which makes it less susceptible to tampering. Penguin, on the other hand, is about external links. And those links can be manipulated. The more Penguin updates that rolled out, the more data you could gain about its signature. And that can lead to very nasty things happening. For example, launching negative SEO campaigns, adding any website to a host of low quality sites that have been previously impacted by Penguin, etc. All of that can muddy the algorithm waters, which can lead to a lot of collateral damage. I won’t harp on negative SEO in this post, but I wanted to bring it up. I do believe that had a big impact on why Penguin took so long to roll out.

My Goal With This Post
I’m going to quickly provide bullets listing what we know so far about Penguin 3.0 and then jump to my findings based on the first ten days of the rollout. I want to explain what I’ve seen in the Penguin trenches, including recoveries, fresh hits, and other interesting tidbits I’ve seen across my travels. In addition, I want to explain the danger of crossing algorithms, which is going on right now. I’ll explain more about Penguin, Panda, and Pirate all roaming the web at the same time, and the confusion that can cause. Let’s dig in.

Here’s what we know so far about Penguin 3.0:

  • Penguin 3.0 started rolling out on 10/17 and was officially announced on 10/21.
  • It’s a global rollout.
  • It’s a refresh and not an update. New signals have not been added. You can read more about the differences between a refresh and update from Marie Haynes.
  • It will be a slow and steady rollout that can take weeks to complete. More about Penguin tremors soon.
  • There was more international impact initially. Then I saw an uptick in U.S. impact during subsequent Penguin tremors.
  • Google has been very quiet about the update. That’s a little strange given the magnitude of Penguin 3.0, how long we have waited, etc. I cover more about the future of Penguin later in this post.


10 Days In – Several Penguin Tremors Already
We are now ten days into the Penguin 3.0 rollout. Based on the nature of this update, I didn’t want to write a post too quickly. I wanted more data, the ability to track many sites during the rollout in order to gauge the impact, fresh hits, and recoveries. And that’s exactly what I’ve done since early Saturday, October 18. Penguin began rolling out the night before and there’s been a lot of movement since then.

When Penguin first rolled out, it was clear to me that it would be a slow and steady rollout. I said that from the beginning. I knew there was potential for disaster (from Google’s standpoint), so there was no way they would roll out it globally all at one time. Instead, I believed they would start rolling out Penguin, heavily analyze the SERPs, adjust the algo where needed, and then push more updates and expand.  If you’ve been following my writing over the past few years, then you know I call this phenomenon “tremors”. I have seen this often with Panda, and especially since Panda 4.0. Those tremors were even confirmed by Google’s John Mueller.

Specifically with Penguin, I have seen several tremors since the initial rollout on 10/17. There was significant movement on 10/22, and then I saw even more movement on 10/24. Some sites seeing early recovery saw more impact during the subsequent tremors, while other sites saw their first impact from Penguin during those later tremors.

For example, one client I helped with both Panda and Penguin jumped early on Friday 10/24. You can see their trending below. They are up 48% since Friday:

Penguin 3.0 Recovery During Tremor

That’s awesome, and was amazing to see (especially for the business owner). They have worked very hard over the past year to clean up the site on several fronts, including content, links, mobile, etc. It’s great to see that hard work pay off via multiple algorithm updates (they recovered from Panda in May during Panda 4.0 and now during Penguin 3.0.) It’s been a good year for them for sure. :)

Moving forward, I fully expect to see more tremors as the global rollout continues. That can mean sites seeing fresh impact, while others see more movement beyond the first date that Penguin 3.0 impacted their sites. For example, a site may recover or get hit on 10/17, but see movement up or down during subsequent tremors. We’ve already seen this happen and it will continue throughout the rollout.

More Recoveries During Penguin 3.0
For those battling Penguin for a long time (some since Penguin 2.0 on May 22, 2013), this was a much-anticipated update. Some companies I’ve been helping have worked hard over the past 12-18 months to clean up their link profiles. That means nuking unnatural links and using the disavow tool heavily to rid their site of spammy links.

For those of you unfamiliar with link cleanup, the process is tedious, painful, and time consuming. And of course, you can have the nasty replicating links problem, which I have seen many times with spammy directories. That’s when unnatural links replicate across other low quality directories. Websites I’ve been helping with this situation must continually analyze and clean their link profiles. You simply can’t get rid of the problem quickly or easily. It’s a nasty reminder to never go down the spammy linkbuilding path again.

For example, here’s a site that had hundreds of spammy links pop up in the fall of 2014. They had no idea this was going on… 

Penguin 3.0 and New Spammy Links


When sites that have been working hard to rectify their link problems experience a Penguin recovery, it’s an amazing feeling. Some of the sites I’ve been helping have seen a nice bounce-back via Penguin 3.0. I’ll quickly cover two of those recoveries below.

The first is an ecommerce retailer that unfortunately took a dangerous path a few years ago. They hired several SEO companies over a number of years and each ended up building thousands of spammy links. It’s a similar story that’s been seen many times since Penguin first arrived. You know, an SMB trying to compete in a tough space, ends up following the wrong strategy, does well in the short-term, and then gets pummeled by Penguin.

The site was not in good shape when they first contacted me. So we tackled the unnatural link profile head on. I heavily analyzed their link profile, flagged many spammy links, they had a small team working on link removals, and whatever couldn’t be removed was disavowed. We updated the disavow file several times over a four to five month period.

But, and this is a point too many Penguin victims will be familiar with, we were done with link cleanup work in the spring of 2014! Yes, we had done everything we could, but simply needed a Penguin refresh or update. Surely that would happen soon, right?… No way. We had to wait until October 17, 2014 for that to happen. The good news is that this site saw positive impact immediately. You can see the increase in impressions and clicks below starting on 10/17. And Google organic traffic is up 52% since Penguin rolled out.

Penguin 3.0 Recovery on 10/17/14


The next recovery I’ll quickly explain started on 10/17 and saw subsequent increases during the various Penguin tremors I mentioned earlier. They saw distinct movement on 10/17, 10/22, and then 10/25. The site saw a pretty big hit from Penguin 2.0 and then another significant hit from Penguin 2.1 (where Google turned up the dial). The website’s link profile was riddled with exact match anchor text from low quality sites.

The site owner actually removed or nofollowed a good percentage of unnatural links. You can see the impact below. Notice the uptick in trending during the various tremors I mentioned.

Penguin 3.0 Recovery During Tremors


A Reality Check – Some Websites Left Hanging But Rollout Is Not Complete
I must admit, though, I know of several companies that are still waiting for Penguin recovery that should recover during Penguin (to some level). They worked hard just like the companies I listed above. They cleaned up their link profiles, heavily used the disavow tool, worked tirelessly to fix their Penguin problem, but have not seen any impact yet from Penguin 3.0. And many other companies have been complaining about the same thing. But again, Google said the full rollout could take weeks to complete… so it’s entirely possible that they will recover, but at some point over the next few weeks.


A Note About Disavow Errors
It’s worth noting that one client of mine battling Penguin made a huge mistake leading up to Penguin 3.0. They decided to update their disavow file in late September (without my help), and the file contained serious errors. They didn’t catch that upon submission. I ended up noticing something strange in the email from Google Webmaster Tools regarding the number of domains being disavowed. The total number of domains being recorded by GWT was a few hundred less than what was listed in the disavow file prior to the latest submission. And those extra few hundred domains encompass thousands of spammy links. I contacted my client immediately and they rectified the disavow file errors quickly and re-uploaded it.

The website has not recovered yet (although it absolutely should to some level). I have no idea if that disavow glitch threw off Penguin, or if this site is simply waiting for a Penguin tremor to recover. But it’s worth noting.


Fresh Penguin Hits
Now let’s move to the negative side of Penguin 3.0. There have been many fresh hits since 10/17 and I’ve been heavily analyzing those drops. It didn’t take long to see that the same old link tactics were being targeted (similar to previous versions of Penguin). And my research supports that Penguin 3.0 was a refresh and not a new algorithm.

For example, exact match anchor text links from spammy directories, article marketing, comment spam, forum spam, etc. Every fresh hit I analyzed yielded a horrible link profile using these tactics. These were clear Penguin hits… I could tell just by looking at the anchor text distribution that they were in serious Penguin danger.

For example, here’s the anchor text distribution for a site hit by Penguin 3.0. Notice all of the exact match anchor text?

Anchor Text Distribution for Fresh Penguin 3.0 Hit

For those of you new to SEO, this is not what a natural link profile looks like. Typically, there is little exact match anchor text, brand terms show up heavily, urls are used to link to pages, generic phrases, etc. If your top twenty anchor text terms are filled with exact match or rich anchor text, then you are sending “fresh fish” signals to Google. And Google will respond by sending a crew of Penguins your way. The end result will not be pretty.

Hit Penguin 3.0


Crazy Gets Crazier
I must admit that some fresh hits stood out, and not in a good way. For example, I found one site that started its spammy linkbuilding just two days after Penguin 2.1 rolled out in October of 2013! Holy cow… the business owner didn’t waste any time, right? Either they didn’t know about Penguin or they were willing to take a huge risk. Regardless, that site got destroyed by Penguin 3.0.

I could keep showing you fresh hit information, but unfortunately, you would get bored. They all look similar… spammy links from low quality sites using exact match anchor text. Many of the hits I analyzed were Grade-A Penguin food. It’s like the sites lobbed a softball at Penguin, and Google knocked it out of the park.


Next Update & Frequency?
At SMX East, Gary Illyes explained that the new Penguin algorithm was structured in a way where Google could update Penguin more frequently (similar to Panda). All signs point to a refresh with Penguin 3.0, so I’m not sure we’ll see Penguin updating regularly (beyond the rollout). That’s unfortunate, since we waited over one year to see this refresh…

Also, John Mueller was asked during a webmaster hangout if Penguin would update more frequently. He responded that the “holiday season is approaching and they wouldn’t want to make such as fuss”. If that’s the case, then we are looking at January as the earliest date for the next Penguin refresh or update. So, we have a minimum of three to four months before we see a Penguin refresh or update. And it could very well take longer, given Google’s track record with the Penguin algorithm. It wouldn’t shock me to see the next update in the Spring of 2015.

Check John’s comments at 46:45:


Important – The Crossing of Algorithm Updates (Penguin, Panda, and Pirate)
In the past, I have explained the confusion that can occur when Google rolls out multiple algorithm updates around the same time. The algorithm sandwich from April of 2012 is a great example, Google rolled out Panda, Penguin, and then another Panda refresh all within 10 days. It caused massive confusion and some sites were even hit by both algos. I called that “Pandeguin” and wrote about it here.

Well, we are seeing that again right now. Penguin 3.0 rolled out on 10/17, the latest version of Pirate rolled out late last week, and I’m confident we saw a Panda tremor starting late in the day on Friday 10/24. I had several clients dealing with Panda problems see impact late on 10/24 (starting around 5PM ET).

A bad Panda hit starting late on 10/24:

When Panda and Penguin Collide
A big Panda recovery starting at the same time: 

When Panda and Penguin Collide


I can see the Panda impact based on the large amount of Panda data I have access to (across sites, categories, and countries). But the average business owner does not have access to that data. And Google will typically not confirm Panda tremors. So, if webmasters saw impact on Friday (and I’m sure many have), then serious confusion will ensue. Were they hit by Penguin, Panda, or for some sites dealing with previous DMCA issues, was it actually Pirate?

Update: I now have even more data backing a Panda tremor late on 10/24. I had Paul Macnamara and  Michael Vittori explain they are seeing the same thing. They also provided screenshots of trending for both sites. You can see with Michael’s that the site got hit during the 9/5 Panda update, but recovered on Friday. Paul’s screenshot shows a clear uptick on 10/25 on a site impacted by Panda (no Penguin or Pirate impact at all).
Another Panda recovery during the 10/24 tremor.


Another Panda recovery during the 10/24 tremor.

And this underscores a serious problem for the average webmaster. If you work on fixing your site based on the wrong algorithm, they you will undoubtedly spin your SEO wheels. I’ve seen this many times over the years, and spinning wheels do nothing but waste money, time, and resources.

If you saw impact this past week, you need to make sure you know which algorithm update impacted your site. It’s not easy, when three external algos are roaming the web all at one time. But it’s important to analyze your situation, your search history, and determine what you need to do in order to recover.

A Note About Negative SEO
I couldn’t write a post about Penguin 3.0 without mentioning negative SEO. The fear with this latest update was that negative SEO would rear its ugly head. Many thought that the heavy uptick in companies building spammy links to their competitors would cause serious collateral damage.

Theoretically, that can definitely happen (and there are a number of claims of negative SEO since 10/17). Let’s face it, Penguin’s signature is not complicated to break down. So if someone built spammy links to their competitors on sites targeted by Penguin, then those sites could possibly get hit by subsequent Penguin refreshes. Many in the industry (including myself) believe this is one of the reasons it has taken so long for Google to roll out Penguin 3.0. I’m sure internal testing revealed serious collateral damage.

But here’s the problem with negative SEO… it’s very hard to prove that NSEO is the culprit (for most sites). I’ve received many calls since Penguin first rolled out in 2012 with business owners claiming they never set up spammy links that got them hit. But when you dig into the situation, you can often trace the spammy link trail back to someone tied to the company.

That might be a marketing person, agency, SEO company, PR agency, intern, etc.  You can check out my Search Engine Watch column titled Racing Penguin to read a case study of a company that thought negative SEO was at work, when in fact, it was their own PR agency setting up the links. So, although we’ve heard complaints of negative SEO with Penguin 3.0, it’s hard to say if those are accurate claims.

Negative SEO and Penguin 3.0


Penguin 3.0 Impact – What Should You Do Next?

  • If you have been negatively impacted by Penguin 3.0, my advice remains consistent with previous Penguin hits. You need to download all of your inbound links from a number of sources, analyze those links, flag unnatural links, and then remove/disavow them. Then you need to wait for a Penguin refresh or update. That can be months from now, but I would start soon. You never know when the next Penguin update will be…
  • On the flip side, if you have just recovered from a Penguin hit, then you should create a process for checking your links on a monthly basis. Make sure new spammy links are not being built. I have seen spammy links replicate in the past… so it’s important to fully understand your latest links. I wrote a blog post covering how to do this on Search Engine Watch (linked to above). I recommend reading that post and implementing the monthly process.
  • And if you are unsure of which algorithm update impacted your site, then speak with as many people familiar with algo updates as possible. You need to make sure you are targeting the right one with your remediation plan. But as I mentioned earlier, there are three external algos in the wild now (with Penguin, Panda, and Pirate). This inherently brings a level of confusion for webmasters seeing impact.


Summary – Penguin 3.0 and Beyond
That’s what I have for now. Again, I plan to write more posts soon about the impact of Penguin 3.0, the slow and steady rollout, interesting cases that surface, and more. In the meantime, I highly recommend analyzing your reporting heavily over the next few weeks. And that’s especially the case since multiple algos are running at the same time. It’s a crazy situation, and underscores the complexity of today’s SEO environment. So strap on your SEO helmets, grab a bottle of Tylenol, and fire up Google Webmaster Tools. It’s going to be an interesting ride.




Monday, September 29th, 2014

Panda 4.1 Analysis and Findings – Affiliate Marketing, Keyword Stuffing, Security Warnings, and Deception Prevalent

Panda 4.1 Analysis and Findings

On Tuesday, September 23, Google began rolling out a new Panda update. Pierre Far from Google announced the update on Google+ (on Thursday) and explained that some new signals have been added to Panda (based on user and webmaster feedback). The latter point is worth its own blog post, but that’s the not the focus of my post today. Pierre explained that the new Panda update will result in a “greater diversity of high-quality small- and medium-sized sites ranking higher”. He also explained that the new signals will “help Panda identify low-quality content more precisely”.

I first spotted the update late on 9/23 when some companies I have been helping with major Panda 4.0 hits absolutely popped. They had been working hard since May of 2014 on cleaning up their sites from a content quality standpoint, dealing with aggressive ad tactics, boosting credibility on their sites, etc. So it was amazing to see the surge in traffic due to the latest update.

Here are two examples of recovery during Panda 4.1. Both clients have been making significant changes over the past several months:

Panda 4.1 Recovery

Panda 4.1 Recovery Google Webmaster Tools

As a side note, two of my clients made the Searchmetrics winners list, which was released on Friday. :)

A Note About 4.1
If you follow me on Twitter, then you already know that I hate using the 4.1 tag for this update. I do a lot of Panda work and have access to a lot of Panda data. That enables me to see unconfirmed Panda updates (and tremors).  There have been many updates since Panda 4.0, so this is not the only Panda update since May 20, 2014. Not even close actually.

I’ve written heavily about what I called “Panda tremors”, which was confirmed by John Mueller of Google. Also, I’ve done my best to write about subsequent Panda updates I have seen since Panda 4.0 here on my blog and on my Search Engine Watch column. By the way, the latest big update was on 9/5/14, which impacted many sites across the web. I had several clients I’ve been helping with Panda hits recover during the 9/5 update.

My main point here is that 4.1 should be called something else, like 4.75. :) But since Danny Sullivan tagged it as Panda 4.1, and everybody is using that number, then I’ll go with it. The name isn’t that important anyway. The signature of the algo is, and that’s what I’m focused on.


Panda 4.1 Analysis Process
When major updates get rolled out, I tend to dig in full blast and analyze the situation. And that’s exactly what I did with Panda 4.1. There were several angles I took while analyzing P4.1, based on the recoveries and fresh hits I know of (and have been part of).

So, here is the process I used, which can help you understand how and why I came up with the findings detailed in this post.

1. First-Party Known Recoveries
These are recoveries I have been guiding and helping with. They are clients of mine and I know everything that was wrong with their websites, content, ad problems, etc. And I also know how well changes were implemented, if they stuck, how user engagement changed during the recovery work, etc. And of course, I know the exact level of recovery seen during Panda 4.1.

2. Third-Party Known Recoveries
These are sites I know recovered, but I’m not working with directly. Therefore, I use third party tools to help identify increases in rankings, which landing pages jumped in the rankings, etc. Then I would analyze those sites to better understand the current content surging, while also checking the previous drops due to Panda to understand their initial problems.

3. First-Party Known Fresh Hits
Based on the amount of Panda work I do, I often have a number of companies reach out to me with fresh Panda hits. Since these are confirmed Panda hits (large drops in traffic starting when P4.1  rolled out), I can feel confident that I’m reviewing a site that Panda 4.1 targeted. Since Tuesday 9/23, I have analyzed 21 websites (Update: now 42 websites) that have been freshly hit by Panda 4.1. And that number will increase by the end of this week. More companies are reaching out to me with fresh Panda hits… and I’ve been neck deep in bamboo all weekend.

4. Third-Party Unconfirmed Fresh Hits
During my analysis, I often come across other websites in a niche with trending that reveals a fresh Panda hit. Now, third party tools are not always accurate, so I don’t hold as much confidence in those fresh hits.  But digging into them, identifying the lost rankings, the landing pages that were once ranking, the overall quality of the site, etc., I can often identify serious Panda candidates (sites that should have been hit). I have analyzed a number of these third-party unconfirmed fresh hits during my analysis over the past several days.


Panda 4.1 Findings
OK, now that you have a better understanding of how I came up with my findings, let’s dig into actual P4.1 problems. I’ll start with a note about the sinister surge and then jump into the findings. Also, it’s important to understand that not all of the sites were targeted by new signals. There are several factors that can throw off identifying new signals, such as when the sites were started, how the sites have changed over time, how deep in the gray area of Panda they were, etc. But the factors listed below are important to understand, and avoid. Let’s jump in.


Sinister Surge Reared Its Ugly Head
Last year I wrote a post on Search Engine Watch detailing the sinister surge in traffic prior to an algorithm hit. I saw that phenomenon so many times since February of 2011 that I wanted to make sure webmasters understood this strange, but deadly situation. After I wrote that post, I had many people contact me explaining they have seen the exact same thing. So yes, the surge is real, it’s sinister, and it’s something I saw often during my latest analysis of Panda 4.1.

By the way, the surge is sinister since most webmasters think they are surging in Google for the right reasons, when in fact, Google is dishing out more traffic to problematic content and gaining a stronger feel for user engagement. And if you have user engagement problems, then you are essentially feeding the mighty Panda “Grade-A” bamboo. It’s not long after the surge begins that the wave crashes and traffic plummets.

Understanding the surge now isn’t something that can help Panda 4.1 victims (since they have already been hit). But this can help anyone out there that sees the surge and wonders why it is happening. If you question content quality on your website, your ad situation, user engagement, etc., and you see the surge, deal with it immediately. Have an audit completed, check your landing pages from Google organic, your adjusted bounce, rate, etc. Make sure users are happy. If they aren’t, then Panda will pay you a visit. And it won’t be a pleasant experience.

The Sinister Surge Before Panda Strikes


Affiliate Marketers Crushed
I analyzed a number of affiliate websites that got destroyed during Panda 4.1. Now, I’ve seen affiliate marketers get pummeled for a long time based on previous Panda updates, so it’s interesting that some affiliate sites that have been around for a while just got hit by Panda 4.1. Some sites I analyzed have been around since 2012 and just got hit now.

For example, there were sites with very thin content ranking for competitive keywords while their primary purpose was driving users to partner websites (like Amazon and other ecommerce sites). The landing pages only held a small paragraph up top and then listed affiliate links to Amazon (or other partner websites). Many of the pages did not contain useful information and it was clear that the sites were gateways to other sites where you could actually buy the products. I’ve seen Google cut out the middleman a thousand times since February of 2011 when Panda first rolled out, and it seems Panda 4.1 upped the aggressiveness on affiliates.

I also saw affiliate sites that had pages ranking for target keywords, but when you visited those pages the top affiliate links were listed first, pushing down the actual content that users were searching for. So when you are looking for A, but hit a page containing D, E, F, and G, with A being way down the page, you probably won’t be very happy. Clearly, the webmaster was trying to make as much money as possible by getting users to click through the affiliate links. Affiliate problems plus deception is a killer combination. More about deception later in the post.

Panda 4.1 and Affiliate Marketing

Affiliates with Blank and/or Broken Pages
I came across sites with top landing pages from Google organic that were broken or blank. Talk about a double whammy… the sites were at risk already with pure affiliate content. But driving users to an affiliate site with pages that don’t render or break is a risky proposition for sure. I can tell you with almost 100% certainty that users were quickly bouncing back to the search results after hitting these sites. And I’ve mentioned many times before how low dwell time is a giant invitation to the mighty Panda.

Blank Affiliate Pages and Panda 4.1

Doorway Pages + Affiliate Are Even Worse
I also analyzed several sites hit by Panda 4.1 that held many doorway pages (thin pages over-optimized for target keywords). And once you hit those pages, there were affiliate links weaved throughout the content. So there were two problems here. First, you had over-optimized pages, which can get you hit. Second, you had low-quality affiliate pages that jumped users to partner websites to take action. That recipe clearly caused the sites in question to get hammered.  More about over-optimization next.


Keyword Stuffing and Doorway Pages
There seemed to be a serious uptick in sites employing keyword stuffing hit by Panda 4.1. Some pages were completely overloaded in the title tag, metadata, and in the body of the page. In addition, I saw several examples of sites using local doorway pages completely over-optimized and keyword stuffed.

For example, using {city} + {target keyword} + {city} + {second target keyword} + {city} + {third target keyword} in the title. And then using those keywords heavily throughout the page.

And many of the pages did not contain high quality content. Instead, they were typically thin without useful information. Actually, some contained just an image with no copy. And then there were pages with the duplicate content, just targeted to a different geographic location.

The websites I analyzed were poorly-written, hard to read through, and most people would probably laugh off the page as being written for search engines. I know I did. The days of stuffing pages and metadata with target keywords are long gone. And it’s interesting to see Panda 4.1 target a number of sites employing this tactic.

Panda 4.1 and Keyword Stuffing

Panda 4.1 and Keyword Density

Side Note About Human Beings:
It’s worth reiterating something I often tell Panda victims I’m helping. Actually, I just mentioned this in my latest Search Engine Watch column (which coincidentally went live the day after P4.1 rolled out!) Have neutral third parties go through your website and provide feedback. Most business owners are too close to their own sites, content, ad setup, etc. Real people can provide real feedback, and that input could save your site from a future panda hit.

I analyzed several sites hit by Panda 4.1 with serious ad problems. For example floating ads throughout the content, not organized in any way, blending ads with content in a way where it was hard to decipher what was an ad and what was content, etc.

I mentioned deception in the past, especially when referring to Panda 4.0, but I saw this again during 4.1. If you are running ads heavily on your site, then you absolutely need to make sure there is clear distinction between content and ads. If you are blending them so closely that users mistakenly click ads thinking it was content, then you are playing Russian roulette with Panda.

Panda 4.1 and Deception

Users hate being deceived, and it can lead to them bouncing off the site, reporting your site to organizations focused on security, or to Google itself. They can also publicly complain to others via social networks, blogging, etc. And by the way, Google can often pick that up too (if those reviews and complaints are public.) And if that happens, then you can absolutely get destroyed by Panda. I’ve seen it many times over the years, while seeing it more and more since Panda 4.0.

Deception is bad. Do the right thing. Panda is always watching.


Content Farms Revisited
I can’t believe I came across this in 2014, but I did. I saw several sites that were essentially content farms that got hammered during Panda 4.1. They were packed with many (and sometimes ridiculous) how-to articles. I think many people in digital marketing understand that Panda was first created to target sites like this, so it’s hard to believe that people would go and create more… years after many of those sites had been destroyed. But that’s what I saw!

To add to the problems, the sites contained a barebones design, they were unorganized, weaved ads and affiliates links throughout the content, etc. Some even copied how-to articles (or just the steps) from other prominent websites.

Now, to be fair to Google, several of the sites were started in 2014, so Google needed some time to better understand user engagement, the content, ad situation, etc. But here’s the crazy thing. Two of those sites surged with Panda 4.0. My reaction: “Whhaatt??” Yes, the sites benefitted somehow during the massive May 20 update. That’s a little embarrassing for Google, since it’s clearly not what they are trying to rise in the rankings…

Incorrect Panda 4.0 Surge

But that was temporary, as Panda 4.1 took care of the sites (although late in my opinion). So, if you are thinking about creating a site packed with ridiculous how-to articles, think again. And it goes without saying that you shouldn’t copy content from other websites. The combination will surely get you hit by Panda. I just hope Google is quicker next time with the punishment.

Security Warnings, Popup Ads, and Forced Downloads
There were several sites I analyzed that had been flagged by various security and trust systems. For example, several sites were flagged as providing adware, spyware, or containing viruses. I also saw several of the sites using egregious popups when first hitting the site, forcing  downloads, etc.

And when Panda focuses on user engagement, launching aggressive popups and forcing downloads is like hanging fresh bamboo in the center of your websites and ringing the Panda dinner bell. Users hate popups, especially when it’s the first impression of your site. Second, they are fearful of any downloads, let alone ones you are forcing them to execute. And third, security messages in firefox, chrome, antivirus applications, WOT, etc. are not going to help matters.

Trust and credibility are important factors for avoiding Panda hits. Cross the line and you can send strong signals to Google that users are unhappy with your site. And bad things typically ensue.

Panda 4.1 Security Problems

Next Steps:
Needless to say, Panda 4.1 was a big update and many sites were impacted. Just like Panda 4.0, I’ve seen some incredible recoveries during 4.1, while also seeing some horrible fresh hits. Some of my clients saw near-full recoveries, while other sites pushing the limits of spamming got destroyed (dropping by 70%+).

I have included some final bullets below for those impacted by P4.1. My hope is that victims can begin the recovery process, while those seeing recovery can make sure the surge in traffic remains.

  • If you have been hit by Panda 4.1, then run a Panda report to identify top content that was negatively impacted. Analyzing that content can often reveal glaring problems.
  • Have an audit conducted. They are worth their weight in gold. Some webmasters are too close to their own content to objectively identify problems that need to be fixed.
  • Have real people go through your website and provide real feedback. Don’t accept sugarcoated feedback. It won’t help.
  • If you have recovered, make sure the surge in traffic remains. Follow the steps listed in my latest Search Engine Watch column to make sure you aren’t feeding Google the same (or similar) problems that got you hit in the first place.
  • Understand that Panda recovery takes time. You need to first make changes, then Google needs to recrawl those changes (over time), and then Google needs to be measure user engagement again. This can take months. Be patient.
  • Understand that there isn’t a silver Panda bullet. I usually find a number of problems contributing to Panda attacks during my audits. Think holistically about user engagement and then factor in the various problems surfaced during an audit.
  • Last, but most importantly, understand that Panda is about user happiness. Make sure user engagement is strong, users are happy with your content, and they don’t have a poor experience while traversing your website. Don’t deceive them, don’t trick them into clicking ads, and make a great first impression. If you don’t, those users can direct their feedback to Panda. And he can be a tough dude to deal with.


Summary – Panda 4.1 Reinforces That Users Rule
So there you have it. Findings based on analyzing a number of websites impacted by Panda 4.1. I will try and post more information as I get deeper into Panda 4.1 recovery work. Similar to other major algorithm updates, I’m confident we’ll see Panda tremors soon, which will bring recoveries, temporary recoveries, and more hits. Strap on your SEO helmets. It’s going to be an interesting ride.



Wednesday, September 17th, 2014

How To Check If Google Analytics Is Firing On Android Devices Using Remote Debugging With Chrome [Tutorial]

How To Debug Google Analytics on Mobile Devices

We all know that having a strong analytics setup is important. Marketing without measurement is a risky proposition for sure. But in a multi-device world, it’s not as easy to make sure your setup is accurately tracking what you need – or tracking at all. And if your analytics code isn’t firing properly across smartphones, tablets, and desktop computers, your data will be messy, incomplete, and inaccurate. And there’s nothing that drives a marketer crazier than flawed data.

A few weeks ago, Annie Cushing tweeted a quick question to her followers asking how everyone was testing their Google Analytics setup via mobile devices. This is something many digital marketers grapple with, especially when you are trying to track down problems. For example, I do a lot of algorithm update work and often dig into the analytics setup for a site to ensure we are seeing the full drop in traffic, conversion, revenue, etc.

My knee-jerk response was to check real-time reporting in Google Analytics while accessing specific pages to ensure those visits were being tracked, in addition to events. That could work, but it’s not as granular or isolated as you would want. I also mentioned to Annie that using a chrome extension like User Agent Switcher could help. That wouldn’t document the firing of analytics code, but would let you see the source code when accessing a webpage via a specific type of smartphone or tablet. But again, you couldn’t see the actual firing of the code or the events being tracked. And that’s obviously an important aspect to debugging analytics problems.

A Solution – Remote Debugging on Android with Chrome
So I did what I typically do when I run into a tricky situation. I find a solution! And for Android devices, I found a solid one. Many of you might be familiar with Chrome Developer Tools (on your desktop computer). It holds some outstanding functionality for debugging websites and web applications. But although it’s extremely helpful for debugging desktop webpages, it didn’t really address the problem at hand (out of the box), since we want to debug mobile devices.

So I started to research the issue and that’s when I came across a nifty technique which would allow you to connect your Android device to your desktop computer and then debug the Chrome tabs running on your mobile device from your desktop computer. And since I could use Chrome Developer Tools to debug the tabs on my desktop computer, I could check to see if Google Analytics was indeed firing when accessing webpages via my Android device. Awesome.

So, I spent some time testing this out and it does work. Sure, I had to jump through some hoops to get it to run properly, but it finally did work. Below I’ll cover what you’ll need to test this out for yourself and how to overcome some of the problems I encountered. Let’s get started.


What You’ll Need
In order to debug GA code running on your mobile device, you’ll need the proper setup both on your desktop computer and on your Android device. In its simplest form, you’ll need:

  • Chrome installed on your desktop (version 32 or later).
  • Android 4.0 or later.
  • A USB Cable to connect your device to your computer.
  • Android SDK {this will not be required for some of you, but others might need to install it. More on that situation below}.

If you run into the problems I ran into, you’ll need the Android SDK installed. I already had it installed since I’ve been testing various Android functionality and code, so it wasn’t a big deal. But you might need to install it on your own. I wouldn’t run to do that just yet, though. If the straight setup works for you, then run with it. If not, then you might need to install the Android SDK.

If you are confident you have the necessary setup listed above, then you can move to the tutorial listed below. I’ll walk you through how to debug Chrome tabs running on your mobile device via Chrome on your desktop computer. And yes, we’ll be isolating Google Analytics code firing on our Android devices to ensure you are tracking what you need.

How To Debug Google Analytics on Your Android Device – Step-By-Step Instructions

  1. Enable USB Debugging on Your Android Device
    Access your settings on your Android device and click Developer Options. On my device, that was located in the more “More” grouping of my settings and under System Manager. If you don’t see Developer Options, then you need to enable it.You can do that by accessing Settings, tapping About Phone or About Device and tapping Build Number seven times. Yes, that sounds extremely cryptic, but that’s what you need to do. Once you do, Developer Options will show up in under System Manager in your phone’s settings.

    Enable USB Debugging on Android Device

    Then you can check the box to enable USB Debugging on your device. You will need to do this in order to debug Google Analytics in Chrome on your device.

  2. Enable USB Discovery in Chrome (on your desktop)
    Next, type chrome:inspect in a new tab in Chrome on your desktop. Ensure “Discover USB devices” is checked on this screen.

    Enable USB Discovery in Chrome Desktop
  3. Connect Your Phone To Your Computer via USB
  4. Allow USB Debugging
    When you connect your phone to your computer, you should see a dialog box on your phone that asks you if you want to allow USB debugging. Click OK. Note, if you don’t see this dialog box, debugging your mobile device from Chrome on your desktop will not work. I provide instructions for getting around this problem later in the tutorial. If you are experiencing this problem, hop down to that section now.

    Allow USB Debugging on Android Device
  5. Fire up Chrome On Your Mobile Device
    Start Chrome on your Android device and access a webpage (any webpage you want to debug).
  6. Inspect With Chrome on your Desktop
    Once you open a webpage in Chrome on your mobile device, access Chrome on your desktop and visit chrome:inspect. Once you do, you should see your device listed and the various tabs that are open in Chrome on your Android device.

    Inspect Chrome Tabs on Desktop Computer
  7. Click Inspect To Debug The Mobile Tab
    When you click “inspect”, you can use Chrome Developer Tools on your desktop to debug the mobile web view. You can use all of the functionality in Chrome Developer Tools to debug the webpage open on your mobile device.
  8. Click the Network Tab in Chrome Developer Tools
    By accessing the Network Tab, you can view all network activity based on the webpage you have loaded in Chrome on your mobile device. That includes any resources that are requested by the webpage. Then reload the webpage on your mobile device to ensure you are seeing all resources.
  9. First Check for GA.js
    When you load a webpage on your mobile device, many resources will be listed in the network tab. But you should look for ga.js to see if the Google Analytics snippet is being loaded.Tip: You can use the search box and enter “ga.js” to filter all resources by that string. It’s an easy way to isolate what you are looking for.

    Check for ga.js in Network Tab in Developer Tools
  10. Next Check for utm.gif
    After checking for ga.js, you should look for the tracking pixel that’s sent to GA named utm.gif. If that is listed in the network panel, then your mobile webpage is tracking properly (at least basic tracking). Again, you can use the search box to filter by utm.gif.

    Check for utm.gif in Network Tab in Developer Tools
  11. Bonus: Advanced Tracking
    If you are firing events from mobile webpages, then you can see them listed here as well. For example, you can see an event being fired when a user stays on the page for more than 30 seconds below. So for this situation, we know that pageviews are accurately being tracked and the time on page event is being tracked via mobile. Nice.

    Check event tracking in Chrome for Android


A Note About Troubleshooting
I mentioned earlier that if you don’t see the “Allow USB Debugging” dialog on your mobile device when you connect your phone to your computer, then this setup won’t work for you. It didn’t initially work for me. After doing some digging around, I found the legacy workflow for remote debugging on Android.

By following the steps listed below, I finally got the prompt to show up on my mobile device. Then I was able to debug open Chrome tabs on my Android device.


  1. Install the Android SDK (if you don’t already have it installed)
    You can learn more about the SDK here and download the necessary files.
  2. Kill the ADB Server
    Use a command prompt to access the “platform-tools” folder in the SDK directory and then issue the following command: adb kill-server. Note, you should use the cd command to change directory to the folder containing adb. That’s the platform-tools folder in your Android SDK directory.

    Kill ADB Server
  3. Revoke USB Debugging on Your Android Device
    Disconnect your phone from your computer. Then go back to Developer Options on your Android phone and tap Revoke USB debugging authorization.

    Revoke USB Debugging
  4. Start the ADB Server
    Now you must restart the adb server. Use a command prompt, access the platform-tools folder again, and enter the following command: adb start-server.

    Start ADB Server
  5. Reconnect Your Device To Your Computer
    Once you reconnect your device, you should see the “Allow USB Debugging” dialog box. Click “OK” and you should be good to go. This will enable you to debug Chrome tabs running on your mobile device via Chrome running on your desktop.
  6. Open Chrome on Your Android Device
    Go ahead and open a webpage that you want to debug in Chrome on your Android phone. Once it’s loaded in Chrome in Android, you can follow the instructions listed earlier for using the network panel to debug the GA setup.


Summary – Know When Google Analytics is Firing on Mobile Devices
So there you have it. There is a way to debug the actual firing of GA code on your Android devices and it works well. Sure, you may need to go the extra mile, use the legacy workflow, and install the Android SDK, but you should be able to get it working. And once you do, you’ll never have to guess if GA is really working on Android devices. You’ll know if it is by debugging your Chrome tabs on Android via Chrome running on your desktop. Good luck.




Tuesday, September 9th, 2014

Panda Update on Friday September 5, 2014

Panda Update on 9/5/14

My last blog post explained that Panda is now running in near-real-time and what that means for webmasters and business owners. Well, that was perfect timing as Panda just made another trip around the web as kids head back to school and the NFL kicks in.

I’ve seen multiple Panda clients see recovery starting on Friday 9/5. And some of the clients had been seriously impacted by our cute, black and white friend in the past. Two sites, in particular, saw drops of 60%+ from previous Panda updates.

Here are a few screenshots from companies seeing impact from the 9/5/14 Panda update:

Panda Recovery on 9/5/14


Another Panda Recovery on 9/5/14


Panda is Starting The School Year Out Right
Teachers always say that hard work can lead to success. And it seems the schoolyard Panda feels the same way. The clients seeing the biggest spikes in traffic have done a lot of hard work Panda-wise.

Over the past few months, massive Panda problems were uncovered from a content quality standpoint. That included finding thin content, duplicate content, low-quality content, scraped content, while also identifying ad problems and technical  problems that were impacting content quality and user engagement.

The user experience across each site was poor to say the least and the changes they have made (and are actively implementing) are improving the overall quality of their websites. And that’s exactly what you need to do in order to see positive Panda movement.

A Note About Temporary Recoveries (or Tests)
I recently wrote a post about temporary Panda recoveries, which I have seen several of over the past month or so.  It’s interesting to note that two sites that just bounced back had seen temporary Panda recoveries in the past month. Now, we don’t know if they were truly temporary recoveries or simply tests of a future Panda update that ended up getting rolled back. But since Friday 9/5, both of those sites have spiked again. Let’s hope these recoveries stick.

Temporary Panda Recovery


Beyond temporary recoveries, other websites battling Panda saw serious spikes in Google organic traffic starting on Friday 9/5. And like I said earlier, they had gotten hammered by Panda in the past. It’s awesome to see them bounce back.

For example, one site is up 85% and another is up 71%. Nice increases to say the least.

Panda Recovery Percentage in GA


Summary – Everybody’s Working for the Weekend (Including Panda)
As I explained earlier, Panda is now near-real-time and the days of waiting for monthly Panda updates are gone. The fact of the matter is that you can see impact at any point during the month (or even multiple times per month). So, if you’ve been impacted by Panda in the past, then check your reporting now. Friday might have been a very good day for you. And on the flip side (for those facing the Panda music for the first time), you might see a frightening drop in Google organic traffic. One thing is for sure… with the mighty Panda roaming the web in near-real-time, it’s never been more important to keep a close eye on content quality. Panda sure is.

So get ready for the next update. I’m confident it’s not far away. Actually, it might be just around the corner.




Tuesday, September 2nd, 2014

Google Panda Running Regularly Since P4.0, Approaches Near-Real-Time

Google Panda Running Regularly

In June of 2013 I wrote about the maturing of Google’s Panda algorithm and how it started to roll out monthly over a ten day period. Google also explained at that time that they wouldn’t be confirming future Panda updates. In my post, I explained how the combination of monthly updates, over ten days, with no confirmation, could lead to serious webmaster confusion. Getting hit by Panda was already confusing enough for webmasters (when they knew it was Panda). Now sites could get hit during a ten day period, any month, without confirmation from Google about what hit them.

So the monthly updates went on, I picked up a number of them, and yes, it was confusing for many. I received plenty of emails from business owners wondering why they experienced drops during those unconfirmed updates. In case you’re wondering, I could pick up those unconfirmed updates since I help a lot of companies with Panda and I have access to a lot of Panda data. More about that soon. But the average webmaster could not easily pick up those updates, which led to serious confusion and frustration. And that’s the situation we were in until May of 2014.

And Along Came Panda 4.0
This went on until Panda 4.0, which was a huge update released on May 20, 2014. Google did announce the update for several reasons. First, it was a new Panda algorithm. Second, they knew it was HUGE and would impact many websites (and some aggressively).

Everything about the update was big. There were huge recoveries and massive new hits. You can read my previous posts about Panda 4.0 to learn more about the update. But that’s not the focus of this post. Something else has been going on since Panda 4.0, and it’s critically important to understand.

After Panda 4.0 rolled out on May 20, 2014, I noticed that sites impacted by the algorithm update were seeing continual “tremors”. Sites that were hit were seeing more drops every week or so and sites that experienced recovery also saw tremors during those dates (slight increases during those intervals). Moving forward, I also started to see sites reverse direction during some of the tremors. Some that saw recovery saw slight decreases and others that were hit saw slight increases. It was fascinating to analyze.

I reached out to Google’s John Mueller via G+ to see if he could shed some light on the situation. Well, he did, and I documented his response in my Search Engine Watch column soon after. John explained that Google doesn’t have a fixed schedule for algorithm updates like Panda. They could definitely tweak the algo to get the desired results and roll it out more frequently. That was big news, and confirmed the tremors I was seeing.

Google's John Mueller Clarifies Panda Tremors

John also explained more about Panda in a recent Google Webmaster Office Hours Hangout (from August 15, 2014).Here’s a quote from John:

“I believe Panda is a lot more regular now, so that’s probably happening fairly regularly.”

And based on what I’ve been seeing across websites impacted by Panda, he’s not kidding. You can see the video below (starting at 21:40).

Since Panda 4.0, I’ve seen tremors almost weekly. And guess what? They really haven’t stopped. So it seems they aren’t temporary adjustments to Panda, but instead, this could be the new way that Panda roams the web. Yes, that would mean we are in the age of a near-real-time Panda. And that can be both amazing and horrifying for webmasters.


What I’ve Seen Since Panda 4.0
I mentioned that I have access to a lot of Panda data. That’s because I’ve helped a lot of companies with Panda since February of 2011, while also having new companies reach out to me about fresh Panda hits. This enables me to see recoveries with companies that are working hard to rectify content quality problems, while also seeing new Panda hits. This combination enables me to document serious Panda activity on certain dates.

Since Panda 4.0 rolled out, I have consistently seen tremors (almost weekly). I have seen companies continue to increase, continue to decrease, fluctuate up and down, and I have also documented temporary recoveries. Below, I’ll show you what some of the tremors look like and then I’ll explain what this all means.

Panda Tremors – Example
Example of Panda Tremors


Panda Tremors – Example
Second Example of Panda Tremors


Temporary Panda Recovery During Tremors
Temporary Panda Recovery During Tremors


Another Temporary Panda Recovery During Tremors
Example of Temporary Panda Recovery During Tremor


Fresh Bamboo and The Near-Real-Time Panda Algo
So, what does this all mean for webmasters and business owners? Well, it means that Panda is rolling out often, and sites can be impacted more frequently than before. That’s huge news for any webmaster dealing with a Panda problem. In the past, you would have to wait for a monthly Panda update to run before you could see recovery (or further decline). Now you can see impact much more frequently. Again, this is big.

That’s why I have seen sites fluctuate almost weekly since Panda 4.0. Some have stabilized, while others continue to dance with the mighty Panda. And the temporary recoveries emphasize an important point. If you haven’t completed enough Panda recovery work, you might see what looks to be recovery, only to get hammered again (and quickly). It’s one of the reasons I explain to Panda victims that they need to move quickly and implement serious changes based on a thorough Panda audit. If not, they are setting themselves up to continually see declines, or worse, see a misleading temporary recovery, only to get smoked again.

Summary – The Good and the Bad of The Near-Real-Time Panda
As I explained above, it looks like a new phase of Panda has begun. As someone neck deep in Panda work, it’s fascinating to analyze. With the mighty Panda roaming the web in near-real-time, websites can see ups and downs throughout the month. They can get hit, or recover, or even see both in one month. That’s why it’s never been more important to address content quality problems on your website. As always, my recommendation is to focus on user engagement, nuke thin and low quality content, remove deceptive tactics, and win the Panda game.

Let’s face it, Panda has upped its game. Have you?



Wednesday, August 13th, 2014

Affiliate Marketer Attacked by Panda 4.0 Sees Temporary Recovery, Gets Hit Again 5 Days Later [Case Study]

Panda Temporary Recovery Case Study

Panda 4.0 arrived in late May with a fury not seen by many previous updates. It was a HUGE update and many sites were decimated by P4.0. Most businesses reaching out to me after the May 20 update saw drops of 50%+, with some losing 80% of their Google organic search traffic overnight. And on the flip side, recoveries were strong too. There were some companies I was helping with past Panda attacks that saw increases of 200%+, with some seeing over 400% increases. Like I said, everything about Panda 4.0 was big.

Panda Games – The Rundown
A few weeks ago, I was analyzing a Panda tremor and saw some very interesting movement across sites I have been helping. More to come on that front, but that’s not the focus of this post today. That same day, a business owner reached out to me explaining that he saw serious fluctuations on a site of his that was crushed by Panda 4.0. Needless to say between what I was seeing, and what he had just explained, I was interested for sure.

So I asked how much of a recovery he saw during the latest Panda tremor, and what I heard shocked me – “Close to a full recovery.”  Whoa, not many have recovered from Panda 4.0 yet, so now he had my attention. Since my schedule has been insane, I didn’t have time to dig in too much at that point. I was planning to, but just couldn’t during that timeframe.

But then I heard back from the business owner the following week. I was at the Jersey Shore on vacation when a giant wave crashed at my feet (both literally and figuratively).  The business owner’s email read, “FYI, I just lost all of the gains from the recovery last week”.  Once again, my reaction was “Whoa…” :)

So to quickly recap what happened, a site that got crushed by Panda 4.0 ended up recovering during a Panda tremor (in late July), only to get hammered again five days later. By the way, it was a near-full recovery during the five day stint (regaining 75% of its Google organic search traffic). In addition, I’ve been analyzing other Panda 4.0 sites that were impacted during the late July 2014 update (which I plan to cover in future blog posts).  It was big tremor.

Quick Note About Temporary Recoveries:
It’s worth noting that I have seen other Panda victims see increases in Google organic traffic during the recovery phase (almost like the site is being tested). I’ve seen this during Panda work since 2011. I’ll explain more about that phenomenon soon, but I wanted to bring it up now since this site did see a temporary recovery.

Digging In
If you know me at all, you know what came next. I fired up my Keurig and dug into the site. With a cup of Jet Fuel and Black Tiger in me, I wanted to know all I could about this interesting Panda 4.0 case study. In this post, I’ll explain more about the temporary recovery, the factors that led to the Panda hit, why I think the site saw a temporary recovery, and end with some key learnings that are important for any business owners dealing with Panda 4.0 attacks to understand.  Let’s go.

Panda Factors
Although I want to focus on the temporary recovery, let’s quickly cover the initial Panda 4.0 hit. The site is small, containing less than 60 pages indexed. It’s a site covering an extremely focused niche and it’s a partial match domain (PMD). After analyzing the site, here are what I believe to be the core factors that led to the Panda hit.

Heavy Affiliate Content:
Looking through the history of the site reveals an increase of content in 2013 and much of the site content became affiliate-driven. The site was heavily linking to Amazon.com for products tied to the niche (and some were followed affiliate links). So there was a lot of traffic arriving on the site that was quickly going out. That’s never a good situation from a Panda-standpoint. Also, the other content funneled visits to the affiliate pages where the site could have a greater chance at converting those visits into potential sales down the line. And of course, you have followed affiliate links, which should be nofollowed.

I can’t tell you how many affiliate marketers have reached out to me after getting smoked by Panda since February of 2011. If you aren’t providing a serious value-add, then there’s a strong chance of getting crushed. I’ve seen it a thousand times. That’s a nice segue to the next factor – engagement.

Low Engagement, High Bounce Rates
I’ve mentioned many times in Panda blog posts the importance of strong engagement. Google has several ways to measure user engagement, but one of the easiest ways is via dwell time. If someone clicks through a search result on Google, visits a page, and quickly clicks back to the search results, that’s a pretty clear signal that the user didn’t find what they wanted (or that they didn’t have a positive user experience). Low dwell time is a giant invitation to the mighty Panda.

Checking standard bounce rates for top landing pages leading up to the Panda attack revealed extremely high percentages. Many of the pages had 90% or higher bounce rates. I wish the site had implemented Adjusted Bounce Rate (ABR), but it didn’t. ABR is a much stronger view of actual bounce rate that takes time on page into account. That said, many top landing pages with 90%+ bounce rates is not good.

High Bounce Rates Before Panda Struck

No Frills Design, Broken HTML
The site itself did not help build credibility. It was a basic WordPress design with little credibility-building factors. There weren’t clear signs of who ran the site, which company owned the site, etc. It was basically a shell WordPress site that you’ve seen a million times. The “About” page was just a paragraph and doesn’t inform the user about who was actually writing the content, who was behind the site, etc. By the way, I find about pages like that to make matters worse, not better.

In addition, there were several pages with broken html, where some html was showing up on the page itself (like html tags).

Broken HTML and Design and Google Panda

When you are trying to drive strong engagement, trust definitely matters. The less people trust the site and the company behind the content, the less chance you have of retaining them. And again, the more users that jump back to the search results, the more virtual bamboo you are piling up.

Deceptive Ads (Cloaked)
During my analysis, I found ads throughout the content that were very similar in style and design to the content itself. So, it was easy to think the ads were the actual content, which could trick users into clicking the ads. I’ve seen this a number of times while analyzing Panda attacks (and especially Panda 4.0.) In addition, this is even called out in the latest version of the Quality Grader Guidelines.

Deceptive Ads and Panda

I’ve found deception to be an important factor in recent Panda hits, so ads that are cloaked as content can be extremely problematic. Remember, SEOs and digital marketers might pick them up pretty quickly, but we’re not the majority of users browsing the web. Think about what the average person would do if they found those ads… Many would have no idea they were ads and not content. And they sure wouldn’t be happy landing on some advertiser’s website after clicking them.

Mixed throughout the content were many exact match anchor text links (EMATs), either pointing to the affiliate pages mentioned before or to off-site authority sites.  For example, a typical landing page would link heavily to the Amazon pages, but also to Wikipedia pages. I’ve seen this tactic used in the past as well with other Panda and Phantom victims (and I’ve even seen this during Penguin analysis).

Typically, the thought process is that if Google sees a site linking to authority sites, then it might trust that site more (the linking site). But it also creates a pattern that’s easy to pick up. It’s not natural to continually link to Wikipedia from many places on your site, and Google’s algorithms can probably pick up the trend when it takes all outbound links into account. And that many of the links are exact match anchor text doesn’t help (since the links throughout the pages tended to look over-optimized and somewhat spammy).

Authorship Backfiring
While analyzing the site, I noticed many of the top landing pages had authorship implemented. But when checking out the author, I got a feeling he wasn’t real. Sure, there was a G+ profile set up, and even other social accounts, but something didn’t feel right about the author.

And using reverse image lookup in Google images, I pulled up the same photo being used elsewhere on the web. In addition, it looked like a stock photo. The one used on the site I was analyzing was cropped to throw off the look (which helped make it look more unique).

So, if I had questions about the author, you better believe Google must have too. And add questionable authorship to the other factors listed above, and you can see how the credibility factor for this site was pushing it into the gray area of Panda. The author in the photo might as well been holding a piece of bamboo.

The Surge, The Hit, The Temporary Recovery, and Subsequent Hit
Below, I’ll quickly detail what happened as the site experienced a roller coaster ride across the giant Panda coaster.

Index status revealed a doubling of pages indexed leading into 2014. My guess is that more content was added to cast a wider net from an affiliate marketing standpoint. And again, many of those pages had affiliate links to Amazon to buy various products. That new content worked (in the short-term). Google organic traffic increased nicely on the site.

Then the site experienced the misleading and sinister surge that I wrote about in my Search Engine Watch column. In March of 2014, the site spiked in Google. Many different keywords related to the niche were driving traffic to the site. But unfortunately, that traffic was all leading to the problems I mentioned earlier.

Surge of Traffic Before Panda Attack

The surge I mentioned enables Google to gain a lot of engagement data from real users. And if you have content quality problems, usability problems, ad problems, etc., then you are feeding Panda a lot of bamboo. And that can easily lead to a Panda attack.

And that’s what happened during Panda 4.0. The wave crashed and the site lost 86% of its Google organic traffic overnight. Yes, 86%. Many of the keywords that the site picked up during the surge were lost during Panda 4.0. The landing pages that were once driving a boatload of organic search traffic dropped off a cliff visits-wise. One page in particular dropped by 96% when you compared post-Panda to pre-Panda (with 30 days of data). That’s a serious hit and speaks volumes about how Google was viewing the website.

Interesting Note – Money Term Untouched
While analyzing the keywords that dropped, it was interesting to see that the site’s money keyword was not impacted at all during Panda 4.0 (or even the second hit which I’ll cover shortly). That keyword, which is also in the domain name, stayed as-is. It’s hard to say why that was the case, but it was. Checking trending throughout the roller coaster ride reveals steady impressions, clicks, and average position.

Money Keyword Unaffected by Panda

July 22, 2014 – The Temporary Recovery
Then along came Tuesday, July 22. The site absolutely spiked with what looked to be a near-full Panda recovery. The site jumped up to 75% of its original traffic levels from Google organic.

Temporary Panda Recovery on July 22, 2014

Checking the keywords that surged back, they matched up very well with the keywords from pre-Panda 4.0. There was clearly a Panda update pushed out, although it was hard to say if it was a Panda tremor (minor tweaks) or something larger. It’s worth noting that I saw other sites dealing with Panda 4.0 hits show serious movement on this day. For example, one large site saw almost a full recovery (from a major Panda 4.0 hit).

July 27, 2014 – It was nice while it lasted.
Well, that was fast. It seems yet another Panda tremor came rolling through and the site lost all of its gains. I’ll cover more about that shortly, but it’s important to note that the site dropped back to its post Panda 4.0 levels. So, the temporary recovery lasted about 5 days. That’s a tough pill to swallow for the business owner, but taking a look at the situation objectively, it makes a lot of sense.

Second Panda Hit After Temporary Recovery

This situation underscores an important point about Panda recovery. You need to make serious changes in order to see long-term improvement. Band-aids and lack of action will get you nowhere. Or worse, it could yield a misleading, temporary recovery that gets your hopes up, only to come crashing down again. Let’s explore the temporary recovery in more detail.

Temporary Recoveries and Panda Tests
I mentioned earlier that I’ve seen Panda victims experience short bumps in Google organic traffic during the recovery phase. I even documented it in one of my Panda recovery case studies. It’s almost like Google is giving the site a second chance, testing user engagement, analyzing the new traffic, etc. And if it likes what it sees, the recovery could stick. In the case study I just mentioned, the site ended up recovering just a few weeks after the temporary bump occurred.

So, will this website experience a similar recovery? You never know, but I doubt it. The site that ended up recovering long-term made massive changes based on a deep Panda audit. They should have recovered (even quicker than they did in my opinion). The site I just analyzed hasn’t made any changes at all, so I doubt it will recover in its current state.

Key Learnings
I’ll end this post with some key learnings based on what I’ve seen with Panda recovery, tremors, etc. If you are struggling with Panda recovery, or if you are helping others with Panda recovery, then the following bullets are important to understand.

  • Google can, and will, push out minor Panda updates (which I call Panda tremors). Sites can recover during those updates to various degrees. For example, I saw a large-scale Panda 4.0 victim experience a near-full recovery during the July 22 update.
  • Small websites can get hammered by Panda too. I know there’s often a lot of focus on large-scale websites with many pages indexed, but I’ve analyzed and helped a number of small sites with Panda hits. Panda is size-agnostic.
  • When websites stir up a serious Panda cocktail, it can experience a misleading surge in traffic, followed by a catastrophic Panda attack. Understanding the factors that can lead to a Panda hit is extremely important. You should avoid them like the plague.
  • Be ready for Panda tests. When Google tests your site again, make sure you are ready from a content, ad, and engagement standpoint. Do the right things Panda-wise so you can pass with flying colors. If not, don’t bank on a recovery sticking. It might just be temporary…
  • Once again, I found deception and trickery contribute to a Panda hit. Cloaked ads, questionable authorship, heavy affiliate linking, and more led to this Panda attack. If you deceive users, expect a visit from the mighty Panda. And no, it probably won’t be pleasant.
  • In some situations, money terms may not be affected by panda. In this case study, the core money term was not impacted at all. It remained steady throughout the ups and downs. But as documented above, that didn’t stop the site from experiencing a massive drop in Google organic traffic (86%).

Summary: Long-Term Panda Changes = Long-Term Panda Wins
First, I’m glad you made it to the end of this post (I know it was getting long). Second, I hope you found this Panda case study interesting. It was definitely fascinating to analyze. I’ve helped many companies with Panda attacks since February of 2011 and this case had some very interesting aspects to it. As usual, my hope is this situation can help some of you dealing with Panda attacks better understand the fluctuations you are seeing over time. Panda can be a confusing topic for sure.

If there are few core things you should remember leaving this post, it’s that temporary recoveries can happen, implementing the right Panda changes over time is extremely important, Google can test your site during the recovery phase, and organic search traffic can come and go like the wind. Just make sure you’re ready when the Panda comes knocking.




Tuesday, July 22nd, 2014

How To Get More Links, Crawl Errors, Search Queries, and More By Verifying Directories in Google Webmaster Tools

Verify by Directory in Google Webmaster Tools

In my opinion, it’s critically important to verify your website in Google Webmaster Tools (GWT). By doing so, you can receive information directly from Google as it crawls and indexes your website. There are many reports in GWT that can help identify various problems SEO-wise. For example, you can check the crawl errors report to surface problems Googlebot is encountering while crawling your site. You can check the HTML improvements section to view problems with titles, descriptions, and other metadata. You can view your inbound links as picked up by Google (more on that soon). You can check xml sitemaps reporting to view warnings, errors, and the indexed to submitted ratio. You can view indexation by directory via Index Status (forget about a site command, index status enables you to view your true indexation number).

In addition to the reporting you receive in GWT, Google will communicate with webmasters via “Site Messages”. Google will send messages when it experiences problems crawling a website, when it picks up errors or other issues, and of course, if you’ve received a manual action (penalty). That’s right, Google will tell you when your site has been penalized. It’s just another important reason to verify your website in GWT.

Limit On Inbound Links for Sites With Large Profiles
And let’s not forget about links. Using Google Webmaster Tools, you can view and download the inbound links leading to your site (as picked up by Google). And in a world filled with Penguins, manual actions, and potential negative SEO, it’s extremely important to view your inbound links, and often. Sure, there’s a limit of ~100K links that you can download from GWT, which can be limiting for larger and more popular sites, but I’ll cover an important workaround soon. And that workaround doesn’t just apply to links. It applies to a number of other reports too.

When helping larger websites with SEO, it’s not long before you run into the dreaded limit problem with Google Webmaster Tools. The most obvious limit is with inbound links. Unfortunately, there’s a limit of ~100K links that you can download from GWT. For most sites, that’s not a problem. But for larger sites, that can be extremely limiting. For example, I’m helping one site now with 9M inbound links. Trying to hunt down link problems at the site-level is nearly impossible via GWT with a link profile that large.

Inbound Links in Google Webmaster Tools


When you run into this problem, third party tools can come in very handy, like Majestic SEO, ahrefs, and Open Site Explorer. And you should also download your links from Bing Webmaster Tools, which is another great resource SEO-wise. But when you are dealing with a Google problem, it’s optimal to have link data directly from Google itself.

So, how do you overcome the link limit problem in GWT? Well, there’s a workaround that I’m finding many webmasters either don’t know about or haven’t implemented yet – verification by directory.

Verification by Directory to the Rescue
If you’ve been following along, then you can probably see some issues with GWT for larger, complex sites. On the one hand, you can get some incredible data directly from Google. But on the other hand, larger sites inherently have many directories, pages, and links to deal with, which can make your job analyzing that data harder to complete.

This is why I often recommend verifying by directory for clients with larger and more complex websites. It’s a great way to dig deep into specific areas of a website. As mentioned earlier, I’ve found that many business owners don’t even know you can verify by directory!  Yes, you can, and I recommend doing that today (even if you have a smaller site, but have distinct directories of content you monitor). For example, if you have a blog, you can verify the blog subdirectory in addition to your entire site. Then you can view reporting that’s focused on the blog (versus muddying up the reporting with data from outside the blog).

Add A Directory in Google Webmaster Tools

And again, if you are dealing with an inbound links problem, then isolating specific directories is a fantastic way to proceed to get granular links data. There’s a good chance the granular reporting by directory could surface new unnatural links that you didn’t find via the site-level reporting in GWT. The good news is that verifying your directories will only take a few minutes. Then you’ll just need to wait for the reporting to populate.

Which Reports Are Available For Directories?
I’m sure you are wondering which reports can be viewed by subdirectory. Well, many are available by directory, but not all. Below, you can view the reports in GWT that provide granular data by directory.

  • Search Queries
  • Top Pages (within Search Queries reporting)
  • Links to Your Site
  • Index Status
  • Crawl Errors (by device type)
  • HTML Improvements
  • Internal Links
  • International Targeting (New!)
  • Content Keywords
  • Structured Data


GWT Reporting by Directory – Some Examples

Indexation by Directory
Let’s say you’re having a problem with indexation. Maybe Google has only indexed 60% of your total pages for some reason. Checking the Index Status report is great, but doesn’t give you the information you need to isolate the problem.  For example, you want to try and hunt down the specific areas of the site that aren’t indexed as heavily as others.

If you verify your subdirectories in GWT, then you can quickly check the Index Status report to view indexation by directory. Based on what you find, you might dig deeper to see what’s going on in specific areas of your website. For example, running crawls of that subdirectory via several tools could help uncover potential problems. Are there roadblocks you are throwing up for Googlebot, are you mistakenly using the meta robots tag in that directory, is the directory blocked by robots.txt, is your internal linking weaker in that area, etc? Viewing indexation by directory is a logical first step to diagnosing a problem.

How To View Index Status by Directory in Google Webmaster Tools


Search Queries by Directory
Google Webmaster Tools provides search queries (keywords) that have returned pages on your website (over the past 90 days). Now that we live in a “not provided” world, the search queries reporting is important to analyze and export on a regular basis. You can view impressions, clicks, CTR, and average position for each query in the report.

But checking search queries at the site level can be a daunting task in Google Webmaster Tools. What if you wanted to view the search query data for a specific section instead? If you verify by directory, then all of the search query data will be limited to that directory. That includes impressions, clicks, CTR, and average position for queries leading to content in that directory only.

In addition, the “Top Pages” report will only contain the top pages from that directory. Again, this quickly enables you to hone in on content that’s receiving the most impressions and clicks.

And if you feel like there has been a drop in performance for a specific directory, then you can click the “with change” button to view the change in impressions, clicks, CTR, and average position for the directory. Again, the more granular you can get, the more chance of diagnosing problems.

How To View Search Query Reporting by Directory in Google Webmaster Tools


Links by Directory
I started explaining more about this earlier, and it’s an extremely important example. When you have a manual action for unnatural links, you definitely want to see what Google is seeing. For sites with large link profiles, GWT is not ideal. You can only download ~100K links, and those can be watered down by specific pieces of content or sections (leaving other important sections out in the cold).

When you verify by directory, the “links to your site” section will be focused on that specific directory. And that’s huge for sites trying to get a better feel for their link profile, unnatural links, etc. You can see domains linking to your content in a specific directory, your most linked content, and of course, the actual links. And you can download the top ~100K links directly from the report.

In addition, if you are trying to get a good feel for your latest links (like if you’re worried about negative SEO), then you can download the most recent links picked up by Google by clicking the “Download latest links” button.  That report will be focused on the directory at hand, versus a site-level download.

I’m not saying this is perfect, because some directories will have many more links than 100K. But it’s much stronger than simply downloading 100K links at the site-level.

How To View Inbound Links by Directory in Google Webmaster Tools


Crawl Errors By Directory
If you are trying to analyze the health of your website, then the Crawl Errors reporting is extremely helpful to review. But again, this can be daunting with larger websites (as all pages are reported at the site-level). But if you verify by directory, the crawl errors reporting will be focused on a specific directory. And that can help you identify problems quickly and efficiently.

In addition, you can view crawl errors reporting by Google crawler. For example, Googlebot versus Googlebot for Smartphones versus Googlebot-mobile for Feature Phones. By drilling into crawl errors by directory, you can start to surface problems at a granular level. This includes 404s, 500s, Soft 404s, and more.

How To View Crawl Errors by Directory in Google Webmaster Tools

Summary – Get Granular To View More Google Webmaster Tools Data
Verifying your website in Google Webmaster Tools is extremely important on several levels (as documented above).  But verifying by directory is also important, as it enables you to analyze specific parts of a website at a granular basis. I hope this post convinced you to set up your core directories in GWT today.

To me, it’s critically important to hunt down SEO problems as quickly as possible. The speed at which you can identify, and then rectify, those problems can directly impact your overall SEO health (and traffic to your site). In addition, analyzing granular reporting can help surface potential problems in a much cleaner way than viewing site-wide data. And that’s why verifying subdirectories is a powerful way to proceed (especially for large and complex sites).  So don’t hesitate. Go and verify your directories in Google Webmaster Tools now. More data awaits.




Monday, July 14th, 2014

Panda, Penguin, and Manual Actions – Questions, Tips, and Recommendations From My SES Atlanta Session

SES Atlanta Panda

{Important Update About Penguin: Read John Mueller’s latest comments about the Penguin algorithm.}

I just returned from SES Atlanta, where I presented “How To Avoid and Recover From Panda, Penguin, and Manual Actions”. The conference was outstanding, included a killer keynote by Duane Forrester and sessions packed with valuable information about SEO and SEM. By the way, I entered my hotel room in Atlanta and immediately saw a magazine on the desk. The photo above is the cover of that magazine! Yes, a Panda was on the cover. You can’t make this stuff up. :)

During (and after) my presentation about algorithm updates and penalties, I received a number of outstanding questions from audience members. And later in the day, I led a roundtable that focused on Panda and Penguin. There were also some great conversations during the roundtable from business owners and marketers across industries. It’s always interesting to hear top marketer concerns about major algorithm updates like Panda and Penguin (and especially Panda 4.0 which just rolled out in late May). We had a lively conversation for sure.

On the plane flight home, I started thinking about the various questions I was asked, which areas were the most confusing for marketers, and the tips and recommendations I was sharing.  And based on that list, I couldn’t help but think a Q&A style blog post could be very helpful for others dealing with Panda, Penguin, and manual actions. So, I decided to write this post covering a number of those questions. I can’t cover everything that I spoke about at SES Atlanta (or this post would be huge), but I can definitely provide some important tips and recommendations based on questions I received during the conference.  Let’s jump in.

Algorithm Updates and Manual Actions – Q&A From SES Atlanta

Question: I’ve been hit by Panda 4.0. What should I do with “thin content” or “low-quality” content I find on my website?  Is it better to nuke the content (404 or 410), noindex it, or should I redirect that content to other pages on my site?

Glenn: I hear this question often from Panda victims, and I know it’s a confusing topic. My recommendation is to remove thin and low-quality content you find on your site. That means 404 or 410 the content or noindex the content via the meta robots tag. When you have a content quality problem on your site, you need to remove that content from Google’s index. In my experience with helping companies recover from Panda, this has been the best path to take.

That said, if you find content that’s thin, but you feel you can enhance that content, go for it. If you believe the content could ultimately hold information that people are searching for, then beef it up. Just make sure you do a thorough job of developing the additional content. Don’t replace thin content with slightly thin content. Create killer content instead. If you can’t, then reference my first point about nuking the content.

Also, it’s important to ensure you are removing the right content… I’ve seen companies nuke content that was actually fine thinking it was low-quality for some reason. That’s why it’s often helpful to have an objective third party analyze the situation. Business owners and marketers are often too close to their own websites and content to objectively rate it.

Panda Decision Matrix


Question: How come I haven’t seen a Panda recovery yet even though I quickly made changes? I was expecting to recover during the next Panda update once the changes were implemented.

Glenn: This is another common question from Panda victims. It’s important to understand that completing the changes alone isn’t enough. Google first needs to recrawl the site and the changes you implemented.  Then it needs to better understand user engagement based on the changes. I’ve explained many times in my blog posts about Panda that the algorithm is heavily focused on user engagement. So just making changes on your site doesn’t provide Google enough information.

Panda recovery can take time. Just read my case study about 6 months with Panda. That was an extreme situation in my opinion, but it’s a great example of how long it can take to recover.

Second, Panda roughly rolls out once per month. You need an update to occur before you can see changes. But that’s not a hard rule. John Mueller from Google clarified the “Panda Tremors” I have been seeing since Panda 4.0, and explained that there isn’t a fixed frequency for algorithm updates like Panda. Instead, Google can continue to tweak the algo to ensure it yields the desired results. Translation: you might see turbulence after a Panda hit (and you may see increases or decreases as the tremors continue).

Panda Tremors John Mueller

And third, you might see smaller recoveries over time during subsequent updates (versus a full recovery in one shot). I’ve had several clients increase with subsequent Panda updates, but it took 4-5 updates for them to fully recover. So keep in mind that you might not see full recovery in one shot.


Question:  We know we have an unnatural links problem, and that we were hit by Penguin, but should we tackle the links problem or just build new links to balance out our link profile?

Glenn: I’ve seen many companies that were hit by Penguin avoid tackling the root problem, and instead, just try and build new links to balance out their link profile. In my opinion, that’s the wrong way to go. I always recommend aggressively handling the unnatural links situation, since that’s the most direct path to Penguin recovery.

And to clarify, you should still be pumping out killer content, using Social to get the word out, etc. I always tell clients impacted by Penguin or Panda to act like they aren’t impacted at all. Keep driving forward with new content, sharing via social media, connecting with users, etc. Fresh links and shares will be a natural side effect, and can help the situation for sure. And then the content they are building while under the Penguin filter could end up ranking well down the line. It’s hard to act like you’re not hit, but that’s exactly what you need to do. You need to be mentally tough.

Address Unnatural Links for Penguin


Question: Is it ok to remove content from Google’s index? Will that send strange signals to the engines?

Glenn: Nuke it. It’s totally fine to do so, and I’ll go even further and say it could be a great thing to do. I mentioned this several times in my Panda 4.0 findings, but the right indexation is more important than high indexation. In other words, make sure Google has your best content indexed, and not thin, duplicate, or other low-quality content.

I had one client drop their indexation by 83% after being impacted by Phantom and Panda, and they are doing extremely well now Google organic-wise. I love the screenshot below. It goes against what many marketers would think. Lower indexation = more Google traffic. That’s awesome.

Indexation and Panda


Question: We consume a lot of syndicated content. What’s the best way to handle attribution?

Glenn: I saw a number of sites get smoked during Panda 4.0 that were consuming a lot of syndicated content and not handling that properly SEO-wise. The best way to handle attribution for syndicated content is to use the cross domain canonical url tag pointing to the original article. If you can’t do that (or don’t want to do that), then you can keep the content out of Google’s index by noindexing it via the meta robots tag.

It’s not your content, so you shouldn’t be taking credit for it.  That said, if set up correctly, it’s fine to have syndicated content on your site for users to read. But the proper attribution is important or it can look like you are copying or scraping content. I know that won’t go over well for ad teams looking to rank in organic search (to gain more pageviews), but again, it’s not your content to begin with.

Syndication and Panda


Question: Why hasn’t there been a Penguin update since October of 2013? What’s going on? And will there ever be another update?

Glenn: It’s been a long time since the last Penguin update (October 4, 2013). Like many others heavily involved with Penguin work, I’m surprised it has taken so long for another update.

Penguin 2.1 on October 4, 2013

Matt Cutts recently explained at SMX Advanced that they have been heavily working on Panda 4.0, so Penguin has taken a back seat. But he also said that an engineer came up to him recently and said, “it’s probably time for a Penguin update”. That situation is both positive and scary at the same time.

On the one hand, at least someone is thinking about Penguin on the webspam team! But on the flip side, they clearly haven’t been focusing on Penguin for some time (while many Penguin victims sit waiting for an update). On that note, there are many webmasters who have rectified their unnatural link problems, disavowed domains, urls, etc., and are eagerly awaiting a Penguin update. It’s not exactly fair that Google has been making those business owners wait so long for Penguin to roll out again.

Now, there’s always a possibility that there is a problem with the Penguin algorithm. Let’s face it, there’s no reason it should take so long in between updates. I’m wondering if they are testing Penguin and simply not happy with the results. If that’s the case, then I could see why they would hold off on unleashing a new update (since it could wreak havoc on the web). But that’s just speculation.

In my opinion, it’s not cool to let Penguin victims that have worked hard to fix their link problems sit in Penguin limbo. So either Google is seriously punishing them for the long-term, they have put the algo on the back burner while focusing on other algos like Panda, or Penguin is not up to par right now. Remember, if Google isn’t happy with the results, then they don’t have to push it out. And if that’s the case, Penguin victims could sit in limbo for a long time (even longer than the 9 months they have waited so far.)  Not good, to say the least.

Important Penguin Update: Google’s John Mueller provided more information about the Penguin algorithm on today’s Webmaster Central Office Hours Hangout.

John was asked if Penguin would be released again or if it was being retired. And if it was being “retired”, then would Google at least run it one more time to free those webmasters that had cleaned up their link profiles. John explained that Penguin was not being retired. Let me say that again. he said Penguin is not being retired. John explained that it can sometimes take longer than expected to prepare the algorithm and update the necessary data. He also explained that if Google were to retire an algorithm, then they would “remove it completely” (essentially removing any effect from the algorithm that was in place).

So we have good news on several fronts. Penguin is still alive and well. And if Google did retire the algo, then the effect from Penguin would be removed. Let’s hope another Penguin update rolls out soon.

You can view the video below (starting at 5:16) or you can watch on YouTube -> https://www.youtube.com/watch?v=8r3IIPCHt0E&t=5m16s


Question: We’ve been hit by both Panda and Penguin. We don’t have a lot of resources to help with recovery, so which one do we tackle first?

Glenn: I’ve helped a number of companies with Pandeguin problems over the years, and it’s definitely a frustrating situation for business owners. When companies don’t have resources to tackle both situations at the same time, then I’ve always been a big fan of tackling the most acute situation first, which is Penguin.

Pandeguin Hit

Panda is a beast, and has many tentacles. And Penguin is all about unnatural links (based on my analysis of over 400 sites hit by Penguin since April 24, 2012). That’s why I recommend focusing on Penguin first (if you can’t knock out both situations at once). I recommend aggressively tackling unnatural links, remove as many spammy links as you can, and then disavow the remaining ones you can’t get to manually. Then set up a process for monitoring your link profile over time (to ensure new unnatural links don’t pop up).

After which, you can tackle the Panda problem. I would begin with a comprehensive Panda audit, identify the potential problems causing the Panda hit, and aggressively attack the situation (the bamboo). Move quickly and aggressively. Get out of the grey area of Panda (it’s a maddening place to live).


Question: Is linkbuilding dead? Should I even focus on building links anymore and how do I go about doing that naturally?

Glenn: Links are not dead! The right links are even more important now. I know there’s a lot of fear and confusion about linkbuilding since Google has waged war on unnatural links, but to me, that makes high quality links even more powerful.

Duane Forrester wrote a post recently on the Bing Webmaster Blog where he explained if you know where a link is coming from prior to gaining that link, then you are already going down the wrong path. That was a bold statement, but I tend to agree with him.

Duane Forrester Quote About Linkbuilding

I had several conversations about this topic at SES Atlanta. To me, if you build killer content that helps your target audience, that addresses pain points, and teaches users how to accomplish something, then there’s a good chance you’ll build links. It’s not the quantity of links either… it’s the quality. I’d rather see a client build one solid link from a site in their niche versus 1000 junky links. The junky links are Penguin food, while the solid link is gold.


Question: I was hit by Panda, but my core competitors have the same problems we do. We followed what they were implementing, and we got hit. Why didn’t they get hit? And moving forward, should we follow others that are doing well SEO-wise?

Glenn: I can’t tell you how many times companies contact me and start showing me competitors that are doing risky things SEO-wise, yet those sites are doing well in Google. They explain that they tried to reproduce what those competitors were doing, and then they ended up getting hit by Panda. That situation reinforces what I’ve told clients for a long time. Competitive analyses can be extremely beneficial for gathering the right intelligence about your competitors, but don’t blindly follow what they are doing. That’s a dangerous road to travel.

Instead, companies should map out a strong SEO strategy based on their own research, expertise, target audience, etc. Ensure you are doing the right things SEO-wise for long-term success. Following other companies blindly is a dangerous thing to do. They could very easily be headed towards SEO disaster and you’ll be following right along.

For example, I had a client always bring up one specific company to me that was pushing the limits SEO-wise (using dark grey hat tactics). Well, they finally got hit during a Panda update in early 2014 and lost a substantial amount of traffic. I sent screenshots to my client which reinforced my philosophy. My client was lucky they didn’t follow that company’s tactics… They would have jumped right off the SEO cliff with them. The screenshot below shows an example of a typical surge in Google before a crash.

Surge in Traffic Before Algo Hit


Question: We’ve been working hard on a manual action for unnatural links, but right before filing reconsideration, it expired. What should we do?

Glenn: I’ve seen this happen with several clients I was helping with manual actions. It’s a weird situation for sure. You are working on fixing problems based on receiving a manual action, and right before you file a reconsideration request, the manual action disappears from Google Webmaster Tools. When that happens, is the site ok, do you still need to file a reconsideration request with Google, should you wait, or should you continue working on the manual action?

It’s important to know that manual actions do expire. You can read that article by Marie Haynes for more information about expiring manual actions. Google has confirmed this to be the case (although the length of each manual action is variable). But those manual actions can return if you haven’t tackled the problem thoroughly… So don’t’ think you’re in the clear so fast.

Expiring Manual Actions


That said, if you have tackled the problem thoroughly, then you are probably ok. For example, I was helping a company with a manual action for unnatural links and we had completed the process of removing and disavowing almost all of their unnatural links. We had already written the reconsideration request and were simply waiting on a few webmasters that were supposed to take down more links before filing with Google.

As we were waiting (just a few extra days), the manual action disappeared from Google Webmaster Tools. Since we did a full link cleanup, we simply drove forward with other initiatives. That was months ago and the site is doing great SEO-wise (surging over the past few months).

Just make sure you thoroughly tackle the problem at hand. You don’t want a special surprise in your manual action viewer one day… which would be the return of the penalty. Avoid that situation by thoroughly fixing the problems causing the penalty.


Summary – Clarifying Panda and Penguin Confusion
As you can see, there were some outstanding and complex questions asked at SES Atlanta. It confirms what I see every day… that business owners and webmasters are extremely confused with algorithm updates like Panda and Penguin and how to tackle penalties. And when you combine algo updates with manual actions, you have the perfect storm of SEO confusion.

I hope the Q&A above helped answer some questions you might have about Panda, Penguin, and manual actions. And again, there were several more questions asked that I can’t fit into this post! Maybe I’ll tackle those questions in another post. So stay tuned, subscribe to my feed, and keep an eye on my Search Engine Watch column.

And be prepared, I felt a slight chill in the air this past weekend. The next Penguin update could (and should) be arriving soon. Only Google knows, but I hope they unleash the algo update soon. Like I said in my post, there are many webmasters eagerly awaiting another Penguin rollout. Let’s hope it’s sooner than later.