The Internet Marketing Driver

  • GSQi Home
  • About Glenn Gabe
  • SEO Services
    • Algorithm Update Recovery
    • Technical SEO Audits
    • Website Redesigns and Site Migrations
    • SEO Training
  • Blog
    • Web Stories
  • Contact GSQi

Archives for December 2017

It’s In The Stars – A Google Algorithm Update On 12/15/17 Is Impacting Some Official Celebrity Websites (Updated)

December 26, 2017 By Glenn Gabe 17 Comments

Google Celebrity Algorithm Update

This is NOT a normal post for me to publish, but I wanted to quickly document what I’m seeing. I’m in the middle of heavily analyzing some larger algorithm updates that occurred in December (there were several), and I came across a very interesting situation. I noticed that some celebrities aren’t ranking anymore for their own names. Their official websites used to rank number one in the search results as of early December, but those sites are now either at the bottom of page one or even off page one.

I initially noticed several celebrities were impacted, including John Lennon, Lebron James, Kristen Stewart, and Charlie Sheen.  I also noticed some strange things going on rankings-wise with the official website for Miley Cyrus a few months back, and that seemed to calm down, but she might be experiencing some issues again. I wasn’t planning on digging into this situation since I’m neck deep in analyzing other updates that occurred this month, but again, I wanted to document the volatility I’m seeing for the celebrities listed in this post. I don’t know if this is collateral damage based on other updates Google has pushed, or if this is intentional. Again, I plan to check this out further soon.

——————–

Update 12/27 8AM: I just added Tom Cruise’s site, which dropped on the same day. Also, although not as bad of a drop, Barack Obama’s official site also dropped several spots. It used to rank #1 for his name, but is now under Wikipedia and Twitter. See the screenshots below. You can also see the search visibility dropping and then bouncing back, and then dropping again. So it’s pretty clear something is going on here… Continuing my updates, I added Leonardo Dicaprio’s site, which also dropped on 12/15. It now ranks under IMDB, Twitter, and Wikipedia, when it used to rank #1. I also included Marilyn Monroe’s official website, which also dropped. It now ranks #6 when it used to rank #1 before the update. At 3PM, I also added Channing Tatum, since his site dropped from #1 to #11 for his name. There are many examples of this happening across celebrities.

Update 12/27 10AM: Thoughts about why is this happening:
After digging into the sites that were impacted, I’m starting to believe Google could be simply treating them just like any other site (even if they are the official celebrity website). They are often very simple websites, they don’t contain a lot of content, and sometimes they are just single page websites. So quality is definitely an issue. If that’s the case, then Google must have been treating them differently before 12/15/17. After going through a number of the sites impacted, I can’t imagine users were happy with the results. And we know Google always wants to provide the best results possible. I’ll post an update with any changes I see. Stay tuned.

Update 12/27 12:30PM: I included information and screenshots below about searches on mobile devices and how celebrity Knowledge Panels come into play (which sometimes contain links to the official websites).

Update 12/28 9:30AM: Many people have been asking me for an example of an official celebrity website that hasn’t dropped. So I added screenshots below from Katy Perry’s official site katyperry.com. You can see search visibility is stable through the update and the site still ranks #1 for her name. The site is definitely higher quality than most celebrity websites. It works well, is pretty well organized, and contains a good amount of content. Other celebrities might want to review at her site. :)

——————–

In the meantime, here are some screenshots of what I’m seeing rankings-wise. It should be interesting to see if the sites bounce back as Google continues to make changes. Or maybe this is what they want… It’s hard to say at this point, but I saw enough celebrities drop that I decided to publish this post.

1. John Lennon
Drop in Search Visibility on 12/15:

John Lennon drop.

Screenshot from November of site ranking #1 for the query “John Lennon”:

John Lennon ranking number one.

Screenshot on 12/26 (ranking #9):

John Lennon ranking #9 after the update.

2. Charlie Sheen
Drop in Search Visibility on 12/15:

Charlie Sheen drop.

Screenshot from November of site ranking #1 for the query “Charlie Sheen”:

Charlie Sheen ranking #1 before the update.

Screenshot on 12/26 (ranking #9):

Charlie Sheen ranking #9 after the update.

3. Lebron James
Drop in Search Visibility on 12/15:

Lebron James drop.

Screenshot from November of site ranking #1 for the query “Lebron James”:

Lebron James ranking #1 before the update.

Screenshot on 12/26 (not ranking on page one at all):

Lebron James not on page one after the update.

4. Kristen Stewart
Drop in Search Visibility on 12/15:

Kristen Stewart drop.

Screenshot from November of site ranking #1 for the query “Kristen Stewart”:

Kristen Stewart ranking #1 before the update.

Screenshot on 12/26 (not ranking on page one at all):

Kristen Stewart not ranking on page one after the update.

Update 12/27 8AM: I added Tom Cruise after hearing from Dan Sharp of Screaming Frog.
5. Tom Cruise

Drop in Search Visibility on 12/15:

Tom Cruise drop after algorithm update.

Screenshot from November of site ranking #1 for the query “Tom Cruise”:

Tom Cruise ranking #1 before the update.

Screenshot on 12/26 (now ranking #6 after the update):

Tom Cruise now ranking #6 after the update.

Update 12/27 9:30AM: I added Barack Obama after seeing his official site drop in rankings for his name.
6. Barack Obama

Drop and Surges in Search Visibility starting on 12/15:

Barack Obama drop after algorithm update.

Screenshot from November of site ranking #1 for the query “Barack Obama”:

Barack Obama ranking #1 before the algorithm update.

Screenshot on 12/26 (now ranking #3 after the update, under Wikipedia and Twitter):

Barack Obama's site dropping after algorithm update.

Update 12/27 10:20AM: I added Leonardo Dicaprio after seeing his official site drop in rankings for his name. It was similar to Barack Obama’s situation above. Leo’s site dropped from #1 to #4 (now under IMDB, Twitter, and Wikipedia). 
7. Leonardo Dicaprio
Drop in Search Visibility starting on 12/15:

Leonardo Dicaprio Drop.

Screenshot from November of site ranking #1 for the query “Leonardo Dicaprio”:

Leonardo Dicaprio's site ranking #1 before the update.

Screenshot on 12/26 (now ranking #4 after the update, under IMDB, Twitter, and Wikipedia):

Leonardo Dicaprio's site dropping in rankings after the algorithm update.

Update 12/27 11:00AM: I added Marilyn Monroe after hearing from Julie Logan of Irish Wonder.
8. Marilyn Monroe

Drop in Search Visibility on 12/15:

Marilyn Monroe drop.

Screenshot from November of site ranking #1 for the query “Marilyn Monroe”:

Marilyn Monroe's official site ranking #1 before the algorithm update.

Screenshot on 12/26 (now ranking #6 after the update):

Marilyn Monroe's official website dropping in rankings after the algorithm update.

Update 12/27 3:00PM: I included Channing Tatum since his official site dropped from #1 to #11.
9. Channing Tatum

Drop in Search Visibility on 12/15:

Channign Tatum Drop.

Screenshot from November of site ranking #1 for the query “Channing Tatum”:

The official site for Channing Tatum ranking #1 before the Google update.

Screenshot on 12/26 (now ranking #11 after the update):

The official site for Channing Tatum dropping to #9 after the Google update.

Update 12/28 9:30AM: Many people were asking for examples of celebrity websites that didn’t drop, so I included Katy Perry below since her official site still ranks #1 for her name (and search visibility remained stable through the update).
10. Katy Perry (was not impacted by the update)
No drop in search visibility through the update:

Katy Perry's official website was stable through the update.

Screenshot from November of site ranking #1 for the query “Katy Perry”:

Katy Perry's official site ranking #1 before the algorithm update.

Screenshot on 12/26 (still ranking #1 after the update):

Katy Perry's official site still ranking #1 after the algorithm update.

A Mobile Twist: The Impact of Knowledge Panels in Mobile Search:
Update 12/27 12:30PM: After analyzing the sites and the search results more, I noticed an interesting situation when searching on mobile devices. We know Google is actively moving sites to its mobile-first index based on the boom in smartphone usage. And we also know that Knowledge Panels can take up a huge amount of real estate on mobile phones. Well, when you search for some of the celebrity names that dropped during the update (on mobile devices), you can see how Knowledge Panels comes into play (and they often contain a link to the official website for the celebrity!) So just checking on desktop doesn’t give the full picture. If you test on mobile devices, you can often still see the official site listed. The sites have dropped on desktop, but can remain in the Knowledge Panel, which shows up above the search results. This didn’t always happen, but it did show up for several tests I performed.

Here are a few examples:

Tom Cruise on mobile devices.

Charlie Sheen on mobile.

Leonardo Dicarpio on mobile.

I’ll post an update as I gather more information and perform more testing. I’m also planning on pinging some people from Google about this in case it’s a mistake. Stay tuned.

——————–

Update: I reached out to Danny Sullivan and John Mueller from Google and heard back from Danny on Twitter. He passed along the information to others at Google and they are looking into it. I’ll post another update once I hear back (if we hear anything about the situation).

GG

Filed Under: algorithm-updates, google, seo

From m-dot to m-not. Real-world examples of mobile SEO problems with Google’s mobile-first index looming

December 18, 2017 By Glenn Gabe 7 Comments

Mobile problems with Google's mobile-first index approaching.
In October of 2016, Google announced its plan to move to a mobile-first index. Gary Illyes first explained this at Pubcon and then Google officially published a blog post covering the subject. It’s an important move and a 180 for search. Until now, Google has used the desktop URLs and content for ranking purposes, even for mobile rankings. That’s not optimal given the surge in smartphones and mobile usage, so they decided to make a switch.

With the mobile-first index, Google will instead use the mobile URLs and content for ranking purposes. Therefore, it’s critically important that site owners have their ducks in a row from a mobile standpoint (across several areas).

Tough(er) for m-dots
The move to a mobile-first index can be especially concerning for sites using separate mobile URLs (like m-dot subdomains). And that’s one of the reasons Google has been pushing responsive design as the cleanest approach for handling mobile. When using responsive design, the same HTML is delivered to all users, including structured data, hreflang tags and so on. CSS is used to change the rendering of the page based on viewport size. Since the same HTML is delivered for both desktop and mobile users, the move to a mobile-first index shouldn’t impact sites using responsive design at all.

But when using separate mobile URLs, you have a completely different set of pages. And those URLs could very well contain scaled-down content, a different internal navigation, no structured data, the wrong hreflang tags (or no hreflang tags) and so on. And that’s a dangerous situation with the mobile-first index rolling out. You also need to use the correct technical SEO setup to signal the relationship between desktop and mobile URLs.

Here is the difference between using separate mobile URLs and responsive design, from Google’s support docs:
The difference between responsive design and separate mobile urls.

Google’s John Mueller and Gary Illyes have both explained that having equivalent content on your mobile URLs is extremely important when preparing for the mobile-first index. In addition, other elements such as structured data and hreflang tags must also be present on your mobile URLs. You don’t want to be in a situation where your site moves to the mobile-first index and only half the content is being used for ranking purposes.

And recently, Google even explained that some sites have already moved to the mobile-first index! So yes, we are very close to seeing Google move more and more sites to mobile-first. Needless to say, site owners started to freak out a little.

Jerry Maguire freaks out about mobile-first index.

Over the past several months, there have been many questions about how the mobile-first index will work, the types of problems that need to be rectified, and how Google will treat certain situations. There’s a lot of confusion, that’s for sure. Below, I’ll take you through some real-world mobile problems that I have uncovered while helping companies prepare for the mobile-first index. Let’s jump in.

Risky m-dot setups cause mobile-first problems
Since Google’s announcement about the mobile-first index, I’ve been helping a number of large-scale websites prepare. These are companies that either have separate mobile URLs (like m-dot subdomains) or are using dynamic serving, which provides different HTML and CSS based on user-agent. (Note: Dynamic serving is only a problem if there are significant gaps between the desktop page and mobile version. But there can still be problems, so keep an eye out.)

While helping these companies dig into their specific mobile setup, I have uncovered some very interesting problems. Therefore, I thought it would be valuable to share some of those problems so you can better prepare your own sites for the move to a mobile-first index. You never know, you or your client might be facing similar issues. And if you are, I recommend tackling those issues now, before the switch to m-first happens.

Botched bidirectional annotations = bad signals
The first problem I’ll cover relates to the fundamental mobile setup a site should be employing when using separate mobile URLs. That’s where the desktop URL should contain rel alternate pointing to the mobile URL, and then the mobile URL should contain rel canonical pointing to the desktop URL.

These bidirectional annotations signal the relationship between desktop and mobile URLs to Google. And this can help Google surface the correct URLs in the search results based on device, consolidate indexing properties across the URLs and so on. Google’s support documentation fully explains how to set this up.

Bidirectional annotations when using separate mobile urls.
During a recent audit, I noticed a few alarming things. First, there were many pages indexed on the m-dot subdomain. That shouldn’t be the case. If Google is properly canonicalizing the mobile URLs, then they shouldn’t be indexed. Note, there will always be some indexation of mobile URLs showing in Google Search Console (GSC), but you shouldn’t see a large percentage of URLs indexed there. For the company I was helping, I saw over 170K mobile URLs indexed, and it was rising!

Second, mobile URLs were ranking on desktop. If you’re not familiar with this situation, it’s important to understand that this shouldn’t be happening. I saw over 57K clicks and over 1.2M impressions when checking the search analytics reporting for the m-dot (and filtering by desktop).
Mobile urls ranking in desktop search.

It’s also important to know that if mobile URLs are ranking in desktop search, that’s a clear sign there are technical problems with the mobile setup. Google’s John Mueller mentioned this on Twitter recently:

Google's John Mueller explaining that mobile urls should not rank in desktop search.

After digging in, I could see that the desktop pages contained self-referencing canonical tags (a good thing), but rel canonical was botched. The tags were using relative URLs rather than absolute, and since the URLs weren’t entered correctly, they created excessively long and concatenated URLs that led to 404s. Rel alternate was set up properly on the desktop URLs pointing to the correct mobile urls, but rel canonical wasn’t correct on those desktop urls.

Note: You can use relative URLs, but they must be entered correctly or Google may ignore rel canonical. Google even mentioned this issue in a blog post covering common problems when using the canonical tag. Here’s a graphic from the post illustrating the problem. The first line is incorrect and will append the domain name to a url that already has the domain name in it:

Relative urls can botch canonical tags.

And here is how the urls were breaking. Notice the url example that 404s and how the domain name was incorrectly appended to the url:

Botched canonical tags due to incorrectly adding relative urls.

Rel canonical was implemented correctly on the mobile pages, so the mobile URLs were correctly indicating the desktop URLs as the canonical version. However, since rel canonical was botched on desktop, the setup wasn’t working correctly. This led to over 170K mobile URLs getting indexed — and that’s why the mobile URLs were ranking on desktop search. Google was apparently seeing them just the way they would see other standard desktop URLs.

In addition, if Google doesn’t understand the relationship between desktop URLs and mobile URLs, the site could be diluting its efforts from an SEO standpoint. Google would not be consolidating indexing properties across each set of URLs (the desktop and mobile URLs). That could lead to weaker pages SEO-wise, weaker rankings, less organic search traffic and more. Not good, to say the least.

I immediately sent my findings to my client, and the fix was implemented very quickly (within two days). And you can already see desktop clicks and impressions dropping on the m-dot in Google Search Console (when filtering by desktop).

Traffic to m-dot from desktop dropping.

Double canonicals (header and HTML)
Another problem I surfaced that could cause serious problems overall (but especially with the mobile-first index looming) related to how a site was publishing rel canonical. I’ve written before about the power — and danger — of using the x-robots-tag. Using this tag, you can publish directives and rel links via the header response rather than in the HTML.

It’s powerful since it scales very well (it’s not in the HTML of each document). The danger is that it’s invisible to the naked eye. And when you can’t readily see the directives or rel links, there’s always a chance they could be wrong. And when they’re wrong on large and complex sites, they can wreak havoc on your SEO.

While recently auditing a site with separate mobile URLs, I surfaced rel canonical being published via both the HTML and the header response. So each page contained rel canonical twice. Since rel canonical is just a hint and not a directive, Google can ignore the canonical URL tag if it sees multiple tags (or if it just believes the site owner messed up). Therefore, when a site is using separate mobile URLs, the bidirectional annotations are critically important (as mentioned earlier). And you don’t want to publish multiple canonical tags across your URLs, including on your mobile URLs.

Double canonical tags being published by accident.

I sent this information along to my client, and their dev team is working on removing rel canonical via the header response. Once that’s completed, the company will be confident they are signaling to Google the correct relationship between desktop and mobile URLs. It’s better to rely on one hint versus multiple hints that possibly send mixed signals. Beware.

Pagination not set up correctly, especially on mobile.
Since I help a lot of large-scale sites, I’m often auditing and dealing with large amounts of pagination. It’s one area I’ve found to be extremely confusing for many site owners, SEOs and developers. Actually, I was surfacing so many similar pagination problems that I decided to write a thorough blog post detailing the correct setup for pagination, including how to set up sorting and filtering parameters. You can read that post if you need help with setting up your own pagination.

Setting up pagination using rel next/prev and rel canonical.

Well, during a recent audit of a site using separate mobile URLs, I noticed the pagination wasn’t set up properly, especially across the mobile URLs. Remember, the desktop URLs should contain rel alternate pointing to the mobile URLs, and the mobile URLs should contain rel canonical pointing to the desktop URLs. That’s on a one-to-one basis.

Therefore, each page of the pagination should contain self-referencing canonical tags. And the mobile URLs should contain rel canonical pointing to the desktop component pages. In other words, page two on mobile should point to page two on desktop, page three on mobile should point to page three on desktop, and so on.

The mobile URLs did contain rel canonical, but they were all pointing to page one on desktop. The desktop URLs were correctly set up with self-referencing canonical tags along with rel next/prev, but the mobile component pages were all being canonicalized to page one on desktop.

Needless to say, this is not the proper setup. And when the switch is made to the mobile-first index, Google would not index any of the content on the mobile component pages. Instead, only page one would be indexed. That’s not what this site wants based on their categories and articles, and it could lead to ranking problems (since content beyond page one would not be indexed at all.)

Don’t simply canonicalize component pages to page one in the pagination. That’s not the correct setup!
Incorrectly canonicalizing component pages to page one in the pagination.

I sent my findings along, and the pagination code was fixed pretty quickly. Now the desktop and mobile pages all use rel canonical properly, along with rel next/prev.

Bonus: Rel alternate for mobile delivered via the header response. What?!
This problem is pretty sinister, since it’s easy for a company to falsely believe it’s correct across all of their desktop urls. During an audit of a site using separate mobile URLs, I noticed that rel alternate was being delivered via the header response (for connecting the desktop URL with the mobile URL). That’s different from delivering rel alternate via the HTML, which most sites have in place.

An example of rel alternate being delivered via the header response on a site with over 600K pages indexed:
Rel alternate being delivered via the header response.
If you’re scratching your head now wondering why you haven’t heard much of this before, it’s because Google doesn’t support that method! So if you are delivering rel alternate via the header response to connect desktop URLs with their mobile counterparts, then you should change that as soon as possible. Instead, rel alternate should be delivered in the HTML or via XML sitemaps as documented in Google’s support center:

Two supported methods for providing rel alternate.

Quick tips based on helping a number of sites with separate mobile URLs:
As you can see, there are a number of mobile issues that can cause problems when sites get switched over to the mobile-first index (and those issues could even be causing problems now). Although I covered several important problems, I didn’t even cover content mismatch issues, missing structured data, hreflang problems, etc.

That’s why I recommend site owners take a hard look at their mobile setup now, before they get switched over to the mobile-first index. By identifying potential problems in the short-term, you can resolve them before they cause even bigger problems down the line.

Here are some quick tips based on helping a number of companies prepare:

  • Crawl your site to understand all potential problems at scale. And make sure you run crawls as both Googlebot and Googlebot for Smartphones. Look for problems with bidirectional tags, canonical tags, hreflang, structured data and content mismatch issues across desktop and mobile. This can take a while, but it’s extremely important.
  • Manually audit key sections and pages. Check for the correct technical setup. And don’t just check your desktop pages; check your mobile pages, too, and ensure the correct tagging is set up there.
  • View your site the way a mobile user would. You can do that in a number of ways, from emulating mobile devices in Chrome to using real mobile devices at your office. I have several phones for testing purposes, including both Android and iOS devices. The combination of emulation and testing actual mobile devices works well to ensure I know exactly how the site is being handled across phones and operating systems.
  • Review Google Search Console (GSC) to check mobile reporting. That includes the Search Analytics report and filtering by mobile devices versus desktop, checking indexation for your m-dot using the Index Status report, checking mobile usability errors, checking fetch and render, checking the robots.txt file for your m-dot versus desktop site, checking your hreflang setup, reviewing your AMP reporting and more. Seriously, there’s a boatload of data in GSC that can help you. Use it.

Summary: Make sure your m-dot doesn’t translate to m-not
Google will continue moving sites to its mobile-first index over time. Only a few sites have been moved so far, but that will surely change as we enter 2018. I recommend making sure your site is in the best shape possible by heavily auditing your mobile setup now. If you surface problems in the short term, then you can fix those issues before the switch happens for your site. The mobile-first index is a big change for Google, and for site owners. Don’t just think your setup is OK. Make sure it’s OK. Good luck.

GG

 

Filed Under: google, mobile, seo

Connect with Glenn Gabe today!

Latest Blog Posts

  • How to compare hourly sessions in Google Analytics 4 to track the impact from major Google algorithm updates (like broad core updates)
  • It’s all in the (site) name: 9 tips for troubleshooting why your site name isn’t showing up properly in the Google search results
  • Google Explore – The sneaky mobile content feed that’s displacing rankings in mobile search and could be eating clicks and impressions
  • Bing Chat in the Edge Sidebar – An AI companion that can summarize articles, provide additional information, and even generate new content as you browse the web
  • The Google “Code Red” That Triggered Thousands of “Code Reds” at Publishers: Bard, Bing Chat, And The Potential Impact of AI in the Search Results
  • Continuous Scroll And The GSC Void: Did The Launch Of Continuous Scroll In Google’s Desktop Search Results Impact Impressions And Clicks? [Study]
  • How to analyze the impact of continuous scroll in Google’s desktop search results using Analytics Edge and the GSC API
  • Percent Human: A list of tools for detecting lower-quality AI content
  • True Destination – Demystifying the confusing, but often accurate, true destination url for redirects in Google Search Console’s coverage reporting
  • Google’s September 2022 Broad Core Product Reviews Update (BCPRU) – The complexity and confusion when major algorithm updates overlap

Web Stories

  • Google’s December 2021 Product Reviews Update – Key Findings
  • Google’s April 2021 Product Reviews Update – Key Points For Site Owners and Affiliate Marketers
  • Google’s New Page Experience Signal
  • Google’s Disqus Indexing Bug
  • Learn more about Web Stories developed by Glenn Gabe

Archives

  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • August 2021
  • July 2021
  • June 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • GSQi Home
  • About Glenn Gabe
  • SEO Services
  • Blog
  • Contact GSQi
Copyright © 2023 G-Squared Interactive LLC. All Rights Reserved. | Privacy Policy
This website uses cookies to improve your experience. Are you ok with the site using cookies? You can opt-out at a later time if you wish. Cookie settings ACCEPT
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience. You can read our privacy policy for more information.
Cookie Consent