Welcome to the Q&A Forum

Google testing tool seems to be showing a Software Application schema but not the reviews. When I pull out just the review source code, it's saying that the item being reviewed is missing. Honestly, though, trouble-shooting these can be tricky sometimes. I'd check the tool, though, and just take a look at the errors:

https://search.google.com/structured-data/testing-tool/u/0/

It is possible to have the schema correct and still not get reviews, though, if Google simply decides not to display reviews for that SERP. I'm not seeing anyone with reviews for the first give pages of that query, so that's a solid sign that this may be more than just mark-up. Google seems to ramp up and scale back which queries get reviews all the time, and there's no way to track that (other than their presence/absence). Most you can do is double-check the code and hope for the best.

Sorry, I know that's not a very satisfying answer.

Oh... argh. Yeah, that makes step one easy. In some cases meta refresh acts like a 301 (if it's set to 0 seconds), and in others it doesn't, and there isn't a lot of rhyme or reason. Get the page-by-page redirects running, and you may see a pretty quick positive impact.

Can a .ly domain rank on Google.com? Sure. Here are many that do:

https://www.google.com/search?q=site%3Aly

Do they have a ranking disadvantage? That's a lot tougher question. It's definitely in a gray area. Thanks to Bit.ly and some others, there is some precedent for these domains to be treated as generic, if other signals suggest they are not Libyan domains (geo-location, language, etc.), but there's always more risk for a new site and a chance you'll need to spend more to get the same results.

The political situation is much more worrisome, though, because none of us can predict that. If there's a history of .ly domains being confiscated and if that confiscation was considered legal (even in the short-term), then there's no guarantee that won't happen again. That's a risk we can't calculate in SEO terms. The fact that even Bitly eventually went to bitly.com doesn't bode well.

My gut feeling is that (1) there are no magic domain names, and you're going to have to advertise/market/promote any new domain, and (2) given the geo-political situation there is more than average risk (vs., say, a .co domain or one of the new TLDs). There's a lot I don't know about your situation, but I think your hesitation is warranted.

There's no way to reverse proxy and hide that sub-domain? Ideally, a CDN for content itself would never be seen by the crawlers. If people are going to actually see this sub-domain and potentially link to it, then you're probably going to have to use cross-domain canonical. That's not an ideal solution, though - ideally, the CDN should be invisible to Google and visitors.

I just see a lot of stuff that's of questionable quality, such as:

http://www.squidoo.com/how-to-turn-power-off-usb-port-on-windows-computers

http://www.hathmaluwa.org/ (multiple links)

http://shetoldme.com/Technology/Google-puts-stop-to-accidental-porn

No single link would be enough to put you in penalty territory, but the profile as a whole looks weak to me, honestly, and once I see a pattern of quality problems, I start to worry.

You also seem to have a redirect in play from www.thespicygadgematics.com/ - any link issues to that site could be effecting this site as well.

It is possible to get a Google Drive document indexed, but I'm not clear what this would accomplish. It would likely be a weak link (Google knows this is possible and that Drive documents are user-controlled) and it ultimately means that you're competing with your own documents for ranking. So, now you've got state pages on your site and state pages on Google Drive, both in the index, and one is potentially cannibalizing the other. I think this would ultimately be counterproductive, honestly.

I'll be brutally honest - the Panda updates have been very unkind to this sort of geo-targeting. Five or more years ago, spinning out hyper-local pages that were similar (search results + a few keywords changed) was popular and relatively effective. Now, Google views it as thin content. In the past, the worst they might do is ignore it. Now, they may penalize the entire site, if taken to extreme.

Personally, in 2013, I wouldn't do it at all. The rewards are very small, and the risks are surprisingly high. Is suspect that situation will only get worse. It's fine to have these pages for visitors, but I'd leave them out of the index. If geo-targeting is important, then focus on a few pages (maybe the state level or major markets) and try to build out some unique content for them. Without digging into your site, my gut reaction is that 300+ is dangerous.

I haven't seen the specific Educational Organization schema have an impact on SERPs, but they're diverging so much lately that it's hard to say. There are some specialty carousels like this:

https://www.google.com/search?q=best+colleges+in+wyoming

...that could be using it, but I suspect this is coming from the broader Knowledge Graph. Individual colleges have Knowledge Panels, but a lot of that data is coming from GMB listings, best I know.

There's no real harm, if the data is appropriate and well-structured (i.e. you're not putting a university mark-up on a sandwich shop page). The drawback is basically spending the time and energy and getting nothing in return.

I guess the other drawback is that Google could use that data to feed its own internal database but not give you anything in return. That's a drawback of basically everything in SEO right now, though.

I'm seeing 200+ links in the source code for the home-page. From a usability standpoint, my first instinct is that this is overwhelming. If you're a big brand or major news site, you might be able to pull it off, but most people just can't digest this many options on a site they aren't familiar with, and you risk that they'll just give up and leave.

From an SEO standpoint, though, it's mainly an issue of dilution. The more pages you link to, the less internal PageRank gets passed to each page. If you have a lot to go around, that may be fine, but for most sites, you'll spread yourself too thin. Essentially, you're telling Google that all of these pages are important. A hierarchical approach can help signal the most important pages and can help Google prioritize (both in terms of crawl and ranking).

I don't believe that there's a hard cut-off at this point (the 100-link rule was based in technical limitations that no longer exist), but I do agree with Thomas that crawler fatigue is a real issue that can negatively impact your site.

Unfortunately, I haven't seen any studies of that nature. I typically look at it pragmatically -- is there a change in SERP features related to that schema (i.e. is there direct, measurable benefit)? So far, I haven't seen any. On the other hand, I don't see any evidence of harm, as long as the schema is appropriate and well-structured. It just comes down to where you want to put your time/effort.

I don't understand the point of the external domain, either - I tend to agree with you that sub-folders would be perfectly fine here. Unfortunately, there are two issues at play:

(1) You've got to direct the short, marketing URLs to the main site URLs. That's a relatively easy - you could either use rewrites or redirects (rewrites are probably better for humans, in this case). Google can't generally index URLs that are on printed materials, TV ads, billboards, etc. (unless people start linking to them or promoting them on social), so your SEO risks are pretty minimal. The safest bet would be a straight 301-redirect.

(2) The other issue is the long/ugly URLs on the site in general. If you want to move the entire site to the short URLs and then use those short URLs for marketing, that's great, but then you'll need to 301-redirect the entire current site. There are definitely risks to that approach, and I'm not sure it's necessary here. The benefits really depend on the scope of the current site and whether the URL structure is creating problems, like spinning out duplicate pages. You could also potentially use rel=canonical to solve some problems, but again, changing your site-wide URLs involves risk.

I wrote more on (2) here:

http://moz.com/blog/should-i-change-my-urls-for-seo

You can't really "optimize" for Hummingbird, but understanding RankBrain can certainly help you do keyword research and write relevant content better.

I'm not seeing that source code on your home-page, but the problem is usual links that are hidden in some way, such as drop-down menus or scrolling images. For example, each picture that scrolls by at the top has its own link. Only one is visible at a time, but Google sees them all in the source code simultaneously. There's nothing necessarily wrong with that, but they do all count. Once you start adding these up, the numbers can go up fast.

Don't have an exact date, but the UI feature is relatively new. I agree with @effectdigital that this is a general capability that Google has been building/expanding for a while. It's helpful to look at that underlying logic, as it will spawn new features over time.

One thing I'd suggest is potentially trying a click-mapping tool like CrazyEgg, to see where your home-page is getting traction. We all tend to over-estimate the user value of our own content, and what you'll often find is that a small percentage of your links are getting most of the activity. If you find that 2-3 sections are getting no love at all, it's a lot easier to start cutting based on that actual usage data.

Yeah, it gets ugly fast, and even done "by the book" you're often going to need to monitor your index and make adjustments, I've found. That said, the official Google stance (at least the last I heard) is that you should canonical to the page with no parameters and rel=prev/next to the parameterized versions (your 2nd-to-last example):

• rel canonical = example.com/for-sale/stuff1?page=30
• rel next = example.com/for-sale/stuff1?sortby=date_added&page=31
• rel prev = example.com/for-sale/stuff1?sortby=date_added&page=29

See the bottom of this Google blog post:

http://googlewebmastercentral.blogspot.com/2011/09/pagination-with-relnext-and-relprev.html

The other option would be to use rel=prev/next on the paginated URLs and then dynamically Meta Noindex anything with parameters. Honestly, it really depends on what works, and it can take a while to sort out. Also, keep in mind that Bing doesn't handle rel=prev/next quite the same way as Google.

I tend to agree with Sorina - in a perfect world, it would be great if you could somehow vet that content and make sure it stays safe for your users (even crawl the sites offline if you need to). What content does the page have around the iFrame (if you can explain it generally without giving away private details)? I'm wondering if these pages should be indexed at all, malware or no, since they're mostly just re-displays of other people's content. META NOINDEX might be a better bet here.

Given their history, two domains with overlapping content and a similar name seems like a terrible idea to me, to be blunt. If this really is a Panda issue, then you're potentially going to aggravate the situation and send out even more low quality signals.

It's hard to speculate, but I've seen a few situations where what seemed like Panda turned out to be something deeper. Directory clients have been hit hard, for example, as Google just seems to be devaluing the entire space (along with price comparison sites, many types of affiliates, etc.). I'm not talking about spammy sites, even, but the ones that provide some original value. It's just that Google doesn't see them as the end-supplier, and so they're getting discounted.

An end-run to a new domain isn't going to fix this. I strongly suspect that you've got something deeper going on that may take a radical overhaul of the main site and even the business/brand. I think it's better to accept that now than continue a gradual decline over the next couple of years.

Technically, it should be ok, but this is a scenario that behave unpredictably, and it's why many mobile SEO folks seems to be recommending more and more moving away from alternate domains. You're doing it the way Google recommends for your situation, as far as I'm aware, but I would monitor the situation very, very carefully, and make sure that there's not crossover or duplicate content issues.

It's a bit technically challenging, but you may also want to make sure that Googlebot-Mobile is hitting the proper site. See this advice:

https://developers.google.com/webmasters/smartphone-sites/redirects

Sorry you're stuck in that spot. I really would be worried that this "fix" would make life worse for everyone, but it's tough to come up with solutions that don't seem like band-aids. Best you may be able to do is get more aggressive about the de-indexation, focus on improving some core content, and maybe re-work the internal linking to focus more on key pages (and spread internal PR a bit less thinly).

Is there any compelling reason to index this content? It's probably going to look thin to Google, at best (since it's mostly a wrapper around an outside site), and the search value is pretty minimal. In other words, it's good for your users and possibly conversion, but it doesn't have much value for search visitors. If the page is really just a wrapper around a demo site, then I'd consider using META NOINDEX on the frameset and just keep those out of your search results completely.

So, it's not indexed, but you're still get malware warnings? That's odd. Honestly, Google shouldn't even see something in a frame as directly being part of your site, in many cases. If you 404 those pages, you potentially kill them for visitors, too - on the other hand, you probably shouldn't be sending your visitors to frames with malware. If it's just a few, I'd probably 404 them temporarily - it'll protect your rankings and your visitors. I'm honestly not sure if the 503 is going to do much that the NOINDEX isn't doing.

Sorry, I realized my comments about the 503 were kind of confusing. A 503 shouldn't serve a page for visitors, either - it's just a matter of 404s sometimes seeming a little more friendly, from the user perspective. It just depends on how you're set up.

My only other concern about the 503 is that it's generally intended for short-term use (at least it's been implemented that way). It's great if your site is down for a day and basically tells Google to come back later. If you leave one up for weeks or months, though, I'm honestly not sure what will happen. It's probably going to be treated like a 404, but it also could signal to Google that you have technical problems on the site. So, it may depend on the timeframe. The problem here is that you don't control the malware - it could be weeks before the 3rd party takes action.

