Welcome to the Q&A Forum

But...this won't affect his ranking in Google, Bing or Yahoo.  It might make his site look a little better to a potential acquirer, or someone he's trying to sell ads to.

Google PR will NOT be affected by these tactics.  And Google PR, as we see it in the toolbar etc., was last updated about a year ago, and Google has no plans to update it going forwards.

Those PR numbers in your examples are from last December...which tells me they're the PR values from the prior owner's site.

But the real PageRank that's actually part of the algorithm won't be affected either--they don't look at Alexa ranking.

I don't think there is any tactic happening. They simply are building lots of mini websites for their clients and messed up on no following affiliate links. it appears that they have not done any of the basic SEO audit work on their system. Nothing deliberate here IMHO.

So if I understand you correctly, your client who's penalized is www.starmandstravel.com, and you're seeing in their GWT backlinks list a ton of links from content.onlineagency.com/index.aspx?site=6599 and one or both of the other parameters are varying, right?

So then your question is:  where are the onlineagency pages linked from?

Well spotted, Travis!

ABSOLUTELY do NOT 301 anything from the old site to the new site...or you risk transferring the penalty!

I'm not sure what Google will do if you disallow via robots.txt AND 301.  Most likely, this is safe, Google will remove the old site from the index and ignore the 301s.  But I think there's some risk here that Google will read the pages anyway, see the 301s, and perhaps transfer the penalty.

Deleting the domain in webmaster tools will have no effect, other than to prevent you from seeing what Google thinks about the old domain :-/. Google will continue to index the old domain, follow redirected links, see duplicate content, etc.

2 years back....that's going to be right in the middle of a lot of Google algo changes, both Panda and Penguin.  It might be just a coincidence that your traffic drop was around when the hacking happened.

Have you done a backlink analysis?  It could be that the hackers also planted a ton of crappy links in the hopes of short-term getting your site to rank well for whatever they're trying to inject into your site and sell.

Sounds like you're doing the right thing with the URLs though.  To do a double-check on the duplicate content side, you could run Screaming Frog against it, and check for duplicate page titles and meta descriptions.  If your pages are getting spit out with multiple URLs, you'll see them all show up with duplicates.

Bonjour!  (I lived in Montreal for 6 years :-).

I do a lot of penalty recovery work, and you're in the same situation as a number of my clients: algorithmic penalty (probably), and you've disavowed links, but....no Penguin update for a year.

The next Penguin data update is mostly likely very soon, from mutterings from Matt at SMX Advanced.  It's been almost a year since the last one.  Your disavows won't take effect until there IS a data update.

I would wait for the data update, and see if you recover on rankings for the 3 terms you had in your footer links from client sites.  If you do, then great, continue on...

If not, then I'd be inclined to start a new domain, and move your content from your old site (and blog) to the new site, WITHOUT 301 redirecting.  Keep the old site running, but 301 redirect all of the pages to the home page....you want Google to successfully fetch all of those blog pages with the great content, but find it's permanently moved to your home page, where that content no longer exists.  This way your new site's content will not be seen as duplicate by Google (if you just 404 the pages, Google will presume the content is still as it was before it 404'd....FOR MONTHS).

It's worth going through all of the backlinks for the old site, seeing which ones are from healthy sites, and manually asking those webmasters if they'd kindly update their links to point to your new site.

What it really comes down to is this:  how deep does each of the link-reporting tools crawl?  In my experience (lately, from doing a lot of penalty recovery work for clients), I'm seeing GWT crawl a fair bit deeper than most of the other tools out there, so their number is going to be higher.

There's a lot of pages out there that really aren't content pages:  things like reply-to URLs, media-only pages in WordPress, standalone blog comment pages, etc.

When it comes to link juice, these kinds of pages have really almost nothing to give to a page they link to, so for the most part, whether you ignore the bottom 1% or bottom 10% of links to your site, you're not missing anything that matters.  The exception to this would be a penalty situation, e.g. where there's a bunch of blog comment spam on really, really weak sites....Google is going to want to see that stuff cleaned up, even though it's not really contributing anything of significance to PageRank.

You're on the right track.  Force it all to https, and keep the rel=canonical pointing to https versions.

Check out this thread of questions to Google's John Mueller on this topic:

Make sure you test very thoroughly before launching the https-only version: you'll run into issues with things like images, CSS, Jscript referenced via http instead of relative or protocol-free referencing.  Same goes for your internal links: you don't want to throw away a ton of link juice (even if only 5% at a time) because of 301 redirects from http to https that you could have fixed :-).

Did the layout of the header area change significantly?  If, for instance, the header area went from 1/10th of the "above the fold" area to 1/3rd, that might run the entire site afoul of the "topheavy" part of Panda.

For starters, I'd add the NOODP NOYDIR meta robots tags to your pages.  That tends to do a pretty good job of keeping Google in line (i.e. using your meta descriptions and page titles in the SERPs).

Recently I've noticed that Google will often attempt to extract your company name and prepend your page title with it. e.g. if your page title is "Purple Widgets - ACME Inc." and your URL is www.acmeinc.com, Google will show "Acmeinc: Purple Widgets" in the SERPs for your headline.  This seems to be new as of a few months ago, and NOODP NOYDIR doesn't seem to stop it like it used to.  But I'd try NOODP NOYDIR because it does USUALLY still seem to have the effect you're looking for.

Why bother trying to clean anything up?  If somewhere out there there are links to your domain, and they're 404'ing, just 301 them to new pages on your site!  Capture that link juice, don't let it run out

I'm not sure why this is happening, but I did notice two things:

#1 many of the 76 pages are "sorry nothing found" pages, that probably ought to be returning 404s

#2 you've got illegal characters in your URLs, which might mess up crawlers etc.:

http://www.mycity4kids.com/Bangalore/activity-based-approach-<near>-west-bangalore?locality=rukmini-nagar

Here it's showing as %3C when I paste it but it's a < sign in the address bar.  It might seem to be working OK, but I'd guess you're on thin ice with this.

Hi Stephan,

Presuming the expand/collapse thing is done properly, it should be golden.  You'll find a lot of sites use this approach when they have multiple pages of content, e.g. a product page with specifications, reviews, technical details, etc.

I do this on my travel website.  A great way to test to see if the initially-collapsed content is being seen and indexed by Google is to take a block of text from the collapsed section and search for it in double-quotes.

Here's an example:  search for "At the Bora Bora Pearl Beach Resort you can discover the sparkling magic of the lagoon".  You'll find my site there at #3 (Visual Itineraries), along with the other 1000 websites who've also copied the resort's description straight from the resort's website (yeah, I really shouldn't do this).  So much for Google's duplicate content detection when it comes to text chunks...BUT I DIGRESS.  That content you see is on the More Info tab.

Now, on to what "done properly" means:

• each tab should be in a separate div
• assign all divs a class which has style="display:none;" EXCEPT the currently selected tab
• have onclick handlers for the tabs that set all of the divs' classes to the display:none class, and then set the newly selected tab's div class to one with display:block or display:inline

And not done properly would mean something like changing the text of a div with Javascript onclick()....because Google won't see that text in the Javascript.  It's got to be in the HTML.

That's about it.  Not so tricky, really.  And works well both for usability (no roundtrip to the server, not even an Ajax fetch!) and for SEO (lotsa yummy content on a single page for Panda).

I'd say the answer is:

Possibilities:

1. The layout of the product pages for the new shopping cart is pissing off Panda.  If that's the case, the traffic to the home page shouldn't have changed much, but the product pages will have dropped.
2. Panda now sees the pages in general as having less content than before, perhaps images aren't getting loaded in the pages in such a way that Google sees them whereas they were before, something like that....and Panda now thinks the entire site is less rich in content.
3. It often seems to take Google a month or so to "settle out" all of the link juice flows when you do a bunch of redirects, have new URLs, etc. I would expect that the link juice calculation is iterative, and that would be why it would take a number of iterations of the PageRank calculation in order for entirely new URLs to "get" all the link juice they should have.
4. Their backlinks were moderately dependent upon a set of link networks, and those link networks have shut down all their sites (so that neither Google nor Bing still see the links from them).

Those are the ideas that come to mind so far.

Sort of.  It's per page, not per website.

I don't think you'd run afoul of Google by doing this, as long as you kept it to one (or a small handful, say, less than 10) satellite sites.  And if those sites can rank on their own for terms, and "feed" leads (not links) to the commercial site, then that might be a good strategy.

But the question really is, I think, is it worth the effort for the link juice that eventually trickles down to the commercial site, right?  Think of it this way: how much would your rankings change if your commercial site got 1 link from the city newspaper's site?  It'd probably make a difference, sure...but probably not massive (unless that was the only decent strong link you had).  Now....how much content marketing and link-building would you have to do to get your satellite site to have the same domain authority as the city newspaper's site?  Ummmm....a lifetime's.   Well, probably 10-20 years anyway.  So the answer really comes down to this:  you can do a TON of work on the satellite site, and you're never going to get as much benefit from that work as you'd get from getting your local newspaper to do a story on your company.  Or get quoted by a reporter in it (speaking of that....check out HARO...as long as you just respond to real reporters writing for real publications).

My question would be:  why do you want to use schema.org markup for attributes that Google doesn't currently show in the SERPs?

The answer might be: because I think that Panda might see schema.org markup as a good quality signal.  And I'd tend to agree with that....but, if that's the case, why not use schema.org/Organization or schema.org/LocalBusiness for your company info in the footer of every page.  You're giving Panda a happy little tasted of schema on every page, and don't sweat the regulators or blazing the trail on new schema attributes

FYI you could also mark up any blog posts or articles you write for the site with http://schema.org/Article as well.

If you're looking at the page that shows the sitemap submitted, then it's showing how many pages from the sitemap are indexed.  Be sure to look at the Index Status to see the total indexed there.  It might be different...

HOW CAN THAT BE?  You say....

Here's a problem a client of mine ran into recently.  Their sitemap generator was outputting all URLs in lower case.  The site itself linked to all URLs in mixed case.  TECHNICALLY, /happyhour.html and /HappyHour.html are different URLs....whether or not your webserver is set up to be case-sensitive.  But what Google saw was a list of 160,000 URLs (all lowercase) in the sitemap that it never saw itself when it crawled the site.  However, it found 160,000 OTHER URLs (all mixed case) when crawling the site, and indexed those just fine.

This could be what you're seeing.

If it's not, then I'd say Google really doesn't like the content on the majority of those pages (or they're 404'ing, 500'ing, or blocked by robots.txt or something like that).

I presume the other countries are using the same language--if that's the case, then the next question is: is anything on the page going to be different for countries #2, #3, etc.?

If the answer is "no", then you can use rel=canonical on the pages for countries #2, #3, etc. pointing back at the version at your site for country #1.

If the answer is "yes" (e.g. the price is different, or the currency is different, or shipping price shown is different, etc.), then set the rel=canonical to point to the URL for the current country's page.

In both cases, you'll want to use rel="alternate" hreflang= tags for ALL of the countries....on ALL of the pages.  The idea here is that you're telling Google, on every page, what the other countries' versions of the pages are.  Included in that is the page for the country you're looking at now.  So, let's say you had www.bananas.com and also a version of the site in the United Arab Emirates, www.bananas.com.ae.  You've got pages www.bananas.com/peel.php and www.bananas.com.ae/peel.php.  BOTH of these pages would have:

For more info on this, check out Maile Ohye's video here.

I would update the meta descriptions, page titles, meta keywords, and the body content to eliminate the stuffing.

You shouldn't see a drop in ranking by removing extra keywords from the page titles.

While I agree in general with what the others  have said, I would say that the new MozLocal is worth pursuing for this, at $49/year.  Presuming you have your G+ page set up correctly with your business address, a local phone number, etc., it'll take you just a few minutes to make the CSV file and submit it.

Very strange.  I looked at the redirect chain with httpfox, and all looks correct, with a single 301 to psg1.com.

I also looked at the source for www.psg1.com/ and all looks fine, including your rel=canonical.

I checked your robots.txt to see if maybe you had somehow disallowed your home page or something like that--but no, it's clean.

Makes me think you have a penalty perhaps on your home page?  Is there anything in Webmaster Tools?

It's definitely a Google-only issue, as I'm seeing psg1.com come up in Bing.

Hi Carl,

