Impatto dell'aggiornamento principale di Google del 4 maggio sui forum di Discourse

Comunità
91

Sono completamente d’accordo. Il mio risultato di ricerca rapido non era il punto centrale e non è stato assolutamente inteso come un test autorevole; quando l’ho pubblicato, non ho fatto alcuna affermazione del genere. Ho solo posto una domanda basata sui risultati della mia ricerca. Avrei dovuto disconnettermi prima di effettuare la ricerca, perché quando mi disconnetto ottengo gli stessi risultati “mancanti”, LOL.

L’unico “punto tecnico tangibile” che ho effettivamente sollevato è che Google ha dichiarato pubblicamente che inizierà a utilizzare LCP (e altre metriche web vitali) a partire da maggio 2021.

Ho anche fatto notare un aspetto commerciale: Google non può fare dichiarazioni del genere e ingannare le persone. Sarebbe un enorme errore per una grande società quotata in borsa. Secondo la mia opinione, non stanno commettendo un tale errore; quando Google afferma che non sta ancora utilizzando LCP come fattore di ranking, non ho motivi per non credergli.

Se i poster benintenzionati che sostengono che LCP stia influenzando la SEO, che sono sicuri dei “loro risultati” e che invitano Discourse a apportare modifiche strutturali al codice basandosi su tali “risultati”, avessero reso il codice disponibile per la revisione, essendo open source, così che tutti potessero esaminarlo, le loro “prove”, dopo una revisione tra pari, potrebbero essere convincenti.

Non c’è nulla di personale o antagonistico, ma in realtà abbiamo visto solo alcuni grafici e nessun codice, mentre Google ha dichiarato pubblicamente che al momento non sta nemmeno utilizzando LCP come fattore di ranking per la SEO.

In tutta “equità tecnica”, non abbiamo effettivamente visto alcuna “prova” che Google stia utilizzando LCP come fattore di ranking attualmente. È solo un’ipotesi e non c’è codice da esaminare e sottoporre a revisione tra pari per supportarla.

Tutti qui vorrebbero sapere quali modifiche sono necessarie per ottimizzare la SEO e aumentare i ricavi. Tuttavia, abbiamo bisogno di fatti tangibili, di codice da esaminare, dove possiamo essere convinti che Google stia effettivamente utilizzando LCP come fattore di ranking.

Google afferma di non utilizzare attualmente LCP come fattore di ranking e inizierà a farlo come fattore SEO nel maggio 2021. Finora, non abbiamo alcun motivo di dubitare di quanto Google ha dichiarato pubblicamente e non abbiamo visto alcuna “prova concreta sottoposta a revisione tra pari” che dimostri il contrario.

Spero che questo sia d’aiuto.

4 Mi Piace
92

Quindi, per tutti quelli che si sono lamentati del maggio 2020, non è nulla rispetto a ciò che potrebbe arrivare nel maggio 2021? :wink: Voglio dire, stai anche dicendo che le comunità Discourse potrebbero subire un colpo in termini di risultati di ricerca l’anno prossimo (vedremo già cosa succederà).

2 Mi Piace
93

Sì, sono completamente d’accordo con te e con tutti quelli qui preoccupati per LCP e per l’effetto che i Core Web Vitals di Google avranno.

Inoltre, faccio i miei più sinceri complimenti a tutti coloro che stanno correndo per trovare risposte e soluzioni a questo problema imminente.

Per quanto riguarda il crollo SEO di maggio 2020, è successo anche a noi sui server LAMP; quindi non è un problema di Discourse, in alcun modo; e ancora non sappiamo i passaggi esatti per risolvere questo problema di maggio 2020, perché se sapessimo cosa correggere, con un alto grado di certezza, tutti noi potremmo “correggere” e “aggiustare”.

Nel corso degli anni, abbiamo tutti visto risultati molto strani dall’IA di Google e su come l’IA di Google classifica i contenuti e modifica i risultati della SERP.

Il mio punto precedente era che mi sembrava infondato leggere in questo argomento che qualcuno spingesse il team Meta di Discourse a apportare cambiamenti strutturali molto sostanziali all’intero ecosistema basato su ipotesi e supposizioni e non su fatti concreti derivanti da un’analisi del codice verificabile.

Detto questo, LCP diventerà molto importante, in ogni caso, in un batter d’occhio.

Ciao.

4 Mi Piace
94