I tend to agree with Karin. On the one hand - yes, this could be seen as duplicate/thin content, especially at large scale. On the other hand, I'm not clear on what your goal is or which set of pages is more important. Think about the business case and where you want to bring users, not just the SEO aspect. Why do both of these pages exist, and what are you trying to achieve?

Agreed - Google seems to be ok with setting a rel-canonical to the "View All" page. Don't combine this with rel=prev/next - both methods are ok, but either use one or the other. Using both sends a mixed message about what you want to have indexed and ranked.

Real-world data about rel=prev/next is hard to come by. I know SEOs at big companies who have done testing, but it's really unclear how Google honors/indexed paginated content with rel=prev/next in place. My gut feeling boils down to this:

(1) If you can reasonably build a "View All" page that loads quickly and is a decent user experience, go ahead and rel=canonical to that page. It's just easier, all-around, and rel=canonical is a more powerful directive.

(2) If that isn't feasible, and/or if you want individual search pages (2+) to have the ability to rank, then use rel=prev/next.

So, I can tell you from conversations with SEOs that some have used rel=canonical successfully to pass link-juice. In some cases, I even know people who use it to move sites, and then 301 later, and claim success with this method. Unfortunately, almost none of those case studies are published.

Generally speaking, I still don't think it's a great way to move a resource, and tend toward 301s for that purpose, but all the data I've seen suggests that rel=canonical tends to consolidate link juice. There are exceptions, of course, such as when Google doesn't honor the tag (they don't see it as a duplicate, for example, and think you're trying to game the system), but that's true of 301s as well.

Rand did a Whiteboard Friday a couple of years ago talking about link-equity and cross-domain canonical:

http://moz.com/blog/cross-domain-canonical-the-new-301-whiteboard-friday

I know he's actually a big believer that rel=canonical passes link equity, as or more strongly in some cases than 301-redirects (again, it's pretty situational).

Yeah, cross-domain canonical tags are probably your best bet. They'll tell Google that the copies are duplicates. Please note that they'll also keep those copies from ranking, but in most cases that's better than the risk of 5 sites all sharing the same content (which can easily get you into Panda territory).

When you say 7,000, do you mean that you have 7,000 links on each page or that 7,000 pages show a "too many links" warning? I'm having trouble resolving 7K with your other numbers.

Ultimately, it's a balancing act, as I wrote about a while back:

http://moz.com/blog/how-many-links-is-too-many

The more links you have, the less love each page you link to will get. It's not just SEO - it's anything. The more options you give people, typically, the less attention each option will get. So, it's a balancing act. Highlighting more options might get link equity to more places, but it'll be spread thinner. There's really no way in 2013 to get around that.

On the usability side, I'd only ask this (from many prior experiences) - do you have data to back up that these links are very important for visitors? I've found many times that, once we did user testing or click mapping (like Crazy Egg), "essential" secondary navigation links turned out to be rarely used. Even now, many visitors to many site (especially non-technical sites) don't really understand or use dropdowns, especially multi-level ones. Too often, these links are important to management, not the actual visitors. I don't know your audience or your site, so I don't mean to make assumptions, but I'd strongly encourage you to collect that data, if you haven't.

As Miki said, if you're generally ranking well, and if these links really do have user value, then I wouldn't do anything drastic. There may be ways to prune a few non-essential links or maybe fine-tune your information architecture, but slashing away at them may do more harm than good.

Just checking in - has the situation improved in the month since you posted the question? I tend to agree with Thomas that it's usually just a waiting game, assuming the 301-redirects are working properly. It never hurts to use a header checker, just in case (it's amazing how often redirects get implemented poorly).

You could re-create the old sitemap if the transition is stalled. I'd avoid actively removing the old URLs, as that could interfere with making sure the link equity from the old URLs passes to the new ones. The only issue would be if you suspect duplicate content problems are harming you.

The devil is in the details on these situations, and it depends a lot on the size of the site, etc.

I'm not sure there's a one-sized-fits-all answer. If the .com is more geared to an audience outside of Singapore, and the .edu.sg site is more geared to the local audience you could set a region and/or language with rel="alternate" hreflang:

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

This is a bit more subtle canonicalization signal that Google can use to sort out sites with language and/or regional copies (the regional aspect may be relevant even if both sites are in english).

The next question would be: where does your traffic come from? If you want to consolidate, but most of your traffic is coming from outside of Singapore, then I'd probably stick with the .com - it still has a "generic" status. The .edu.sg may rank more strongly in Singapore but fall off everywhere else.

I wouldn't worry much about the DMOZ link, especially if you have a solid link profile. DMOZ links have gotten buried over the years and typically don't carry nearly the value most people think. At some point, they could be a solid boost to a new site with a small link profile, but I think even those days are well behind us.

Happy to help - hope it does the trick.

I'm checking with Dr. Matt Peters, head of our Data Science team. It's less about secrecy and more that DA/PA are based on machine learning and have gotten a bit complex. Still, I suspect we can give you a general sense of how DA/PA pass through links. Posting this because I suspect an answer may take a day or two.

Unfortunately, that's a lot more tricky. If you're trying to rank both the .com and .sg version for, let's say, US residents, and those sites have duplicate content, then you do run the risk of Google filtering one of them out. If you use canonical tags or something like that, then one site will be taken out of contention for ranking - in that case, you won't rank for both sites on the same term. The only way to have your cake and eat it too is to make the sites as unique as possible.

Even then, you're potentially going to duplicate effort and cannibalize your own rankings, so it's a risky proposition. In some cases, it may be better to try to promote your social profiles and other pages outside of your site that have some authority. It doesn't have to be your own site ranking, just a site that's generally positive or neutral.

Rankings are a lot less stable than they used to be, so I think those days of cleanly seeing differences across data centers are pretty much gone. This is something I deal with a lot in the MozCast project, and today's ranking, even across short time periods on a single data center are pretty volatile, especially for keywords with a news/QDF component. I wrote a bit about it a while back:

http://moz.com/blog/a-week-in-the-life-of-3-keywords

Sometimes, different data centers will show things like features that are in testing and they may have regional differences for locally sensitive queries, but the index itself seems to propagate pretty quickly these days.

If that's your site, I'd at least nofollow it, and probably remove it. Not sure you should disavow your own site, though.

LinkDetox and similar tools can help you spot these links, but I'd really recommend going through them by hand. You're probably going to have to kill off or at least disavow some of the aggressive exact-match anchor text while you're building more natural links.

Do "/houses" and "/houses?page=1" have exactly the same content? I'd definitely want to see rel=canonical on the "page=1" version - those are just duplicates. Google has expressly said that they don't want you to canonical pages 2, 3, etc. back to page 1. That doesn't mean it never works, just that it's a bit dicey.

As Chris said, rel=prev/next is another option. Theoretically, it would allow all of the results pages to rank, but let Google know they're a series and not count them against you as thin content. In practice, even my enterprise SEO colleagues have mixed feelings. There's just very limited evidence regarding how effective it is. It is low-risk.

The other option is to go a bit more old-school and META NOINDEX anything with "page=", and just let the original version get indexed and rank. This can help prevent any dilution and would also solve your "page=1" issue. The biggest risk here is if that cut off PR flow across your site or if you had links to the paginated results. In most cases, that's unlikely (people don't link to or tweet page 17 of your search results), but it's a case-by-case thing.

Unfortunately, the "best" solution can be very situational, and even Google isn't very clear about it.

I ran a crawl with Xenu (similar to what Donna did with Screaming Frog), and came across some deep page that may be causing this problem. For example, on this page...

http://www.cryopak.com/en/resources/cryopak-news/anthony-alleva-presenting-temp-maintenance-biopharmaceutical/