I do a ton of penalty recovery work, so I've got some experience here.  I would disavow those, whether there appears to be a penalty or not.  What's probably happening is that your client has a Penguin penalty for specific keywords...but, you don't really care, since you don't ever care to rank for those terms anyway.  But what you want to prevent is that mass of backlinks causing a manual review and then getting a penalty that takes time and effort and loss of traffic to get past.

What might have happened, by the way, is that the client's site might have been hacked at one point to do a redirect to a site that actually is selling replica watches.  The technique there is to take a site with a decent backlink profile and redirect a page on the site by injecting Javascript or a meta refresh into the source.  Then, building a mass of spammy links to get that page to rank because of anchor text and drive traffic through the victim site to the site that's selling whatever.  I've seen this done to WP sites (including one of mine...sigh) before.  Typically it's a short-run strategy, as pretty quickly the site owner realizes their site is compromised, and fixes it.  In the case of my site, there was a server in China that reran its hacking script to reinstall the redirect crap every 30 minutes or so.  So I'd fix it, and half an hour later, it'd be back. Took me a long time to figure out how to block the vulnerability they were exploiting.

For the schema.org markup, you'll find Google's schema tester here.

I would use schema.org/LocalBusiness but you can see an example of how to do the markup on one of my sites.  Start at line 447 of the source where you see schema.org/Corporation, and use LocalBusiness instead of Corporation.  I think most of the other fields will be the same, but refer to the link to schema.org/LocalBusiness above to be sure.

In my example, I've used a CSS class schemaorghide that's got display:none in it, as while I want to include a bunch of these fields in the schema I show Google, I don't necessarily want to show all of them in the footer (and note that some of the fields are elements of multiple entities within Corporation, so I don't want to show my phone number twice, for instance).

Pay attention to all of the places you see itemscope or itemprop.  And it's all done where you see the comment:

Oops, good catch Paul, you're correct!

Caroline,

REMOVE THE DISALLOW LINE.

I am concerned that that line will match all URLs on the site, and disallow the ENTIRE site.

Michael.

Definitely put your address and phone number in your footer, and use schema.org/LocalBusiness to mark up those bits as well.

My advice is to go easy with robots.txt--it's a bit like dynamite, powerful, but can take your leg (or entire website) off.

I like this checker:

http://tool.motoricerca.info/robots-checker.phtml

If you look ok after running that checker, then use the built-in Google one.

Note that robots.txt syntax DOES NOT have wildcards.  Apparently this doesn't stop a ton of people from using wildcards in them (to no effect, and clearly they didn't bother to test!).

Another reason to avoid disallow in robots.txt is that if you disallow the engines from looking at a page's contents, then you're ALSO stopping the link juice that might have flowed to other pages it links to.

So let's say you have 100 pages on your site that you're currently blocking with disallow in robots.txt.  If instead, you put a meta robots "noindex,follow" in each of those pages, then every page linked to from those 100 pages (i.e. everything in your main menu) would get an extra 100 internal links worth of link juice.

I'd be really, REALLY careful about a disallow statement like that: you run the risk of disallowing your entire website.

FYI I'm not sure putting a crawl delay in your robots.txt file is the right answer.  I saw an example a week or so ago where Google (I think, but maybe it was Bing) explicitly said somewhere that it had ignored the crawl delay in the robots.txt. I would specify the crawl delay in Webmaster Tools instead.  It's hard to find, but it's there

• in Webmaster Tools, select the site you want to set the crawl rate for
• click the Gear icon in the upper right
• you'll see the option there to set the crawl rate

Hi Chris,

With any calendar plugin or widget you're looking at, you can use the Moz toolbar's highlighter to instantly show you whether the links in the calendar, or event descriptions, are followed.  That's the first thing to check out (I don't know if Google Calendar links are or not).

Something else to look at with calendaring is that apparently it's pretty easy to get rich snippets and nice placement in the SERPs if you mark up the events with schema.org/Event markup. You'd probably want to put that markup on the individual event pages, of course, and NOT in the calendar itself.

Third consideration: you'll want to be very careful about how many clicks it is from the home page to the individual event pages, and to try to minimize that.  For instance, let's say you care about ranking for the name of a big event to be held in August 2014 now....and, to get to that event from your home page, you had to click:

