homepage Welcome to WebmasterWorld Guest from 54.167.138.53
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Google / Google SEO News and Discussion
Forum Library, Charter, Moderators: Robert Charlton & aakk9999 & brotherhood of lan & goodroi

Google SEO News and Discussion Forum

This 80 message thread spans 3 pages: < < 80 ( 1 [2] 3 > >     
Google Products Used for Negative SEO
turbocharged




msg:4567897
 11:52 am on Apr 25, 2013 (gmt 0)

A website I am working on had previously suffered in the SERPS for its homepage. Duplicate content, created externally, resulted in hundreds of copies of their homepage and internal pages. Most of the copies reside on Google owned properties (Google Apps and Blogspot). To combat the problem, we did a complete homepage re-write. New images, lots of next text and functionality were added to combat the problem. We also modified the htaccess to prevent this from happening again (or so we thought).

A single character in the htaccess file left only the homepage open to Appspot. Within two days, four Appspot URLs were indexed and our client's homepage was in the "omitted results."

I am here to say that Google's preference for their own brands is harming the internet in more ways than just limiting consumer choice. Webmasters and SEO professionals, like me (webmaster) are spending countless hours defending themselves against Google's products. I discovered this when I did a search and found many complaints from others that have been proxy hijacked by Appspot.

Since I am not an htaccess pro, or SEO pro by any means, we submitted a request for additional funding from our client to bring a SEO pro on for a limited consulting basis. Other proxies that have cached content, not owned by Google, appear to be placed in the omitted results appropriately. But we develop webpages mostly, and have no idea how many other Google products/techniques are being used as a negative SEO weapon.

Yesterday I sent out 4 DMCA notices to Google on behalf of our client. Today I will work on assembling the rest of the list, which reaches well beyond one hundred different domains, and hand them off to another in my department to File DMCA notices. Once I get client approval for the SEO pro, he/she will get the list to for review.

A good portion of the wasted time/money could be saved if Google used noindex on Appspot proxy pages. Does anyone have any idea why they would legitimately not do so? At the present time, I estimate this problem is going to cost our client $1,500. In addition to submitting the DMCA notices, we will have to rewrite some pages that probably won't meet Google's threshold for removal. Multiply this by thousands or tens of thousands of small businesses, and you have a lot of financial damage occurring. What a nightmare!

 

rish3




msg:4569364
 3:40 pm on Apr 30, 2013 (gmt 0)

The solution, in the case of duplication, is Google not indexing/showing duplicates.


I agree with this, but they should also honor DMCA requests when they end up showing duplicates. They turned me down because the offending site was "a proxy". They didn't seem to get the issue at all...the site scraped the content, and altered all the urls in a way that made it look like they were hosting the site in it's entirety.

From my perspective Google should have more "smarts" on their team that approves DMCA requests. I've had DMCA requests initially declined for similar reasons before. For example, one site put all of the scraped content into a hidden <div>, and the DMCA request was denied because "they couldn't find" any copied content.

Both cases are straightforward enough that a simple tool, similar to copyscape, would help them make decisions.

There's a really big hole right now in the algorithm as well. Scrapers look for sites with good content that are currently suffering from Panda and/or Penguin, then scrape them. They instantly outrank the source and get free traffic with little effort.

diberry




msg:4569391
 5:56 pm on Apr 30, 2013 (gmt 0)

Rish3, I find sometimes you have to explain more in your DCMA request. I had a page that someone had PDF'd and random users were sharing it right and left, unaware they had no right to, in forums. I sent a DCMA for those forum pages and my guess is that Google sent a bot which couldn't read the PDF and therefore didn't see my text or images being stolen. I re-submitted, explaining that it was a PDF of my page, with all my text and photos, and they very quickly removed it from the index.

I would suggest you re-submit, this time explaining the proxy thing.

The problem is that the algo is failing to downgrade duplicates bigtime. I recall Matt Cutts or someone saying a while back that sometimes people would rather read the article from a more trusted source (again with this trust thing). That may be valid, but it's hardly CNN who's republishing our stuff. How are these spammer domains gaining "trust" over the sites that originally produced the content? Something's wrong in the algo. The stealing of content SHOULD weigh more than any trust factor, because it's a potential reason for people to stop trusting not just a domain, but a whole company. Imagine the PR problems if BigBoxCompany.com got caught stealing content. So it's not even in Google's best interest for the algo to reward content theft. For the life of me, I don't know why they do.

TheOptimizationIdiot




msg:4569445
 9:20 pm on Apr 30, 2013 (gmt 0)

@ Rish3 - I totally agree.

Something's wrong in the algo.

Or something's wrong with their entire line of reasoning.

If there are two stores on a street and one's "a 'brand', shiny, looks good and has competitive prices", while the other is "Mom & Pop unknown, a bit rundown, but has the same merchandise at the same prices" it could be argued people "trust" the big brand franchise more, because they know the name and "all things being equal" they would rather shop there.

In real (non-algorithmic) life all that changes if the people find the ownership of the "big brand" franchise is stocking their shelves with stolen merchandise. Theft, lies, deceit, etc. destroy trust in real life, they don't build it and they certainly aren't a non-factor of it.

Think "political scandal" and how many politicians who were once "trusted" have had to retire after one too many stories proves to be false. (Sometimes one is enough to destroy people's trust.)

If people truly trust the thieves more than the originators it's likely in part attributable to Google promoting the "trusted thieves" above the originator so no one who uses their search engine gets to know who the originator actually is.

diberry




msg:4569722
 5:25 pm on May 1, 2013 (gmt 0)

Or something's wrong with their entire line of reasoning.


I can see it wrt press releases, where the intent of the original writer was to have their work republished all over the place, and readers might as well see it in its most authoritative home (that's probably good for the brand as well). But aside from that case, I don't see it.

What I can't figure out is any reason why Google would WANT to:

(a) index multiple copies of the same thing (except maybe in the case of press releases, but I'm not sure I even see the point there)

(b) ever, EVER rank the duplicate above the original

But they must have a reason to want this because their solution - handling who knows how many DCMA requests a day - is likely more expensive than tweaking the algo to do whatever Bing's doing to plagiarists.

diberry




msg:4569723
 5:25 pm on May 1, 2013 (gmt 0)

Or something's wrong with their entire line of reasoning.


I can see it wrt press releases, where the intent of the original writer was to have their work republished all over the place, and readers might as well see it in its most authoritative home (that's probably good for the brand as well). But aside from that case, I don't see it.

What I can't figure out is any reason why Google would WANT to:

(a) index multiple copies of the same thing (except maybe in the case of press releases, but I'm not sure I even see the point there)

(b) ever, EVER rank the duplicate above the original

But they must have a reason to want this because their solution - handling who knows how many DCMA requests a day - is likely more expensive than tweaking the algo to do whatever Bing's doing to plagiarists.

turbocharged




msg:4569861
 1:01 am on May 2, 2013 (gmt 0)


I received my first DMCA denial from Google today regarding their Appspot proxies. They stated:

Thanks for reaching out to us.

The DMCA notice sent is for an application that is a web proxy. The content in question is not stored on the application, but instead is simply being pulled from the original source and forwarded to the user. Please note that the webmaster can employing technical measures to block web proxies.

We apologize that we cannot be of further assistance at this time.

Regards,
The Google Team

I responded that the content was not just pulled from our client's website by a proxy but was stored on Google's servers as a cached file. Let's see their response to caching stolen content from a service/proxy that they maintain control over.

Now, if I leave the doors in my home unlocked and someone comes in and takes my television, are they free to do so without facing criminal penalties? I feel these proxy hijacking attempts are no different, but with Google condoning such activities by brushing off DMCA requests as if they are not responsible for their role in such events. It's as if Google wants to assimilate the work of webmasters and drive more traffic to their own properties. It's very disturbing.
.

[edited by: Robert_Charlton at 7:09 am (utc) on May 2, 2013]
[edit reason] post accidentally posted in wrong thread [/edit]

TheOptimizationIdiot




msg:4569863
 1:23 am on May 2, 2013 (gmt 0)

Well, for one the reviewer doesn't even know proper English:
Please note that the webmaster can employing technical measures to block web proxies.

FTEM (Fixed the Email): Please note that the webmaster can employ technical measures to block web proxies.



Beyond that, I have said previously Google's proxy is behaving correctly, so it's really the responsibility of the site owner (now passed to you) to make sure you deny proxies the ability to cache the pages, because if you do not and they run their end of the proxy server according to w3 standards, then your client (now you receiving the "passed buck" from them) don't have anything to complain about.

It's not Google's or anyone else's fault the site owner didn't take the time to learn the web standards and make sure their pages should not be served via proxy before they hopped online. It's really not, and Google may be offensive and abrasive and completely suck at customer service, but a one of the things they're not known to do without great reason is break HTTP protocol.

Sorry for sounding harsh, but it's not right to blame them for following web protocol when you don't know what web protocol is or how to make sure what you want is communicated in a protocol compliant way.

(Complaining because Google follows protocol your client (now you) don't know is like your client complaining they turned right and got hit because they don't understand the Yield Sign for their lane means they have to stop if there's a car coming. It's not the other driver's fault your client doesn't know what they're doing and didn't take the time to learn the systems. It's the fault of the person not knowing WTF the Yield Sign means for not taking the time to learn.)

There are times when Googles seem to be the problem, but it's rarely them not following web protocol standards and on the very limited occasions they break protocol (like treating 302 redirects like 301s) they have very good reason to not follow the exact protocol set by the w3.

If your client does not want their pages cached by Google's proxy server at AppSpot, then they (or now you) need to follow the protocol to stop them from being cached rather than getting upset at Google for following web standards your client has not bothered to learn.

And that still does not stop them from being proxy served, only cached by Google's AppSpot servers.

turbocharged




msg:4570192
 1:44 am on May 3, 2013 (gmt 0)

Sorry for sounding harsh, but it's not right to blame them for following web protocol when you don't know what web protocol is or how to make sure what you want is communicated in a protocol compliant way.

No need to be sorry TOI. But let me ask you this... Who stores my client's cached homepage in Google? Is it normal protocol for Google to receive a DMCA takedown notice and deny it while still holding my client's cached homepage in their index on proxy domains?

Since Google does not care about the work of others, by allowing proxied content to be indexed in the first place, the issue then becomes who has the right to cache/save/store my client's homepage on a different domain. My client did not give the proxy user or Google the right to display his trademarked logo on a different domain.

In other words, Google knowingly and willfully neglected the intellectual property rights of my client when they denied the DMCA takedown notices and allowed the cached pages to remain in their index.

TheOptimizationIdiot




msg:4570200
 3:15 am on May 3, 2013 (gmt 0)

You're confusing two different things.

Google's search index cache has nothing to do with "proxy serving" and "proxy caching".

AppSpot, even if used as a proxy is very likely not caching your page. (That's even what the denial of your DMCA says.)

It's very likely the user is running a very simple script and "grabbing" the pages from your server on-the-fly, then showing them. (That's abuse of AppSpot's service imo, but not AppSpot itself doing anything against web protocol or "caching" your page like it looks like you said it was in your DMCA complaint and have said a number of times in this thread.)

When I say simple, I mean with mod_rewrite and php I could serve your pages with less than 5 lines of code:

RewriteEngine on
RewriteRule .? /get-the-page.php [L]

### on /get-the-page.php ###

<?php

echo str_replace('www.yoursite.com','subdomain.appspot.com',file_get_contents('http://www.yoursite.com'.$_SERVER['REQUEST_URI']));

?>

So simple, but it's not "cached" on my server or my host or on AppSpot if that's where I do it from, so AppSpot is working correctly.

To "cache" (save) a copy of your site locally takes about another 5 lines max, but me telling the server to save a copy locally when it "grabs" the page is still not AppSpot "caching" the page as a proxy server, just like the denial of your DMCA notice says.



Google's search cache is another story from another portion of the company, which has nothing to do with AppSpot "caching" of anything, and Google's Search Index keeps a "cached" a copy of every page it grabs when it does not receive an error or find "noarchive" on the page.

Why would they not take the cache out of the search index? Quite possibly because you told them it was AppSpot being used as a proxy server and caching the page.

You didn't ask them to remove the appspot subdomain and cached copy from their search results.

You said AppSpot was misbehaving and caching the page and when they checked they got back to you with exactly what I'm telling you: AppSpot is working just fine and complying with web standards.

I can understand why they "didn't get what you meant" with the DMCA, because the way you have things worded here in this thread made it very difficult to figure out what you're trying to say, which I think is:

Google's search index has a cached copy of a page(s) from your client's site that is being served without their permission on an AppSpot subdomain(s).

TheOptimizationIdiot




msg:4570228
 6:03 am on May 3, 2013 (gmt 0)

Should Add:
You didn't ask them to remove the appspot subdomain and cached copy from their search results.

It doesn't look like you did to me anyway.

And my php won't quite work as posted, because showing people exactly how to do it and serve the images, etc. while changing the links isn't something I'm likely to do since I don't think it's cool to "borrow" other people's work without permission.

diberry




msg:4570382
 3:28 pm on May 3, 2013 (gmt 0)

It almost sounds like Google has deliberately come up with a clever way to index scrapers while legitimately being able to say, "Sorry, out of our hands." I still don't understand why they seem to want to index scrapers. (I just can't believe they're incapable of fixing the problem, which is why I assume it's a feature in their minds rather than a bug.)

TheOptimizationIdiot




msg:4570410
 4:56 pm on May 3, 2013 (gmt 0)

(I just can't believe they're incapable of fixing the problem, which is why I assume it's a feature in their minds rather than a bug.)

Totally agree.

I also don't understand if their "people like 'more trusted sites' better and they could be reproducing with permission" line of reasoning is true, why they can't put the originator at the top and the other "more trusted sites" at #2 and #3 (or something) for their users, sort of like they've figured out how to do with YouTube.

Originally Found On
Origination Site Here

Also Published By
Other Site They Say People Like Better #1
Other Site They Say People Like Better #2

If it's a "legit" republication, then their visitors are happy. If it's not then the originator is #1 until they get the DMCA in to Google and the infringers/infringing host.

Originator should be happy, visitors should be happy, thieves still get DMCAed.

If the "originally discovered" location isn't the original and it's not an authorized copy, then they get the DMCA and the actual originator can take their place with a simple "override original discovery date" flag in the system.

turbocharged




msg:4570594
 12:35 pm on May 4, 2013 (gmt 0)

AppSpot, even if used as a proxy is very likely not caching your page. (That's even what the denial of your DMCA says.)


It's very likely the user is running a very simple script and "grabbing" the pages from your server on-the-fly, then showing them.

I don't quite get where you are coming from. I understand the basics of a proxy and how it pulls data from one source to display to another. If Appspot subdomains are indexed in Google with my client's homepage, how a user accomplishes this should not matter to the owner of Appspot (Google) when they receive a DMCA notice.

You didn't ask them to remove the appspot subdomain and cached copy from their search results.

I made reference to it in the original DMCA notices. The Appspot caches are dropping, albeit at a slow pace. Whether this is related to the original DMCA notices or htaccess restrictions is uncertain. I also responded to their denials with specific references to the cached versions of my client's homepage. No response has been received from those yet.

TheOptimizationIdiot




msg:4570620
 3:33 pm on May 4, 2013 (gmt 0)

The Appspot caches are dropping, albeit at a slow pace.

You keep calling them AppSpot caches. That would be really confusing to anyone, because they're not AppSpot caches. They're Google's Search Index cache of your clients pages displayed via AppSpot subdomain.

If Appspot subdomains are indexed in Google with my client's homepage, how a user accomplishes this should not matter to the owner of Appspot (Google) when they receive a DMCA notice.

If you don't say what's actually happening no one knows where to actually look to see what you're saying. I understand you're a designer and this isn't your "thing", but that doesn't mean Google should have to somehow determine for you the complaints you're making are about something other than what you keep stating.

I'm really not sure if they can make that determination legally when it comes to DMCA, so your repeatedly calling Google's Search Index cache of your client's page served via AppSpot subdomain an AppSpot cache could very easily be shooting you in the foot.

AppSpot is not caching anything. That's what people keep telling you, but you keep referring to it as an AppSpot cache. AppSpot is not doing any caching. Period. There's a cache of a page served via AppSpot subdomain you would like removed from Google's search cache/index. They're two totally different things.

Whether this is related to the original DMCA notices or htaccess restrictions is uncertain.

Everything to do with the htaccess, nothing to do with a DMCA that talks about AppSpot caches, because AppSpot is not using caching, but that's what you keep saying.

rish3




msg:4570897
 9:08 pm on May 5, 2013 (gmt 0)

Heh. It doesn't matter if the AppSpot proxies are "caching" the pages or not. They are serving them up as if they exist locally...and worse than that, they've altered the html such that all linked on served pages look as if they are on the AppSpot domain as well.

You can bet that if anyone started serving up Google's own content on one of these AppSpot domains, the app would get banned.

TheOptimizationIdiot




msg:4570898
 9:20 pm on May 5, 2013 (gmt 0)

Or not...
http://my-home-proxie.appspot.com/google.com

Not sure if the link will be allowed so I broke it.
Copy and paste to see how wrong the preceding assumption is.

I even conducted a search on Google using it.

rish3




msg:4570899
 9:28 pm on May 5, 2013 (gmt 0)

Or not...
http://my-home-proxie.appspot.com/google.com


Well, the home page of google isn't really content per se. Get one of them to crawl something they care about, and then get somebody at Google who matters to see it, then the app will get banned.

My point isn't that there's some automated Google overlord that will zap the account behind the scenes. My point is that they would consider it a DMCA issue if it were something or someone they cared about.
.

[edited by: Robert_Charlton at 9:52 pm (utc) on May 5, 2013]
[edit reason] disabled autolink to delink sample url [/edit]

TheOptimizationIdiot




msg:4570904
 10:11 pm on May 5, 2013 (gmt 0)

Can you please point me in the direction of a couple legal rulings against proxy serving webpages? I've tried but can't find any.

I found a couple about framing, but as far as I can tell (and remember from doing this before) it was only when the framing site profited directly from displaying the content of others in a way that could be confusing to visitors as being theirs when the rulings went against the framing sites.

I have not found any rulings against someone proxy serving another website for free. In fact, proxy servers are often used to get around "censorship" in schools and businesses and some of them even charge for their use, but there still aren't any rulings I can find against them.

So you're making statements about DMCA and how if it was Google and anything they cared about (as if they don't care about their home page -- and that's fine you can think they don't care about it), but, please show me the legal precedence for your conclusion about there being anything to DMCA when a proxy server doesn't profit or even attempt to profit from serving the content on behalf of another website, because I don't see it.

TheOptimizationIdiot




msg:4570906
 10:31 pm on May 5, 2013 (gmt 0)

Also, let me ask, since I work on sites that don't have any issues with proxy servers and I just checked and they are available via proxy, including the AppSpot proxy I noted above, and the proxy does change the links so they continue requesting through the proxy but what the proxies do not change is the <link rel="canonical" href="http://www.my-sites.com/the-page.ext"> I run on every single page of every site I work on.

Do those with issues of proxies outranking them run rel="canonical" on their pages?

rish3




msg:4570911
 11:08 pm on May 5, 2013 (gmt 0)

please show me the legal precedence for your conclusion about there being anything to DMCA when a proxy server doesn't profit or even attempt to profit from serving the content on behalf of another website, because I don't see it.


I'm not talking about legal precedence. I'm talking about Google's willingness to honor DMCA requests when the host that copied the content is a Google-owned property. They regularly approve requests when then infringing party is a site with -0- monetization.

but what the proxies do not change is the <link rel="canonical" href="http://www.my-sites.com/the-page.ext"> I run on every single page of every site I work on.


Yes, they change the canonical link as well. The particular script that's really prolific on appspot that munges the canonical link can be found by searching Google with this:

site:appspot.com "Just type the URL of any web page in the input box"

An example:


view-source:http://www.newtekproxy.appspot.com/huffingtonpost.com

It's subtle...you have to notice the slash in front:

<link rel="canonical" href="/www.huffingtonpost.com/" />


In fact, the example proxy you posted happens to munge the canonical url as well...


view-source:http://my-home-proxie.appspot.com/huffingtonpost.com

<link rel="canonical" href="/www.huffingtonpost.com/" />

rish3




msg:4570912
 11:26 pm on May 5, 2013 (gmt 0)

Anyhow, from my perspective, both Google, as well as many others on this forum are confusing "real proxies", like squid, with these "web based proxies".

All of the RFC's pertaining to proxies are talking about real proxies. Real proxies don't take HTTP requests like a normal web server (with the exception of "transparent mode"). They use ICP, HTCP, etc. The one exception is "transparent mode", where they DO NOT DO CRAP LIKE REWRITING URLS. THE PROXIED PAGES ARE 100% VERBATIM.

Somewhere, someone at google's DMCA team, and apparently here as well, "web based proxies" somehow got equated with "real proxies".

There are no RFC's for a web-based proxy that rewrites the content. However, a sensible web-based proxy would take measures to ensure that it doesn't create duplicate content...like a <meta ROBOTS> tag for example.

TheOptimizationIdiot




msg:4570915
 11:53 pm on May 5, 2013 (gmt 0)

I'm not talking about legal precedence. I'm talking about Google's willingness to honor DMCA requests when the host that copied the content is a Google-owned property. They regularly approve requests when then infringing party is a site with -0- monetization.

AppSpot is not Copying the Muther Bleeping Content!
How F'ing Tough is it to Get?

I'm done with this one. Please, try to beat Google in court on it if you're right, please, try. Feel free. You can't find legal precedence and you won't be able to prove "bias" on the part of Google upholding a DMCA request, because you really, really don't get what proxy serving is and whether you can do anything about it legally or not.

Don't like your site being framed by sites like about.com? Install some JavaScript.

Don't like your site being proxy served? Install some .htaccess rules.

Either way, please, quit complaining and saying how wrong Google is until you find an attorney who actually understands what's "acceptable" and what's "not acceptable" online, accepts your case and actually wins against Google.

If you can do that, then, cool you've got a great "told you so" story, but until then, quit talking about bias when the main person complaining about a DMCA not being honored in this thread can't even say WTF is happening so someone who actually understands how things work can understand it.

You started off earlier by saying if it was Google being served by AppSpot they would do something about it, then when I pointed out they are you changed your tune and said if it was a page they cared about they would, as if they don't care about their home page.

Please, get real, deal with reality and realize Google's allowing Google.com to be proxy served for a reason, and the reason they're letting it happen isn't because they have legal grounds to stop it and don't want to or feel like saying "Hey, you have to stop and your AppSpot account is cancelled.", really it's not, because it would be so easy to automate a check to see if Google.com was being proxy served and send an automated CD to the AppSpot user it's not even funny.



Really, if Google is being biased to their AppSpot system, then I hope you sue and I absolutely hope you win, but until then, since there's no legal precedence and people can't even say what they mean in this thread then I'm not seeing it personally, and understanding how things work and what's happening and stopping it on your end are the best solutions I can think of, because there's not "copying" going on with a proxy server any more than there is with framing.

rish3




msg:4570935
 2:06 am on May 6, 2013 (gmt 0)

AppSpot is not Copying the Muther Bleeping Content!
How F'ing Tough is it to Get?'

They are presenting it in a way that is no different to a search engine's crawler than a copy. How hard is THAT to get?

rish3




msg:4570936
 2:10 am on May 6, 2013 (gmt 0)

Don't like your site being proxy served? Install some .htaccess rules.


I did, but of course, after the fact. After I discovered they even existed, and after tons of content was in Google's search engine cache.

Sure, I did the research and found that AppSpot uses a predicable user-agent. But, that won't protect me from the next set of "web proxies" that use a different user agent.

Again, just noting my opinion that if your site presents a "copy" of someone else's site to Google's crawler, it should be subject to the same rules as other scrapers. Not sure why that has you so wound up.

turbocharged




msg:4570939
 2:15 am on May 6, 2013 (gmt 0)

@TOI

I think most people understand what I mean when I say my client's homepage is cached on Appspot proxy. The homepage is obviously cached by Google on an Appspot subdomain for anyone that appears to be confused.

The Appspot proxies rip everything including canonical and all internal links. I have not checked the sitemap, but it would not surprise me if they ripped that too. If a user happens to land on an Appspot proxy, the can view your pages all day long without ever leaving that proxy. Sure, htaccess helps. But how many webmasters even know that these Appspot proxies exist?

While Appspot proxies may have a legitimate use, staff in our office append a CR when referring to Appspot. Blogspot is also referred to as Spamspot. Both of these Google owned properties are ripe for abuse and are being run by an Administrator (Google) that has absolutely no respect for original content creators. That's the conclusion that everyone in my office has come to, and Google's reluctance to secure their own properties is a testament to how they prioritize protecting copyrighted material.

TheOptimizationIdiot




msg:4570940
 2:16 am on May 6, 2013 (gmt 0)

How hard is THAT to get?

It's not tough at all.

Have you sent a DMCA to Google asking them to remove their Search Engine cache of the AppSpot page?

After I discovered they even existed, and after tons of content was in Google's search engine cache.

So your lack of knowledge about what is correct, allowable legally, and how to deal with it is the responsibility of a 3rd party now? Have you checked with every single spidering/caching and made sure they don't have a cache too? And, if they do, then who's fault is it?

I don't like everything Google does, but the "blame them and hold them responsible" for people not knowing WTF they're dong when they hop online and try to make money from the Internet is BS. It's not any more their fault for not informing you than Yahoo! or Bing or Archive.org or anyone else who runs a site that makes a cache of a page that happens to be served on AppSpot!

How do people think it's right to blame Google for their own lack of knowledge about what they're doing and the business they get into?

I think most people understand what I mean when I say my client's homepage is cached on Appspot proxy.

Sorry, but to people who know what they're talking about, you're saying it's apples, when you really mean oranges. It's like if I said will you check the "hue" and meant "saturation". People who don't know what they're talking about might infer "check the color overall", but someone who knows would check the f'ing hue, not the saturation.

[edited by: TheOptimizationIdiot at 2:27 am (utc) on May 6, 2013]

rish3




msg:4570941
 2:23 am on May 6, 2013 (gmt 0)

Have you sent a DMCA to Google asking them to remove their Search Engine cache of the AppSpot page?

I did, and it was denied, because it was a "proxy".

So, I put in some .htaccess rules to block AppSpot's user-agent, then used the public url removal tool.

Did it work? Yes. However, I disagree with proxies getting an exception. This method only worked because the python api in appspot doesn't allow code to alter the user-agent.

To me, if you're going to run one of these "web proxy" sites, you need to either keep proxied content from being indexed, or you should be held to the same DMCA rules as everyone else. I see you disagree...that's fine.

Once this negative seo technique spreads to other places...places where they can alter the user-agent, I won't have that option.

TheOptimizationIdiot




msg:4570942
 2:33 am on May 6, 2013 (gmt 0)

Once this negative seo technique spreads to other places...places where they can alter the user-agent, I won't have that option.

Unless you take the time to learn enough about what you're doing to know you could go by IP Range too. Is it Google's fault you don't know that? Or would it be mine if I didn't bother to tell you how to defeat something without the UA being the same when you own and operate a site you would like to make money from?

Google didn't tell you to build a website. They don't make the rules about what's acceptable and what's not for a proxy server. They know way more about their job, web protocol and websites than you do. Don't blame them (or anyone) for taking the time to learn and know the rules and know what to do in different situations when you haven't bothered to, please.

[edited by: TheOptimizationIdiot at 2:35 am (utc) on May 6, 2013]

turbocharged




msg:4570943
 2:34 am on May 6, 2013 (gmt 0)

Sorry, but to people who know what they're talking about, you're saying it's apples, when you really mean oranges. It's like if I said will you check the "hue" and meant "saturation". People who don't know what they're talking about might infer "check the color overall", but someone who knows would check the f'ing hue, not the saturation.


You are absolutely right. When I sent the original DMCA notices to Google, and referenced that my client's homepage was indexed in Google on a multitude of Appspot subdomains, they had absolutely no idea what I was talking about. Google confused it just like the thousands of other people complaining about stolen/cached content originating from Appspot subdomains even in Google's own webmaster help forum.

While your literary lesson is nice, it has gotten well off topic. I'm not here to define what "is" is as President Clinton tried. It appears that is what you are trying to do to this thread - turn it into an English lesson with the proper use of verbs, nouns, etc.

TheOptimizationIdiot




msg:4570945
 2:39 am on May 6, 2013 (gmt 0)

Just see my previous post. I'll leave it to the two of you.

It wasn't about literature, it was about knowledge and the ability to communicate wtf you actually mean to someone who's taken way more time than you to learn what they're doing wrt sites and protocol, because like I said, you've been saying apples in this thread when you meant oranges. That's not my fault. It's not Google's fault. It's your fault and your client's fault for not knowing or hiring someone who knows what to do and how to do it and when and can actually say what they mean.

Sorry, but your problems (handed to you by your client) and the combined lack of knowledge of the two of you are no one's fault or problem except your own. I was trying to help. I don't get paid for this. I don't have any vested interest in Google and don't get paid by them either. I'm done try to tell either of you anything. GL to both of you.

[edited by: TheOptimizationIdiot at 2:45 am (utc) on May 6, 2013]

rish3




msg:4570946
 2:40 am on May 6, 2013 (gmt 0)

When I sent the original DMCA notices to Google, and referenced that my client's homepage was indexed in Google on a multitude of Appspot subdomains, they had absolutely no idea what I was talking about.

This is exactly what bothered me. Google, by the nature of what they do, should understand the situation *more* than anyone else. They don't. Leverage appspot proxies as part of a negative seo campaign is very common. They don't seem to know, or perhaps don't care.

My earlier rant about Google probably understanding it if it were something they cared about drives off that point. I didn't take the google home page as a good example because it doesn't even have a complete sentence on it. But, if, for example, the Adsense blog was being proxied, and the proxied copy started ranking for terms...I bet they would not only DMCA the content, they would shut down that particular appspot app and ban the owner.

This 80 message thread spans 3 pages: < < 80 ( 1 [2] 3 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Google / Google SEO News and Discussion
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved