Now that you know how to iden­ti­fy, pre­vent, stop and recov­er from a Neg­a­tive SEO attack, here’s a look toward pos­si­ble future threats you should arm your­self to fight.

Wel­come to the final install­ment of the Neg­a­tive SEO series! Before we get start­ed on this look into the pos­si­ble future, it is impor­tant to note that –as with any prog­nos­ti­ca­tion — this arti­cle is going be heav­i­ly opin­ion­at­ed and will con­tain a fair amount of speculation.

I base my expec­ta­tions about the future of SEO upon search trends that are cur­rent­ly only in their infan­cy, so it’s impos­si­ble to say whether they’ll con­tin­ue on the same trajectory.

Addi­tion­al­ly, I acknowl­edge that some of these new attack vec­tors might tech­ni­cal­ly already exist but they haven’t been test­ed by my team or by oth­er cred­i­ble researchers that I’m aware of.

The basis for the inclu­sion of such near-future attack vec­tors is to pro­vide as much action­able infor­ma­tion as pos­si­ble (for an arti­cle about the future) and to avoid rely­ing on too-far-out predictions.

The first point I would like to make is that what worked yes­ter­day is like­ly to work tomor­row, and the next day, and the next, ad nau­se­am. So long as Google is rely­ing on data to decide where to rank a site, it will be pos­si­ble for that data to be viewed either pos­i­tive­ly or negatively.

Thus, the more reliant Google is on a sig­nal, the more dif­fi­cult it will be for them to com­plete­ly nul­li­fy the effects of a bad actor attempt­ing to attack you by manip­u­lat­ing the data under­ly­ing that sig­nal. What we saw work­ing in the ear­li­er arti­cles of this series should occu­py most of your atten­tion; the fol­low­ing is what I expect may come to pass in the next year or three.

In keep­ing with our prac­tice of sim­pli­fy­ing SEO into the buck­ets of con­tent, links, and user sig­nals, we are going to approach the future neg­a­tive SEO attack vec­tors in the same manner.

Links

Social links from low-qual­i­ty accounts. For the most part, social links don’t appear to direct­ly impact rank­ings sig­nif­i­cant­ly, though they are use­ful for link dis­cov­ery purposes.

In the future, how­ev­er, Google may start to place a pre­mi­um on who shares a link, espe­cial­ly with ver­i­fied accounts; in this sce­nario, hav­ing links to your site shared out by known bot net­works may result in an adverse reac­tion sim­i­lar to the ear­ly link penal­ties relat­ed to bad web neighborhoods.

Seek­ing out tox­i­c­i­ty. One tac­tic that bad actors some­times use is to place out­bound links on tox­ic web­sites, hop­ing to asso­ciate their tar­gets with these known ill-reput­ed players.

Now that link tools like SEM­rush / LinkRe­search­Tools / Majes­tic and oth­ers make dis­avow files and oth­er tox­i­c­i­ty data avail­able through their APIs, attack­ers could be more effi­cient in ensur­ing that time spent accru­ing bad links will yield a high­er prob­a­bil­i­ty of result­ing in a penal­ty. It’s only a mat­ter of time before a bad actor syncs this data direct­ly to their link spam tools for max­i­mum effect.

Anonymous/fake press releas­es. Plac­ing press release links, as a tac­tic, still works for pos­i­tive SEO. What I have not yet seen in the wild and expect to see at some point is a fake news push via the press. If an attack­er sub­mit­ted a press release anony­mous­ly and pur­chased place­ment via cryp­tocur­ren­cies, it would be rel­a­tive­ly easy to either high­light neg­a­tive news or make up a sto­ry that is poten­tial­ly dam­ag­ing, simul­ta­ne­ous­ly using rich anchor text in the links back to the tar­get domain.

Such a tac­tic would be harm­ful in two ways: first, it would poten­tial­ly result in bad press rank­ing for key terms and sec­ond, the tar­get­ed anchor text may trip an algo­rith­mic link penalty.

