Google Sheets IMPORTXML ha raggiunto i limiti: 7 segnali che è tempo di passare al proprio parser con proxy

Se stai monitorando i prezzi dei concorrenti su Wildberries, Ozon o Avito tramite IMPORTXML in Google Sheets, prima o poi il foglio di calcolo inizia a restituire errori #N/A, i dati vengono aggiornati con un ritardo di ore e a volte smettono completamente di caricarsi. Questo non è un bug, ma un limite intrinseco di Google Sheets e della protezione dei siti contro le richieste massicce dallo stesso indirizzo IP di Google. In questo articolo analizzeremo quali segni indicano che il foglio ha esaurito le sue risorse e come passare senza problemi a un proprio parser con proxy.

Come funziona IMPORTXML e perché viene utilizzato

IMPORTXML è una funzione integrata di Google Sheets che recupera dati da una pagina tramite una richiesta XPath e li inserisce direttamente nella cella. Una formula del tipo =IMPORTXML("URL"; "//span[@class='price']") consente di estrarre senza alcuna riga di codice il prezzo di un prodotto dalla scheda su Wildberries o Ozon e di aggiornarlo automaticamente ogni ora.

Per i venditori e i marketer, sembra una soluzione ideale: non è necessario un sviluppatore, non è necessario un server, tutto funziona direttamente nel foglio di calcolo familiare. Un piccolo negozio con 20-30 prodotti può effettivamente vivere per anni con un solo IMPORTXML, senza notare problemi. Ma non appena il numero di SKU monitorati supera un paio di centinaia e la frequenza di aggiornamento necessaria non è una volta al giorno, ma una volta all'ora, iniziano i guasti sistematici che non possono essere risolti con le impostazioni della funzione stessa.

Il problema è che tutte le richieste IMPORTXML provengono dai server di Google, non dal tuo computer. Google ha un pool limitato di indirizzi IP per tali richieste e i marketplace conoscono perfettamente questi intervalli. Quando le richieste diventano numerose, scatta la protezione del sito e invece del prezzo nella cella appare un errore o un valore vuoto.

7 segni che IMPORTXML non sta più funzionando

Prima di perdere tempo a passare a una soluzione più complessa, assicurati che il problema sia effettivamente nei limiti e non in un errore di battitura nella formula. Ecco i sintomi specifici che lo indicano:

1. Massivi #N/A — contemporaneamente smettono di funzionare il 30-50% delle formule, anche se ieri tutto andava bene e la struttura delle pagine non è cambiata.
2. Aumento del ritardo di aggiornamento — prima i dati venivano aggiornati in 5-10 minuti, ora il foglio "pensa" 30-40 minuti o non si aggiorna affatto senza un ricalcolo manuale.
3. Errore "Resource at url contacted too many times" — un messaggio diretto di Google che indica che hai raggiunto il limite interno di richieste a un dominio.
4. I dati arrivano obsoleti — il prezzo nel foglio è diverso da quello reale sul sito, perché Google restituisce una versione cache della pagina invece di quella attuale.
5. Il numero di righe supera 300-500 — più formule IMPORTXML ci sono in un documento, maggiore è la probabilità di un ban collettivo per dominio.
6. È necessaria una frequenza di aggiornamento più frequente di una volta all'ora — IMPORTXML non è fisicamente progettato per il monitoraggio in tempo reale, non ha un meccanismo di rotazione degli IP.
7. Il sito richiede autenticazione o captcha — Wildberries e Ozon mostrano sempre più spesso pagine con verifica JavaScript, che IMPORTXML non riesce a superare in linea di principio.

Se hai riscontrato almeno 2-3 punti dell'elenco, non si tratta di un glitch temporaneo di Google Sheets, ma di un limite strutturale della tecnologia. Puoi continuare a riparare le formule, aggiungere IFERROR e ricalcolare manualmente, ma il volume di lavoro manuale crescerà più velocemente del volume di dati utili.

Perché i siti bloccano le richieste da Google Sheets

I marketplace come Wildberries e Ozon ricevono ogni giorno milioni di richieste automatiche da concorrenti, servizi di analisi e bot. Per non sovraccaricare i server e proteggere i dati sui prezzi da scraping massivo, implementano diversi livelli di protezione:

• Limitazione della velocità per IP — se da un indirizzo arrivano più di N richieste al minuto, l'IP viene bloccato temporaneamente.
• Analisi dell'User-Agent — le richieste dai bot di Google per IMPORTXML sono facilmente distinguibili da un normale browser tramite gli header.
• Rendering JavaScript — parte del contenuto viene caricato dinamicamente tramite script, e IMPORTXML vede solo l'HTML originale senza eseguire JS.
• Geo-filtraggio — le richieste dagli IP server di Google spesso rientrano nel filtro "non sembra un acquirente reale".

Il problema principale è che tutti gli utenti di IMPORTXML in tutto il mondo utilizzano tecnicamente lo stesso limitato set di indirizzi IP server di Google. Quando migliaia di fogli di calcolo interrogano contemporaneamente lo stesso dominio Wildberries, la protezione del sito non banna un singolo utente, ma un intero intervallo — e ne soffrono tutti, compreso te.

IMPORTXML vs parser no-code vs proprio parser: tabella comparativa

Passare dalla funzione integrata di Google Sheets non significa necessariamente assumere un programmatore. Ci sono opzioni intermedie. Confrontiamo tre approcci in base a parametri chiave:

Criterio	IMPORTXML	Parser no-code (Octoparse, ParseHub)	Proprio parser con proxy
Necessità di codice	No	No	Sì (o un appaltatore)
Limite di richieste	Rigido, nascosto	Dipende dal piano	Controlli tu stesso
Rotazione IP	Non disponibile	Integrata parzialmente	Controllo completo tramite proxy
Lavoro con pagine JS	No	Sì	Sì (con Selenium/Playwright)
Frequenza di aggiornamento	Una volta all'ora o meno	Configurabile	Qualsiasi, fino al tempo reale
Scalabilità (SKU)	Fino a 200-300	Fino a diverse migliaia	Senza limiti pratici

I parser no-code sono un buon passo intermedio se è necessario chiudere rapidamente un compito senza sviluppatore. Ma se il monitoraggio dei prezzi è un processo aziendale continuo e non un compito una tantum, avere un proprio parser con proxy ripaga grazie al controllo sui dati e all'assenza di dipendenza da un servizio esterno e dai suoi limiti.

Quali proxy sono necessari per il parsing dei marketplace

La principale ragione per cui un proprio parser funziona in modo più stabile di IMPORTXML è la possibilità di distribuire le richieste tra diversi indirizzi IP invece di un unico pool server di Google. Ma anche il tipo di proxy è importante:

• Proxy di data center — la soluzione più veloce e accessibile per iniziare. Adatti se il marketplace non ha ancora riconosciuto il modello delle richieste automatiche. Ottimi per i primi test del parser e un numero ridotto di SKU.
• Proxy residenziali — utilizzano indirizzi IP reali di provider domestici, quindi appaiono per Wildberries e Ozon come normali acquirenti. Questa è l'opzione principale per il monitoraggio regolare dei prezzi su scala industriale, quando è importante non essere bannati per geo o per modello di traffico.
• Proxy mobili — IP di operatori mobili, che i marketplace bannano molto riluttantemente, poiché dietro un unico IP mobile possono esserci migliaia di utenti diversi contemporaneamente. Rilevanti se è necessario il parsing tramite versioni mobili del sito o dell'applicazione.

Per iniziare il monitoraggio dei prezzi su Wildberries e Ozon, la combinazione ottimale è: proxy residenziali con rotazione IP per ogni richiesta o ogni pochi minuti. Questo riduce il rischio di incorrere in un limite di velocità e consente di distribuire migliaia di richieste tra centinaia di indirizzi diversi, simulando il comportamento di normali utenti provenienti da diverse regioni.

Piano passo-passo per passare al proprio parser

Passare da IMPORTXML non richiede di fermare completamente il lavoro: il foglio può essere mantenuto come canale di riserva mentre il nuovo parser viene testato.

1. Fissa l'elenco degli SKU e dei selettori XPath già utilizzati nelle formule IMPORTXML: questa è una mappa dei dati pronta per la nuova soluzione.
2. Scegli il formato del parser: servizio no-code (Octoparse, ParseHub, Apify) per un avvio rapido senza programmatore, oppure uno script in Python/Node.js, se nel team c'è uno sviluppatore o un freelancer.
3. Collega i proxy con rotazione IP. Senza questo, il nuovo parser si troverà ad affrontare gli stessi blocchi di IMPORTXML, solo un po' più tardi.
4. Imposta un programma di richieste con piccole pause casuali tra le richieste (2-5 secondi) — questo riduce la probabilità di attivare la protezione per modello.
5. Esporta i dati nuovamente in Google Sheets tramite Google Sheets API o un servizio come Zapier/Make, per non rompere i report e i dashboard familiari al team.
6. Testa su 10-15% dei prodotti per una settimana, confrontando l'accuratezza con i dati delle vecchie formule IMPORTXML, prima di passare completamente.
7. Imposta avvisi sugli errori — notifica su Telegram o email se il parser inizia a ricevere captcha o codice 403, per cambiare subito proxy o ridurre la frequenza delle richieste.

Parser minimo in Python con proxy

Se nel team c'è uno sviluppatore, la versione base del parser occupa letteralmente solo alcune decine di righe di codice. Di seguito è riportato un esempio semplificato di richiesta di una pagina prodotto tramite proxy utilizzando la libreria requests:

import requests
import time
import random

proxies = {
    "http": "http://login:password@proxy_host:port",
    "https": "http://login:password@proxy_host:port",
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36"
}

urls = [
    "https://example-marketplace.com/product/12345",
    "https://example-marketplace.com/product/67890",
]

for url in urls:
    try:
        response = requests.get(url, headers=headers, proxies=proxies, timeout=10)
        if response.status_code == 200:
            # successivo parsing del prezzo tramite BeautifulSoup o lxml
            print(f"OK: {url}")
        else:
            print(f"Stato {response.status_code} per {url}")
    except requests.exceptions.RequestException as e:
        print(f"Errore di richiesta: {e}")

    time.sleep(random.uniform(2, 5))  # pausa tra le richieste

Per le pagine con caricamento dinamico del prezzo tramite JavaScript (caratteristico per Wildberries e Ozon), invece del normale requests sarà necessario Selenium o Playwright, che sono in grado di eseguire il rendering della pagina proprio come un browser reale e supportano anch'essi la trasmissione di proxy tramite i parametri di avvio.

Checklist prima del lancio

Conclusione

IMPORTXML è uno strumento eccellente per iniziare, finché l'elenco dei prodotti è ridotto e la frequenza di aggiornamento non è critica. Ma non appena inizi a vedere massivi #N/A, ritardi crescenti e messaggi di errore diretti sui limiti, è un segnale che la funzione integrata di Google Sheets ha raggiunto il limite architettonico. Tecnologicamente, questo non può essere risolto con le impostazioni del foglio, poiché il problema risiede nel pool limitato di indirizzi IP di Google, che i marketplace bannano completamente.

Passare a un proprio parser, sia esso un servizio no-code o uno script in Python, risolve il problema proprio grazie al controllo sugli indirizzi IP delle richieste. Se prevedi un monitoraggio regolare dei prezzi su Wildberries, Ozon o Avito su scala industriale, ti consigliamo di iniziare con proxy residenziali — offrono il minor rischio di blocco grazie alla somiglianza con il traffico degli acquirenti reali. Per test rapidi all'inizio, puoi accontentarti di proxy di data center più economici, mentre per scenari con versioni mobili dei siti, potresti considerare proxy mobili.