...the last link to "phase change material" goes to:

http://www.cryopak.com/product_line/default.aspx?DepartmentId=67

...which then redirects to...

http://www.cryopak.com/en/?DepartmentId=67

It seems like multiple pages share that template, so one canonical tag might clean up a lot. I'd have to understand the site structure a lot better to advise, though. Google doesn't seem to be indexing these URLs, so they probably aren't a huge problem, but they could be diluting your ranking power. It's worth cleaning them up.

I believe the actual calculation comes from Google's internal PR measure, so if you used Toolbar PR, it would be scaled in appropriately. For example, a page with TBPR=4 would only pass 33% more equity than a page with TBPR=3 (if you treat TBPR as linear), whereas it should actually be an order of magnitude higher (we're not sure what power Google uses).

Technically, you can't calculate PR without the entire link-graph, since the maximum values are set from the link graph, and the calculation is iterative. On a small scale, you could just pick a log scale to use and approximate what happens.

I guess I'm not sure what you're trying to accomplish. Beyond a tutorial view, so many factors are laid on top of PR, that even if you could calculate the true values, they would only tell you a small part of the story.

Yeah, this is a good starting point. Create a sitemap in GWT with just these pages (it's easier to monitor that way), and re-fetch any specific pages that are critical. You can also build internal links (even temporarily) to kick the crawlers or try promoting some pages via Google+. There's no foolproof method, though - just nudges.

This assumes, of course, that you've corrected the canonical tags. If there shouldn't have been a canonical tag at all, then I'd recommend adding a self-referencing canonical (i.e. one pointing to the page itself). A new canonical tag seems to overwrite an old one better than just removing, at least that's my anecdotal observation.

Yeah, I'd have to concur - all the evidence and case studies I've seen suggest that rel=canonical almost always passes authority (link equity). There are exceptions, but honestly, there are exceptions with 301s, too.

I think the biggest difference, practically, is the impact on human visitors. 301-redirects take people to a new page, whereas canonical tags don't.

Our data in OSE can lag a bit, but I'm concerned that you're seeing the same thing in Google. Is it possible to provide an example URL?

When you say "Google is still indexing the old URLs", can you tell me exactly how you're measuring that (I find "indexing" means a lot of things to a lot of different people). It's not uncommon for both the old and new version to be stuck in the index for a while, and that's not always a bad sign. It can be, but it might not be (I realize that's not terribly helpful).

Have you double-checked some of these redirects with a header checker? It's amazing how often a redirect is supposedly in place but isn't working properly, is producing multiple hops, etc.

We only crawl your own site, so we wouldn't surface a duplicate with Tumblr, unless something really, really weird is going on. This is why I need to look at the campaign - what you're describing shouldn't happen, in theory, so I have a feeling this is a pretty unusual situation.

I'm afraid there's no easy answer. The security side is beyond the scope of Q&A (it's just too dependent on your platform/host/etc.), but locking that down is definitely the biggest and first step. Obviously, though, you can't stop third-party sites from getting hacked.

Disavow can be done at the domain level. There are some oddities, like Wordpress.com (where sub-domains act more like stand-alone domains), but for most sites, if most links are malicious, lock down the entire incoming domain.

Make sure your core links are clean. If you have a solid base of links, and you're not dealing with a lot of quality issues, it's tough for these kinds of hacked links to cause as much harm. Google knows this happens. Unfortunately, if your core link profile is a mess or week, then it's a lot easier to take damage. So, this is a battle on two fronts - stop the attack and, at the same time, clean up your core link profile and strengthen it as best you can.

There are a lot of link removal tools now, but honestly, they're a starting point. You need to dig in and evaluate what they give you, so that you're not taking out links that are potentially good. Right now, this is a labor-intensive process, I'm afraid.

I'm hearing similar reports. It's been a crazy week. We're seeing massive algo flux, Mobile-friendly 2, Google testing new column widths, etc. Odds are, though, that this really is just a bug and nothing to worry too much about.