È così che funziona Discourse da sempre :laughing:

La novità è che il LCP viene rilevato dai telefoni Android degli utenti. Android è la piattaforma più lenta che supportiamo e questo ci colpisce in modo sproporzionato.

Quello che ha suggerito @sam era anche servire quella vista per alcuni utenti anonimi tramite un plugin, ma non è qualcosa che faremo a breve.

7 Mi Piace
95

Ok. Mi mancano alcune conoscenze su come funziona esattamente (ma sembra che ci sia ancora un certo caricamento iniziale, e potrebbe essere più veloce. Da qui nasce tutto questo argomento). Questa discussione è già sorta in parte il 14 ottobre, sopra. Jeff ha effettivamente sollevato l’idea:

Perché non prendere i contenuti e creare un sito statico completamente pregenerato. Qualcosa il più veloce possibile. E sottoporlo ai motori di ricerca invece del forum vero e proprio? L’idea è che qui il contenuto è ciò che conta di più, non l’esperienza. E concentrarsi sulla rapidità di consegna, dato che sembra essere ciò che è importante per i motori di ricerca.

Lo scrolling infinito non è stato incolpato di recente, ma creeresti pagine statiche pregenerate senza scrolling infinito. E lo progetteresti come un’auto da rally: di ogni grammo di peso che non è strettamente necessario, ti libereresti. Nessun menu hamburger, nessun logo, nessun avatar per gli autori. Ti concentreresti esclusivamente sul contenuto e sulla velocità.

Sarebbe come un bel ristorante (= il forum Discourse), dove allesti un drive-in con ordini da asporto. Stesso ottimo cibo (= i contenuti) ma senza alcuna esperienza. Ordini al parlatorio arrivando (= la tua ricerca sul motore di ricerca) e ti viene lanciato il cibo preimballato attraverso il finestrino. L’idea è che ciò che viene richiesto è importante, e solo il cibo (= contenuto) e la velocità di consegna contano. Se alle persone piace il cibo, forse torneranno e godranno dell’intera esperienza all’interno.

Dopo, spetta a ogni proprietario (= amministratore) fare una scelta: pensi che un drive-in sia negativo per il tuo marchio e ti rifiuti di farlo, oppure prendi questa strada per attirare più persone, sapendo che molte potrebbero non venire mai a mangiare dentro (molte già non lo fanno, ma potrebbe peggiorare ancora. E forse il tuo ristorante sembrerà molto meno bello presentato in questo modo). Ma forse quel famoso sito web che consiglia ristoranti ti invierà più persone (resta da vedere se è efficace).

Ciò che servirebbe è un plugin o modulo per generare queste pagine statiche man mano che i contenuti vengono aggiunti al forum (immagino non dovrebbe essere eccessivamente complicato). Aggiungeresti semplicemente un link qui e là al tuo forum vero e proprio (impostato su “non indicizzare” per i motori di ricerca). Spetterebbe a ogni amministratore utilizzare o meno questa soluzione.

Se quanto detto sopra è corretto in linea di principio, e questo problema potrebbe peggiorare in futuro, questa sembra una soluzione accettabile per me. O forse non ho capito bene. (Nota: tutto questo sarebbe SOLA LETTURA, naturalmente)

1 Mi Piace
96

Noi già serviamo HTML semplice, senza JavaScript, ai crawler :upside_down_face:

Come ho detto sopra, il punto è che il nuovo punteggio LCP viene rilevato dai browser degli utenti, non dai crawler.

7 Mi Piace
97

Ok, ma allora ciò che non riesco a capire è che in questo caso nessuno sta andando meglio, giusto? Perché dovrebbe influire sui risultati di ricerca? Se i siti Discourse performano allo stesso modo degli altri (“allo stesso modo” o “ugualmente male” ;)). Anche gli altri siti vengono aperti su Android, no?

2 Mi Piace
98

Android è più lento della media nelle prestazioni single-core, il che influisce sulle applicazioni single page pesanti come Discourse. Ne parliamo in profondità in Lo stato di JavaScript su Android nel 2015 è… scarso

L’iPhone di punta è 10 volte più veloce dell’ultimo Pixel nel rendering di Discourse. Google non tiene conto dei rendering dell’iPhone nel calcolo del LCP, semplicemente perché non può farlo, dato che su iOS non esiste un vero Chrome.

9 Mi Piace
99

Quindi potrebbe esserci effettivamente un vantaggio in tal senso nel generare un sito con “pagine piccole” da inviare ai motori di ricerca. Ne varrebbe la pena? (forse no). O gli amministratori devono offrire nuovi telefoni di fascia alta ai loro utenti? :wink: È questo lo scopo di tutti quegli annunci che dicono che hai vinto l’ultimo iPhone? :rofl:

Grazie per le spiegazioni, Falco!

1 Mi Piace
100

Dalla rapida lettura di questa pagina Overview of CrUX  |  Chrome UX Report  |  Chrome for Developers sembra che Google ottenga le informazioni spiando gli utenti (con il loro permesso), quindi dovresti convincere molti di loro a utilizzare il tuo Discourse da poveri :slight_smile:

4 Mi Piace
103

Sembra che tu stia confondendo Ember e Ember CLI. Ember è il framework che stiamo già utilizzando (e lo facciamo da oltre 8 anni). Ember CLI è lo strumento da riga di comando che stiamo adottando al posto dell’asset pipeline di Rails. Lo menziono perché alcune cose che dici (come il fatto che le versioni precedenti alla 3 richiedano riscritture) non sarebbero vere per Ember CLI, ma potrebbero esserlo per Ember.

Di nuovo, Ember CLI non gestisce il rendering. Lo fa Ember e, a volte, presenta problemi di prestazioni. Tieni presente che non si tratta di qualcosa di specifico di Ember: tutti i framework attuali hanno trappole prestazionali di cui bisogna essere consapevoli. Dopo anni di lavoro con Ember, abbiamo identificato due percorsi critici (la pagina principale e la visualizzazione dei topic) che necessitavano di migliori prestazioni e abbiamo optato per un approccio basato su virtual DOM.

Potrebbe non essere sempre necessario farlo, a seconda di come funzioneranno Glimmer e Ember Octane, ma il codice è piuttosto stabile ed esegue velocemente anche su dispositivi mobili più vecchi.

Ember Octane è stato introdotto nella versione 3.15 e da allora sono state rilasciate due versioni LTS (3.16 e 3.21). Lo aggiorneremo, ma in fasi. Fortunatamente, il team di Ember permette di scegliere attivamente (anche a livello di singolo file!) quale formato utilizzare.

Detto questo, c’è molto da criticare riguardo a Ember. Quando le prestazioni erano un problema più grande per Discourse, ci sono state alcune versioni promesse che alla fine ci hanno danneggiato invece di aiutarci. È stato difficile. Abbiamo dovuto tenerlo sotto stretta osservazione per molto tempo per soddisfare le nostre esigenze.

Oggi, ha anche una frazione della popolarità di framework più recenti come React. Tuttavia, React non esisteva 8 anni fa! Le nostre uniche scelte erano Angular, Ember e Knockout. Se pensi che aggiornare Ember sia difficile, potresti vedere cosa ha dovuto affrontare Angular passando dalla versione 1 alla 2 (senza contare le loro avventure collaterali con Dart!).

Aggiornare Ember nel corso degli anni è stato molto lavoro, ma almeno è un’opzione! Nessuno degli altri framework offriva un percorso di aggiornamento simile.

Per quanto riguarda la riscrittura in Vue/Next/React, penso che le persone sottovalutino enormemente quanto codice abbiamo che funziona perfettamente. Sarebbe un lavoro inimmaginabile.

19 Mi Piace
104

Sì, è corretto. Quando la tua utenza utilizza dispositivi datati, il tuo sito verrà generalmente valutato meno.

6 Mi Piace
105

Ci sto pensando @justin e @awesomerobot, ma volevo che Robin si esprimesse prima sui dettagli di Ember CLI.

Nel suo nucleo, c’è un po’ di quel paradosso del “Cosa succede quando una forza inarrestabile incontra un oggetto immovibile?” .. siamo intenzionalmente un’app JavaScript (o SPA), e questo comporta dei compromessi che abbiamo deciso di fare nel 2012/2013 basandoci sulla nostra migliore ipotesi su come sarebbe stato il futuro nel 2022/2023. Anche se sono ovviamente di parte, direi che la nostra previsione che “eh beh, le prestazioni dei browser sui dispositivi mobili sarebbero state indistinguibili da quelle dei browser desktop” era azzeccata.

Cavolo, abbiamo anche superato l’obiettivo, dato che i telefoni Apple più recenti sono più veloci dei laptop e dei desktop. :astonished_face: Questo .. non me l’aspettavo!

:bullseye:

Continueremo a migliorare ciò che possiamo sulla velocità di caricamento iniziale – e sulla velocità in generale – ma penso che il nostro record qui sia lodevole. Per cominciare, abbiamo ottenuto così tanta pubblicità nel 2015 che Google internamente ha apportato una serie di miglioramenti a V8, Chrome e Android per affrontare le scarse prestazioni dei SoC Qualcomm misurate in JavaScript.

Il nostro tallone d’Achille è stato .. Qualcomm. Purtroppo, Qualcomm non ha fatto molto sul fronte delle prestazioni fino ad ora, dato che il dispositivo Android “migliore” si attesta a circa il livello di un iPhone 7. Ci vuole molto tempo perché i dispositivi Android più vecchi escano dal mercato, ma l’855 e l’865 erano entrambi prestazioni decenti a circa il livello di un iPhone 7:

image
image2110×1854 536 KB

Devo scorrere più in basso per arrivare a un dispositivo Apple lento quanto il dispositivo Android più veloce, ma se lo faccio, la corrispondenza più vicina è l’iPhone X / iPhone 8 a ~910 in Geekbench. Purtroppo l’865, per ragioni che non comprendo appieno, performa un po’ meno sul lato web, quindi siamo ancora ai livelli di prestazioni dell’iPhone 7 in Speedometer:

image
image650×650 30.8 KB

Vorrei davvero vivere in un mondo in cui ci fossero dispositivi Android dotati di una varietà di SoC da diverse aziende che competono per costruire i SoC più veloci e potenti.. :crying_cat: Sul lato positivo, le prestazioni dell’iPhone 7 sono solide per Discourse e sono felice che alla fine tutti i dispositivi Android, anche quelli vecchi, saranno “almeno veloci quanto un iPhone 7”. Ho anche le dita incrociate per il prossimo Snapdragon 875, dovrebbero esserci più dettagli nei prossimi mesi. :crossed_fingers:

Secondo i risultati di Geekbench 5, possiamo vedere che lo Xiaomi Mi 11 è alimentato dal Snapdragon 875 a 5nm (come accennato da nientemeno che Lu Weibing, dirigente di Xiaomi). Il futuro Xiaomi Mi 11 è riuscito a ottenere 1.102 punti nel benchmark single-core e 4.113 punti nel test multi-core.

Se è vero, questo lo collocherebbe al livello dell’A12, e speriamo che questo si manifesti anche sul lato web!

Comunque, c’è una decisione architettonica fondamentale qui a Discourse di essere un’app JavaScript … e siamo pienamente impegnati su questa strada per il futuro prevedibile.

Deal_with_it_dog_gif

23 Mi Piace
109

Per chi tiene d’occhio le proprie statistiche, ecco un’altra data da segnare. Sarà interessante vedere cosa accadrà nelle prossime settimane in relazione al più recente aggiornamento core di Google, quello di dicembre 2020.

https://searchengineland.com/googles-december-2020-core-update-was-big-even-bigger-than-may-2020-says-data-providers-344429

1 Mi Piace
110

Non possiamo dimenticare i nuovi Mac con Apple Silicon annunciati di recente! :grinning:

Per pura curiosità, da dove è arrivata quella pubblicità?

Il chip A10 sta ancora reggendo a stento.

Per sicurezza, tengo basse le aspettative. Apple è sempre stata avanti.

Detto questo, gli smartphone Android stanno ancora cercando di recuperare. È assolutamente ridicolo. Apple ha già il chip A14 e probabilmente sta già lavorando sull’A15 per l’anno prossimo.

2 Mi Piace
111

Grazie per aver condiviso. Alcuni punti rilevanti per questa discussione da estrarre dall’articolo:

Cosa fare se sei stato colpito. Google ha fornito consigli su cosa considerare se sei stato negativamente colpito da un aggiornamento principale in passato. Non ci sono azioni specifiche da intraprendere per recuperare e, anzi, un impatto negativo sul posizionamento potrebbe non segnalare che ci sia qualcosa di sbagliato nelle tue pagine. Tuttavia, Google ha offerto un elenco di domande da considerare se il tuo sito è stato colpito da un aggiornamento principale. Google ha anche detto che puoi vedere un po’ di recupero tra gli aggiornamenti principali, ma il cambiamento più significativo che noteresti avverrebbe dopo un altro aggiornamento principale.

Anche questo è utile.

https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184

7 Mi Piace
112

A mio avviso, quando si parla di SEO, ovvero l’ottimizzazione dei risultati dei motori di ricerca rispetto ad altri siti, parlare dell’hardware dell’utente è in gran parte irrilevante.

Perché?

È in realtà abbastanza semplice.

Prendiamo il caso di una persona e dei suoi risultati di ricerca sul dispositivo portatile.

Indipendentemente dalla velocità del dispositivo o dal chipset, le prestazioni saranno simili su tutti i siti web perché l’esperienza dell’utente finale (le prestazioni) di un singolo dispositivo dell’utente finale sulla rete sarà, per la maggior parte, la stessa su tutti i siti web di prestazioni simili. I siti web più veloci saranno più veloci e quelli più lenti saranno più lenti, indipendentemente dal chipset o da altri fattori del dispositivo dell’utente finale. Un’alta marea alza tutte le barche e una bassa marea le abbassa tutte. Nella SEO, il dispositivo dell’utente finale è “rumore” rispetto al segnale SEO rispetto all’applicazione di servizio, che è ciò che viene ottimizzato nella “SEO”.

Quindi, se un telefono mobile è il telefono più veloce dell’intero universo, tutti i siti web saranno veloci (o lenti) a seconda della velocità della rete e della progettazione del sito web. Il focus della SEO è sull’ottimizzazione dell’applicazione web e della sua distribuzione, non sui dispositivi dell’utente finale. Se un’app web funziona “straordinariamente bene” su un chipset, lo fanno anche tutti gli altri siti web di design simile. Il focus della SEO non è il dispositivo dell’utente finale; è l’ottimizzazione dell’applicazione web, dei contenuti, dei tempi di caricamento basati sul server; non sul dispositivo client. I dispositivi client visitano, in teoria, tutti i siti web, quindi tutto ciò è “rumore” nel rapporto segnale-rumore della SEO.

Da una prospettiva SEO del sito web, la tua ottimizzazione per i motori di ricerca basata sull’esperienza utente sarà la stessa sulla rete per tutti gli utenti della stessa classe (caratteristiche di prestazioni) di tutti i dispositivi mobili dell’utente finale. L’unica cosa che darà a un sito web un vantaggio SEO rispetto a un altro sarà le prestazioni del sito web (e della sua rete), non dei dispositivi dell’utente finale.

Perché?

Perché i dispositivi dell’utente finale si comporteranno allo stesso modo su tutti i siti web, in generale. Se il mobile dell’utente è lento a causa della memoria o del chipset, sarà lento in tutto il cyberuniverso dei siti web. In altre parole, la discussione su come i dispositivi dell’utente finale influenzino la SEO è superflua. L’ottimizzazione per i motori di ricerca è un’operazione lato server, non lato client.

Ciò che conta è il contenuto, la presentazione e le prestazioni; e come l’AI di Google valuta questi fattori in tutto il cyberuniverso. Se, ad esempio, tutti nel mondo intero aggiornassero a telefoni mobili con calcolo quantistico, la SEO sarebbe la stessa perché tutti gli utenti finali avrebbero le stesse “curve di prestazioni dei dispositivi dell’utente finale”. L’ottimizzazione avviene presso il provider (il sito web). Allo stesso modo, se l’intero cyberuniverso degenerasse in telefoni mobili con chipset lenti, i posizionamenti nei motori di ricerca rimarrebbero in gran parte gli stessi; perché l’ottimizzazione che deve avvenire, avviene dai server che servono i contenuti web.

Certo, Discourse, in quanto SPA guidata da JavaScript, funzionerà meglio dopo il caricamento se i dispositivi mobili sono più veloci. Lo fanno anche tutti gli altri siti web! In generale, ciò che conta è anche le prestazioni della rete e le prestazioni del server, non il dispositivo dell’utente finale per quanto riguarda la SEO. Questa non è la mia opinione, è un fatto scientifico e ingegneristico. La mia opinione o connessione emotiva con JavaScript o EmberJS non cambiano il modo in cui funziona la SEO. Ciò che funziona per la SEO è il contenuto e le prestazioni dell’applicazione web.

In conclusione, Google utilizza un’AI avanzata, principalmente reti neurali artificiali, per determinare come Google classifica e indicizza i contenuti web. L’ottimizzazione per i motori di ricerca si basa su come l’AI di Google classifica il sito, le prestazioni del sito e il suo “appeal per l’AI di Google”. Quanto amiamo JavaScript, Ruby o Python, o quanto ci piace o adoriamo l’eleganza e i meccanismi di qualsiasi applicazione web che forniamo agli utenti finali non è rilevante; a meno che la nostra passione per la nostra applicazione non appelli all’AI di Google e stiamo creando contenuti unici presentati bene all’AI di Google e su come l’AI di Google percepisce le prestazioni; non su come noi percepiamo le prestazioni e i contenuti.

Non classifichiamo i nostri siti web. È l’AI di Google a fare la classificazione.

Come ha dichiarato pubblicamente Google:

“Un modo per pensare a come opera un aggiornamento principale è immaginare di aver creato una lista dei 100 migliori film del 2015. Qualche anno dopo, nel 2019, aggiorni la lista. Cambierà naturalmente. Alcuni nuovi e meravigliosi film che prima non esistevano saranno ora candidati per l’inclusione. Potresti anche rivalutare alcuni film e renderti conto che meritavano un posto più alto nella lista rispetto a prima. La lista cambierà, e i film precedentemente più in alto nella lista che scendono non sono cattivi. Ci sono semplicemente film più meritevoli che vengono prima di loro,” ha scritto Google.

L’azienda ha offerto la seguente lista di domande da considerare quando si valuta il proprio contenuto:

  • Il contenuto fornisce informazioni originali, reportage, ricerche o analisi?
  • Il contenuto fornisce una descrizione sostanziale, completa o esauriente dell’argomento?
  • Il contenuto fornisce un’analisi approfondita o informazioni interessanti che vanno oltre l’ovvio?
  • Se il contenuto attinge ad altre fonti, evita di copiarle o riscriverle semplicemente e fornisce invece un valore sostanziale aggiuntivo e originalità?
  • Il titolo e/o il titolo della pagina forniscono un riassunto descrittivo e utile del contenuto?
  • Il titolo e/o il titolo della pagina evitano di essere esagerati o scioccanti?
  • È il tipo di pagina che vorresti segnare, condividere con un amico o raccomandare?
  • Ti aspetteresti di vedere questo contenuto in una rivista stampata, un’enciclopedia o un libro, o che vi fosse fatto riferimento?

Questa è la SEO e il business principale di Google è creare algoritmi in modo che le macchine possano valutare e classificare i siti web.

https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184

2 Mi Piace
113

Ciò è incoerente con quanto registrato: sappiamo che Google raccoglie i tempi reali di caricamento delle pagine dai dispositivi Android e li utilizza per il posizionamento delle pagine.

4 Mi Piace
114

Sì, ma tutti i dispositivi Android (dello stesso tipo) si comportano sostanzialmente allo stesso modo per tutti i siti web (dello stesso tipo). In altre parole, se ottimizzi un sito web basato su JavaScript che utilizza webpacker e bundler, stai competendo, dal punto di vista SEO, con tutti gli altri siti che sono SPA in JavaScript che utilizzano webpacker e bundler, ecc.

Non ho detto che Google non raccoglie queste informazioni. Sto cercando di spiegare che concentrarsi sul dispositivo client non risolverà il problema delle prestazioni SEO delle SPA. Una “marea crescente alza tutte le barche”, quindi una CPU più veloce che elabora bene gli JS compressi (veloci, ottimizzati, ecc.) si comporterà bene su tutti i siti web simili.

In altre parole, la SEO è lato server (come ho scritto sopra in modo dettagliato e lungo), non lato client.

È ampiamente documentato, a proposito.

Lascia perdere :). Preferisco non discutere di questo qui su meta. Grazie.

Google è stato molto chiaro su quali segnali SEO consideri importanti, ora e fino al 2021. Ridisegneranno costantemente la loro AI in base a eventi e situazioni nel cyberspazio.

2 Mi Piace
115

Dal punto di vista SEO, sei effettivamente in concorrenza con siti tecnicamente simili.

Tuttavia, dal punto di vista commerciale, sei in concorrenza con altri siti nel tuo mercato, indipendentemente dalla loro tecnologia. Questo potrebbe spingere le persone a valutare il passaggio a una tecnologia percepita come “migliore” dal punto di vista SEO. È esattamente la situazione in cui si trovano alcune persone.

5 Mi Piace