Using Google Assis­tant to do bad things. This is a favorite of mine, inso­far as a poten­tial­ly use­ful tool can be used for some tru­ly awful things. In this exam­ple, it is already a sim­ple process to deter­mine the major­i­ty of a competitor’s links via one’s favorite link research tool; then those links can be parsed through a WHOIS ser­vice, as we described in a pre­vi­ous article.

Final­ly, the future part: Google Assis­tant, specif­i­cal­ly the Duplex fea­ture being released to some Pix­el smart­phones next month, could be used to mim­ic a human, call­ing and request­ing link removals to the web­mas­ter con­tacts, repeat­ed­ly. When this tac­tic starts, it will be extreme­ly suc­cess­ful and dam­ag­ing. (Google says Duplex will iden­ti­fy itself as a non-human, but it remains to be seen whether that can be over­rid­den in some way.)

Content

Dupli­cate con­tent served through prox­ies. This is an old tac­tic that I fear may return soon. The way the tac­tic works is a proxy gate­way site is set to index and effec­tive­ly crawl a web­site, mak­ing and dis­play­ing a copy of it. The rea­son I fear it may come back is because Google appears to be mak­ing a con­cert­ed effort to focus more on enti­ties and less on URLs.

URLs help us to dis­tin­guish real vs fake on the web, help us to under­stand under­ly­ing tech­nolo­gies being used, a site’s struc­ture, and so much more. If Google ulti­mate­ly moves to drop URLs as it has been recent­ly sug­gest­ed they’d like to do, one can expect this tac­tic to be extreme­ly effec­tive in rob­bing a site of its traf­fic via dupli­cat­ed con­tent that an attack­er has set up.

Mis­used AMP. AMP can be mis­used in mul­ti­ple ways to cause con­fu­sion among users and web­mas­ters alike, but with regards to neg­a­tive SEO, the sim­ple method is to cre­ate an AMP site with bad con­tent and use the rel=canonical tag to con­nect it to a tar­get site.

In this case, bad con­tent can sim­ply mean con­tent that is an 80% tex­tu­al match to the tar­get page’s con­tent, except with more key­word stuff­ing and adult phras­es designed to trig­ger Safe Search.

Inject­ed canon­i­cals. In the same way that an attack­er can inject con­tent onto a site through a hack or tech­ni­cal mis­con­fig­u­ra­tion, a bad actor may imple­ment a PWA (pro­gres­sive web app) and asso­ciate the PWA with a tar­get domain, via the hack.

If prop­er­ly cloaked to the web­site own­er, the PWA could appear as a nor­mal brand­ed PWA, but it would just so hap­pen to steal cus­tomer infor­ma­tion or oth­er­wise cause rep­u­ta­tion­al prob­lems. Sim­i­lar to the PWA-inject­ed con­tent prob­lems, a bad actor could also tweak AMP and hre­flang set­tings in an attempt to cause incor­rect index­ing issues.

GDPR com­plaints as a ser­vice. This will almost cer­tain­ly be a prob­lem in Europe. The attack would work by seek­ing out rank­ing pages that con­tain a person’s name and then fic­ti­tious­ly fil­ing GDPR com­plaints in bulk, as an attempt to have the pages removed.

This is an exten­sion of sim­i­lar attacks that have exist­ed for years in the U.S. with the Dig­i­tal Mil­len­ni­um Copy­right Act (DMCA), which were very suc­cess­ful up until quite recently.

User signals

Knowl­edge graph, rich snip­pets, reviews and oth­er Google prop­er­ty list­ings. It is already cur­rent­ly pos­si­ble to inun­date Google host­ed fea­tures with neg­a­tive reviews and incor­rect infor­ma­tion, which result in a waste of time for a web­mas­ter. How­ev­er, I can fore­see a future where this is done far more aggres­sive­ly, by rent­ing the use of senior Google review­er accounts to do a vari­ety of things:

  • Mark­ing busi­ness list­ings as closed (repeat­ed­ly).
  • Updat­ing address­es to known spam addresses.
  • Updat­ing web­site list­ings to point to a competitor.
  • Updat­ing exist­ing links to valid yet incor­rect pages.

Google trusts its senior­i­ty process for mak­ing changes, and, like the Wikipedia edi­tor com­mu­ni­ty, once it is suf­fi­cient­ly infil­trat­ed with bad actors, it becomes dif­fi­cult to trust.

3rd par­ty review sites [serchen, G2 crowd, etc]. This attack vec­tor works in two dif­fer­ent ways. First, hav­ing a sig­nif­i­cant num­ber of bad reviews is prob­lem­at­ic as it cur­rent­ly reduces the amount of traf­fic that would orig­i­nal­ly come from such sites. Addi­tion­al­ly, what will start to hap­pen fair­ly soon is we will see the most neg­a­tive list­ings ranked with aggres­sive link spam.

Not only do peo­ple tend to pre-judge the qual­i­ty of a ser­vice or prod­uct by rely­ing on 3rd par­ty reviews, but the more first-page rank­ings that are com­prised of bad reviews, the more like­ly the tar­get domain is going to be ignored and thus receive few­er clicks.

Mass flag­ging in Chrome. As Google relies more and more on its own prod­ucts for user sig­nal trust, attack­ers will also start to place more empha­sis on those prod­ucts to manip­u­late the sig­nal. One such way has to do with report­ing malware.

Cur­rent­ly, if enough mal­ware web­sites are 301 redi­rect­ed into a domain and are report­ed through Google’s gen­er­al feed­back form, there is not insignif­i­cant chance the tar­get domain will be list­ed with a mal­ware warn­ing. With Chrome the poten­tial may even be high­er, as an attack­er could flag both the tar­get and recip­i­ent domains of the mal­ware redi­rect, at scale.

In my opin­ion, this would be excep­tion­al­ly effec­tive and like­ly result in the attacked domain being flagged and not view­able to the 80% of the web that uses Chrome brows­er by default. Tech­ni­cal­ly, because this con­cept uses links, we could also include it in the pre­vi­ous section.

Junk traf­fic through AMP. High lev­els of junk traf­fic pushed through the accel­er­at­ed mobile pages (AMP) ver­sion of the site is already done to mis­lead web­mas­ters by pro­vid­ing a view of incor­rect user intent which results in wast­ed time opti­miz­ing for poten­tial­ly incor­rect pages, terms, and needs.

It has oth­er neg­a­tive impacts if con­tin­u­ous­ly scaled, by pur­pose­ful­ly send­ing bounce traf­fic through the non-AMP ver­sion and lin­ger­ing traf­fic through AMP where­in one may incor­rect­ly assume AMP is a good solu­tion (it isn’t). If an attack­er was look­ing to accel­er­ate the demon­e­ti­za­tion of a pub­lish­er site, this is one such method I expect we’ll see.

More sophis­ti­cat­ed DDoS attacks. This is an almost cer­tain tac­tic to be employed and is based on trig­ger­ing serv­er-side local JavaScript and nat­u­ral­ly slow pages due to expen­sive queries.

Giv­en that hosts have empha­sized improv­ing CPU per­for­mance and the abil­i­ty to auto-scale when traf­fic is high as a proxy for deter­min­ing serv­er load, a more effi­cient attack will evolve where­in solv­ing traf­fic-relat­ed DDoS won’t mat­ter as the attack vec­tor shifts towards attack­ing slow serv­er-side scripts and the data­base by repeat­ed­ly load­ing spe­cif­ic URLs which con­tain uncached SQL queries, result­ing in hung SQL queries and thus a slow, if not inca­pac­i­tat­ed website.

Conclusion

This con­cludes our series on neg­a­tive SEO. As we set out in the begin­ning, it is my hope that you now have a firm under­stand­ing of what it is, how it works, how to pro­tect your­self, how to stop an attack, how to recov­er from it, and can now keep an eye to the future on what neg­a­tive SEO may look like in the years to come. I would like to thank Andrew Evans for cor­rect­ing my numer­ous gram­mar mishaps and Debra Mastaler for trans­lat­ing my search engine thoughts in human on a month­ly basis.

SOURCE