• Events (then it shows March 2014 calendar)
• next month
• next month
• next month
• next month
• next month
• [name of event]

That'll flow piddly amounts of link juice to your August event's page, and your rankings will really suck.

You might address that by adding links to the next 12 or 24 months calendar pages from the main Events page...or, even better, if Events is a main nav pulldown, have each of the next 12 or 24 months in the pulldown, so that the August 2014 calendar page gets a link from every single page on your site.

Internal link juice flow can make a massive difference to rankings, indexation, etc. so pay attention to this stuff

Cheers,

Michael

Hello from a fellow (well, ex) BC'er!

I think your issue is simply a lack of backlinks at this point.  Did you submit an XML sitemap to Google?  That will help a bit.  Also, be sure to register in all of the local business directories--check out this post on the Whitespark blog to see the Canadian business directories that matter to Google.

Your site looks very nice, by the way.  Very professional and it looks like the images are yours (I presume Amanda Parker is related to your business?)

FYI, the "boost" sites get for an exact or partial domain match to the query seem to take a long time in Google--up to a year, last time I built exact-match sites (that was a couple of years ago).  Yahoo and Bing was quicker.

Cheers (Kokanee, of course),

Michael.

I would update the pages to reduce the keyword stuffing.  You run the risk of getting penalized (and not knowing it), basically because Panda's evaluation of the quality of the page is likely going to suffer.  While we don't know exactly whether or not measuring keyword stuffing is a part of Panda, I believe it's extremely likely because:

• it was a heavily used spam technique for so many years
• it's really easy for Panda to measure algorithmically

As well, conversion rates for real customers who land on the page will do better with un-stuffed pages.

If you're not under a Google penalty, I wouldn't bother getting the links & listings removed.  I don't think they're hurting you.  I expect that once you add NOODP NOYDIR the problem will go away in a matter of days.

You're also here with that description:

• http://www.top20.md/int/info/raworthscouk
• http://uk-directory.co.uk/United_Kingdom/England/North_Yorkshire/Harrogate/Business_and_Economy/Legal_Services/index.html
• http://www.the-arena.com/matrix_smartlist.aspx?sid=1164145
• http://www.inonesearch.com/?cid=00000522741
• http://www.lawyersdirectory.co.uk/law_links/Find-a-Solicitors/North-Yorkshire-Solicitors/index.html

FYI it'll probably help a lot if you add NOODP, NOYDIR to your meta robots like Pete says

Michael

.htaccess processes requests received by your webserver.   It doesn't process HTML sent to the client, so it can't affect those affiliate links.

You have two options:

1. Set it up in IIS Manager (best option, least overhead for the server, need no coding skills)
2. Code it in classic ASP in a global include file that all pages reference before sending content back to the browser.

Here's a great article that walks you through the IIS config option.  For this, you need access to IIS Manager:

http://www.proworks.com/blog/2010/02/11/adding-a-301-redirect-in-iis-for-individual-pages-with-non-aspx-extensions/

Sounds like that option is unavailable to you however.

For the other option:  your site probably has a file or two that's included at the start of all web pages.  (If not, you can add it).  In that file, you'll want to check the URL passed in like this:

Dim sThisPage                = Request.ServerVariables("SCRIPT_NAME")

If (LCase(sThisPage) = "/oldpage.aspx") Then

Response.Status            = "301 Moved Permanently"
        Response.AddHeader        "Location", "http://" & sThisServer & "/newpage.aspx"
        Response.End
End If

Hi Anders,

I would expect that Google would see and understand the jquery menu links.  They've been able to find links in simple Jscript for several years now, and certainly jquery is one of the most common libraries out there, so I'd be surprised if they're not already all over that.

MC

I agree with Keri...there are a ton of factors that all contribute to ranking for any given term.  It's possible to rank well based simply on a few of them, if it's not super-competitive space.

I'd agree with Keri on this one.  If you want to start with a fairly inexpensive investment to see how bad the problem is, buy a subscription to Link Research Tools and run a Link Detox report on your site.  If you get a pretty bad result, then go to the Moz recommended list to find someone with experience identifying and getting you out of penalties.

By the way, if your site has ANY visibility at all, you can expect an automated attack on the WP admin login maybe once an hour.  All day, every day.  So, if you leave your admin account active, and give it a password that's in the dictionary, you'll be seeing injection scripts in your home page and you'll be the proud assistant distributor of various pharma products within a month or two :-).

Right now, I'm seeing so many scripted attacks from China, I blocked all China IP addresses from my travel website.  I was seeing hundreds to thousands of attempts per day before that.

This:  http://moz.com/blog/the-definitive-guide-to-wordpress-security

No.  The expires directive is merely there to tell the browser "this content is at least good until date X", so that the browser doesn't need to fetch it if it's got it cached.

So let's say you've got a dynamically-generated page called widgets.php, and it pulls a list of products, latest pricing, availability etc. from the database.  Let's say you style the page with an external stylesheet.css, you've got some awesome wacky UI stuff in Javascript in an external wackystuff.js, and your images for navigation on the site are in /img/nav (but product images, which maybe can change more frequently) are in /img/products.

You might NOT set the Expires header on your .php files and folders, as those should be considered to expire the second after the browser fetches them.  You might set the Expires header for the CSS file to a week out; same with the JS and the /img/nav folders, as those only change with a major update to the site.  You might set the Expires header date for the /img/products folder to maybe an hour or two, so that if a person is flipping back and forth between pages, the browser will use the cached product image for a little while before forcing a refetch of it.

Make sense?

You've definitely got a lot of links in there in your navigation, but I don't think it's really going to hurt you. It's doing to distribute link juice pretty evenly across all of the pages linked to from that left-hand menu and the submenus.

You MIGHT consider reducing the left menu to just the main categories, and NOT including all of the submenus.  That would funnel a fair bit more link juice to the main categories, and the submenus I'm guessing are all pretty long-tail anyway, so they shouldn't need as much.

I don't see a duplicate content problem here.  I'm seeing different content on every page.  You might consider putting noindex/follow on some of the intermediate pages that merely list subcategories, like this one:

http://dorchdanola-netbutik.dk/category/belysning-el-artikler-485/

These kinds of pages will be seen as extremely content-light...and that's not so good.

I wouldn't nofollow your social media links. And rel=me mostly you use to link an author page back to your G+ profile, so I wouldn't use that here.

I agree, that's a great approach.  I think you mean Javascript, not Java though (that's a different language).  The only thing that might make this approach a challenge would be if you had so much product data before filtering that it caused a performance problem, i.e. let's say you had 50 pages of results...if you filter server-side, you're only sending down 1 page of results, whereas if you're filtering with client-side Javascript, you've got to send all 50 pages down and then filter it in the browser.

Cool, looking forward to the ad-hoc query tool!

I've been seeing a fairly long time for Google to catch up with 301s and pass along the link juice....a couple of months.  Consensus is that something around 90-95% of the link juice passes through a 301.  There's some talk about 301s not passing link juice forever, although I haven't heard any evidence of exactly how long that might be, but seems like it would be in the 1-2 year range at least.  Just my opinion & recollection of a whole bunch of other people's opinions though :-).

Greetings from Portland

The way it's built in the HTML looks good to me right now--this will give you a page with a high content density (and nice rich content too, with those videos).

But remove the other direct links to the other tabs, e.g. tree-logistics....that WILL cause you to have a duplicate content problem.  I would 301 redirect those other pages to the main page, after removing the other links.

Oh, and get those videos out of YouTube and put them on Wistia, and then embed them, and use Wistia's generated video sitemap.  You'll then stand a chance of getting a video snippet for some of your search results, which is great for click through rate :-).

See Sir Phil's treatise on video SEO here.  Phil's The Guy when it comes to video SEO.

That's a good question...I've not seen a tool that magically does all of that, but certainly Moz could get that from the data they get when they crawl.  I'll pass along that idea to Jon White.

I would use this tool myself during site audits, when I'm looking to see if the client's site has subdomains other than www that might be worth consolidating onto the www subdomain.

Today, I do it arduously with Google site: -inurl queries, e.g.

site:acme.com -inurl:www -inurl:blog

and then when I see a new subdomain appear, e.g. news.acme.com, then I append -inurl:news to the site: search.

This doesn't work if the client has decided that the www-less version of their domain is their preferred one...in this case, I'm totally SOL.