La risposta breve
L'indicizzazione mobile-first e completata. Da luglio 2024, Google utilizza solo la versione mobile del tuo sito per l'indicizzazione e il posizionamento. Se contenuti, dati strutturati o link interni esistono nella versione desktop ma non in quella mobile, Google non li vede. Nel 2026, ci sono tre nuove conseguenze che la maggior parte dei proprietari di siti non ha ancora affrontato: l'INP ha sostituito il FID come Core Web Vital, gli AI Overviews estraggono contenuti renderizzati su mobile e il Core Update di marzo 2026 ha aumentato il peso dell'esperienza di pagina mobile nel ranking.
Di seguito troverai un flusso di lavoro completo per l'audit e una skill Codex pronta all'uso che esegue la maggior parte dei controlli per te.
Cosa significa davvero "solo mobile" nel 2026
Google ha iniziato a migrare i siti all'indicizzazione mobile-first nel 2018. La transizione ha richiesto oltre sei anni. Da luglio 2024, ogni sito che aveva ancora contenuti accessibili su desktop senza un equivalente mobile ha perso quei contenuti dall'indice di Google. Non esiste alcuna possibilita di opt-out ne un fallback solo desktop.
Ma la storia non e finita qui. Tre cambiamenti nel 2025-2026 hanno modificato cio che il "mobile-first" richiede dal tuo sito:
Cambiamento 1: L'INP ha sostituito il FID — e la maggior parte dei siti mobile non lo supera
A marzo 2024, Google ha sostituito il First Input Delay (FID) con l'Interaction to Next Paint (INP) come Core Web Vital. L'INP misura la velocita con cui la pagina risponde a tap, clic e pressioni di tasti durante l'intera sessione sulla pagina, non solo alla prima interazione.
Il dato concreto: circa il 40% dei siti che superavano il FID non superano l'INP. Su mobile, solo il 65% circa dei siti soddisfa la soglia "buona" di 200 millisecondi o meno. Il Core Update di marzo 2026 ha aumentato ulteriormente il peso dei Core Web Vitals nel ranking. I siti che non superano l'INP mobile stanno ora perdendo posizioni a favore di concorrenti piu veloci.
Cambiamento 2: Gli AI Overviews e i crawler AI leggono i tuoi contenuti mobile
Gli AI Overviews di Google appaiono in circa il 47% delle ricerche a meta 2026. Quando i sistemi AI di Google generano risposte, attingono dagli stessi contenuti indicizzati su mobile utilizzati dalla ricerca tradizionale. Anche i crawler AI di terze parti (GPTBot, ClaudeBot, PerplexityBot) accedono alle tue pagine renderizzate su mobile.
Se la tua versione mobile e priva di dati strutturati, intestazioni chiare o testo critico, i sistemi AI non possono citarti, anche se la versione desktop contiene quei contenuti.
Cambiamento 3: Le lacune nella parita dei contenuti hanno ora un impatto misurabile sul ranking
Nel 2026, i siti con contenuti mobili e desktop incoerenti mostrano in media un'esposizione di ricerca organica inferiore del 31,2% rispetto ai siti con piena parita di contenuti. Gli elementi piu comunemente mancanti su mobile: contenuti nascosti nelle tab, link della sidebar, markup dei dati strutturati, testo alternativo delle immagini e link di navigazione interni.
Elemento di contenuto | % di siti che ne sono privi su mobile |
|---|---|
Dati strutturati (JSON-LD) | 23% |
Link interni (menu, breadcrumb) | 18% |
Testo alternativo delle immagini | 27% |
Testo completo in tab/accordion | 15% |
Meta tag robots | 9% |
Come verificare se il tuo sito supera i controlli (versione da 2 minuti)
Prima di eseguire un audit completo, controlla questi tre segnali. Ognuno richiede meno di un minuto e ti dice se vale la pena approfondire.
Segnale 1: Stato di indicizzazione in Google Search Console
Apri Google Search Console → clicca su Impostazioni (icona dell'ingranaggio, in basso a sinistra) → cerca la sezione "Informazioni". Se sotto "Crawler di indicizzazione" appare "Googlebot per smartphone", il tuo sito e in indicizzazione mobile-first. Nel 2026 questo vale praticamente per tutti i siti, ma verificalo.
Controlla anche: Strumento di ispezione URL → inserisci una pagina importante → espandi "Scansione" → conferma "Eseguita scansione come: Googlebot per smartphone". Guarda lo screenshot fornito da Google: e esattamente cio che Google vede. Se contenuti chiave mancano da quello screenshot, mancano anche dall'indice.
Segnale 2: PageSpeed Insights con dati reali su mobile
Vai su PageSpeed Insights, inserisci il tuo URL e cerca la sezione "Scopri cosa sperimentano i tuoi utenti reali". Questi sono i dati sul campo del Chrome User Experience Report (CrUX), gli stessi dati che Google utilizza per il ranking.
Se il report mobile mostra arancione o rosso per l'INP (Interaction to Next Paint), hai una penalizzazione attiva nel ranking. La soglia e inferiore a 200 millisecondi per il verde.
Segnale 3: Controllo rapido del viewport mobile in Chrome DevTools
Apri Chrome DevTools (F12 o Cmd+Option+I), clicca sull'icona della barra dispositivi (Ctrl+Shift+M) e seleziona un preset di dispositivo mobile come "Pixel 7". Ricarica la pagina. Verifica:
- Testo che richiede lo scorrimento orizzontale
- Pulsanti o link troppo piccoli per essere toccati (meno di 48x48 pixel CSS)
- Contenuti nascosti dietro toggle "leggi di piu" non presenti nel sorgente HTML
- Pop-up che coprono la maggior parte dello schermo
Ognuno di questi e un problema di indicizzazione mobile-first se i contenuti o i link dietro di essi differiscono da cio che vedono gli utenti desktop.
L'audit mobile-first in 30 minuti (con Codex)
Il modo piu rapido per eseguire un audit mobile-first completo oggi e affidare a un agente di codifica AI — Claude Code o Codex — un compito strutturato. L'agente legge il sorgente del tuo sito, verifica le regole e produce un elenco prioritario di correzioni.
Di seguito trovi un file skill completo. Copialo nel tuo progetto, poi chiedi al tuo agente di eseguirlo.
Passo 1: Crea il file skill
Crea un file in .claude/skills/mobile-first-audit/SKILL.md (per Claude Code) o .codex/skills/mobile-first-audit/SKILL.md (per Codex):
name: mobile-first-audit
description: Audit a URL or list of URLs for mobile-first indexing readiness. Checks content parity, Core Web Vitals, structured data, mobile UX, and AI crawler access.
# Mobile-First Indexing Audit
Run a structured mobile-first indexing audit on one or more URLs. The agent must report findings, not make edits, unless the user explicitly approves a fix plan.
## Input
The user provides one or more page URLs. If they provide a sitemap URL or a list of more than 5 URLs, sample 5 URLs that represent different page types (homepage, product page, article, category page, landing page).
## Audit Checklist
For each URL, check and report on all eleven items below. Mark each item as `PASS`, `WARN`, or `FAIL`. Include the evidence for every WARN and FAIL.
### 1. Viewport Meta Tag
Check that `<meta name="viewport" content="width=device-width, initial-scale=1">` is present in the HTML `<head>`. If missing or if it sets a fixed width or disables user-scaling without a valid accessibility reason, mark FAIL.
### 2. Content Parity (Text)
Fetch the page with a desktop user-agent and a mobile user-agent (Googlebot Smartphone). Compare the visible text content. If any text block over 50 words exists on desktop but not in the mobile HTML source, mark WARN. If important body text, headings, or product descriptions are missing, mark FAIL.
### 3. Structured Data Parity
Extract all JSON-LD blocks from both desktop and mobile fetches. If any schema type present on desktop is missing from mobile, mark FAIL. If schema content differs between versions, mark WARN.
### 4. Meta Tags Parity
Compare title, meta description, canonical, robots, and hreflang tags between desktop and mobile versions. Any difference is a WARN. A missing canonical or conflicting robots tag is FAIL.
### 5. Internal Links and Navigation
Count the number of internal `<a href>` links in the desktop and mobile HTML. If the mobile version has 20%+ fewer internal links, mark WARN. If breadcrumb links, category navigation, or footer links present on desktop are missing from mobile, mark FAIL.
### 6. Image Alt Text
Count images in the mobile HTML. Report the number and percentage missing alt attributes. If more than 10% of images lack alt text, mark WARN. If hero images or product images lack alt text, mark FAIL.
### 7. Core Web Vitals (Field Data)
Look up the URL's Chrome UX Report (CrUX) field data. If accessible via PageSpeed Insights API or a direct CrUX lookup, report LCP, INP, and CLS for mobile. Mark thresholds: LCP > 2.5s = WARN, > 4.0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0.1 = WARN, > 0.25 = FAIL.
If CrUX data is unavailable (insufficient traffic), note this and use lab data from Lighthouse as a fallback with the caveat that lab data is not used for ranking.
### 8. Tap Target Sizing
Inspect CSS for buttons, links, and interactive elements. Flag any element whose computed height or width is under 48 CSS pixels. Flag adjacent interactive elements with less than 8px spacing. Mark WARN for 1-3 violations, FAIL for 4+.
### 9. Font Sizing
Check that body text uses a computed font-size of at least 16px. Flag any text below 12px. Mark WARN if body text is 14-15px, FAIL if below 12px.
### 10. Interstitials and Pop-ups
Visually inspect the mobile viewport. If a pop-up, banner, or interstitial covers more than 30% of the initial viewport and is not legally required (cookie consent, age verification), mark WARN. If the pop-up prevents scrolling or reading content, mark FAIL.
### 11. AI Crawler Access
Check robots.txt for rules blocking GPTBot, ClaudeBot, PerplexityBot, Google-Extended, or OAI-SearchBot. If any AI crawler is blocked, note that as a deliberate choice. If AI crawlers are allowed but the page has no structured data, mark WARN (AI systems rely on structured data for citations).
## Output Format
Produce a Markdown report:
```markdown
# Mobile-First Audit Report
**Date:** YYYY-MM-DD
**URLs audited:** N
**Overall score:** X/11 PASS items per URL average
## Summary
| Check | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |
## Detailed Findings
### URL 1: [url]
**FAIL items (must fix):**
- [Item name]: [evidence and fix instructions]
**WARN items (should fix):**
- [Item name]: [evidence and fix instructions]
**PASS items:** [list]
### Priority Fix Queue
1. [Highest priority fix] — affects indexing directly
2. [Next fix] — affects ranking
3. ...Rules
- Do not make any changes to the site without explicit user approval of a fix plan.
- If you cannot check an item because the page requires authentication, note it as "NOT CHECKED — authentication required."
- For CrUX data, use the official Chrome UX Report API or PageSpeed Insights API if available. If neither is accessible, use Lighthouse mobile audit as a fallback.
- Never fabricate metrics, scores, or check results. If data is unavailable, say so.
- Do not access or expose API keys, cookies, tokens, or credentials.
### Passo 2: Esegui l'audit
Chiedi al tuo agente: **"Esegui la skill di audit mobile-first su [tuo URL]"** e incolla l'URL che vuoi controllare. L'agente produrra un report con PASS/WARN/FAIL per ciascuno degli 11 controlli, oltre a una coda di priorita delle correzioni.
Se vuoi controllare piu pagine contemporaneamente, fornisci un elenco: **"Esegui l'audit mobile-first su questi 5 URL: [URL1, URL2, URL3, URL4, URL5]"**.
## Correzione n.1: Parita dei contenuti — cosa controllare per primo
La parita dei contenuti e la correzione di maggior impatto perche determina direttamente cosa Google puo indicizzare. Ecco cosa si rompe piu spesso e come risolverlo.
### Contenuti nascosti in tab e accordion
Molti siti su mobile comprimono contenuti lunghi in tab, accordion o toggle "leggi di piu". Questo va bene **purche il contenuto sia nel sorgente HTML** — Google non penalizza piu i contenuti nascosti per motivi di UX. Ma se le tue tab caricano contenuti via JavaScript dopo un tap dell'utente, Googlebot non attiva quel tap. Il contenuto e invisibile.
**Come verificare:** In Chrome DevTools, clicca con il tasto destro sul contenuto nascosto e seleziona "Ispeziona". Se vedi il testo nel pannello Elementi, e nel DOM e Google puo vederlo. Se il pannello Elementi mostra un contenitore vuoto finche non clicchi sulla tab, il contenuto viene caricato dinamicamente e Google lo perde.
**Come correggere:** Esegui il rendering lato server del contenuto nascosto nell'HTML. Usa CSS (`display: none` o toggle di visibilita) per il comportamento mostra/nascondi invece dell'iniezione di contenuti via JavaScript.
### Dati strutturati mancanti su mobile
I dati strutturati (JSON-LD) devono essere presenti nell'HTML mobile. E facile dimenticarsene se il tuo tema mobile o la versione AMP utilizza un template diverso.
**Come verificare:** Apri la pagina mobile, visualizza il sorgente (`Cmd+Option+U`) e cerca `application/ld+json`. Poi fai lo stesso su desktop. Gli stessi blocchi JSON-LD dovrebbero apparire in entrambi.
**Come correggere:** Assicurati che i dati strutturati siano renderizzati lato server e inclusi nella stessa risposta HTML sia per mobile che per desktop. Se usi un CMS, verifica che il plugin schema o il tema non carichino script in modo condizionale in base al rilevamento del dispositivo.
### Link di navigazione rimossi dai menu mobile
I menu mobile spesso semplificano o rimuovono link presenti nella navigazione desktop: breadcrumb, link di categoria, colonne del footer, link della sidebar. Google utilizza i link interni per comprendere la struttura del sito e distribuire il PageRank. I link mancanti su mobile mancano anche dal grafo di Google.
**Come verificare:** Conta i tag `<a href>` nel sorgente desktop rispetto a quello mobile. Un design responsive dovrebbe avere conteggi approssimativamente uguali. Se il conteggio mobile e inferiore del 30% o piu, indaga su quali link sono scomparsi.
**Come correggere:** Aggiungi i link di navigazione mancanti al menu mobile, menu hamburger o footer. Dai priorita ai link verso pagine di categoria importanti, articoli chiave e pagine principali.
## Correzione n.2: INP — la metrica di velocita mobile che la maggior parte ignora
L'Interaction to Next Paint (INP) misura quanto tempo impiega la pagina a rispondere visivamente dopo un tap, clic o pressione di tasto dell'utente. La soglia e **200 millisecondi o meno**.
A differenza del FID, che misurava solo il ritardo di input della prima interazione, l'INP misura ogni interazione e riporta il risultato **peggiore**. Questo lo rende un test molto piu severo.
### Cosa penalizza l'INP mobile
Le cause piu comuni, in ordine:
1. **JavaScript pesante in esecuzione sul thread principale.** Bundle di grandi dimensioni, componenti React/Vue non ottimizzati e script di tracciamento bloccano la capacita del browser di rispondere ai tap.
2. **Gestori di clic che eseguono troppo lavoro prima di aggiornare l'interfaccia.** Se un tap attiva una chiamata API, un cambio di stato e una modifica del DOM prima di mostrare qualsiasi feedback visivo, l'INP ne risente.
3. **Tag di terze parti.** Analytics, widget di chat, reti pubblicitarie e script di personalizzazione, specialmente quando piu tag competono per il thread principale.
### Come diagnosticare l'INP
1. Apri [PageSpeed Insights](https://pagespeed.google.com/), inserisci il tuo URL, scorri fino a "Scopri cosa sperimentano i tuoi utenti reali". Il valore INP sotto "Mobile" e quello che Google utilizza.
2. In Chrome DevTools, apri il pannello **Performance**, clicca su registra, interagisci con la pagina (tocca pulsanti, apri menu, digita negli input), poi ferma la registrazione. Cerca task lunghi (segnati in rosso, 200ms+). Questi sono i tuoi problemi di INP.
3. Puoi anche chiedere al tuo agente AI: **"Controlla i Core Web Vitals per [URL] e dimmi esattamente cosa sta danneggiando l'INP su mobile. Dammi le prime 3 correzioni in ordine di priorita."**
### Come correggere l'INP (ordine di priorita)
```text
Priorita 1: Rimanda o ritarda gli script di terze parti non critici.
→ Carica widget di chat, analytics e tag pubblicitari dopo che la pagina e interattiva.
→ Usa <script defer> o caricali 3-5 secondi dopo il caricamento della pagina.
Priorita 2: Suddividi i task JavaScript lunghi.
→ Suddividi il codice per route. Carica in modalita lazy i componenti below the fold.
→ Sposta i calcoli pesanti in requestIdleCallback() o in un Web Worker.
Priorita 3: Fai in modo che i gestori di clic aggiornino immediatamente l'interfaccia.
→ Mostra uno stato di caricamento, uno spinner o un pulsante disabilitato entro i primi 50ms.
→ Esegui il lavoro effettivo (chiamata API, aggiornamento dello stato) dopo la risposta visiva.Correzione n.3: Preparazione ai crawler AI (il livello 2026)
L'indicizzazione mobile-first ha ora un livello AI. Quando gli AI Overviews di Google o i sistemi AI di terze parti rispondono a una domanda, attingono dagli stessi contenuti indicizzati su mobile. Se le tue pagine mobile mancano dei segnali che i sistemi AI cercano, perdi citazioni.
Cosa serve ai sistemi AI dalle tue pagine mobile
Segnale | Perche e importante | Controllo rapido |
|---|---|---|
Dati strutturati (JSON-LD) | Aiuta i sistemi AI a comprendere entita, prodotti, articoli, FAQ | Visualizza sorgente → cerca |
Gerarchia chiara delle intestazioni | Gli estrattori AI usano H1-H4 per analizzare la struttura della pagina | Scorri la pagina: ogni sezione ha un'intestazione descrittiva? |
Blocchi di risposta concisi | Gli AI Overviews preferiscono risposte di 2-4 frasi nella parte superiore | La tua pagina risponde alla domanda principale nelle prime 200 parole? |
Accesso robots.txt per i crawler AI | Se bloccati, i sistemi AI non possono recuperare i tuoi contenuti | Controlla robots.txt per |
File llms.txt | Aiuta i sistemi AI a scoprire efficientemente i tuoi contenuti chiave | Controlla |
Prompt rapido di verifica AI per il tuo agente
"Verifica [URL] per la preparazione alla ricerca AI. Dimmi: (1) i dati strutturati JSON-LD sono presenti e validi? (2) c'e una risposta chiara alla domanda principale della pagina nelle prime 200 parole? (3) i crawler AI sono autorizzati in robots.txt? (4) esiste llms.txt nella root? Dammi un PASS/FAIL per ciascuno e dimmi cosa correggere per primo."
Prompt completi per l'audit mobile-first per principianti
Ecco una serie di prompt che puoi copiare in Claude Code o Codex in questo momento. Ogni prompt svolge un compito specifico, senza necessita di configurazione oltre ad avere l'agente aperto e puntato al tuo progetto o URL.
Prompt 1: Audit mobile di una singola pagina
Run a mobile-first indexing audit on [YOUR URL HERE].
Check these 8 things and report PASS or FAIL for each with the evidence:
1. Viewport meta tag is correct
2. All body text visible on desktop is also in the mobile HTML source
3. JSON-LD structured data is the same on desktop and mobile
4. Title tag, meta description, and canonical are identical across desktop and mobile
5. Internal link count is roughly equal (not 20%+ fewer on mobile)
6. Images have alt text
7. Mobile Core Web Vitals (LCP, INP, CLS) from CrUX field data if available
8. AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are not blocked in robots.txt
For each FAIL, give me the exact fix in one sentence.Prompt 2: Audit massivo per tipi di pagina
I need to audit mobile-first readiness across different page types on my site. Here are 5 URLs, each representing a different template:
1. [HOMEPAGE URL]
2. [PRODUCT PAGE OR SERVICE PAGE URL]
3. [BLOG POST OR ARTICLE URL]
4. [CATEGORY OR COLLECTION PAGE URL]
5. [ABOUT OR CONTACT PAGE URL]
For each URL, check: viewport meta tag, content parity (text + structured data), meta tags consistency, internal links, image alt coverage, and mobile font/tap-target sizing.
Then produce a single table with all 5 URLs as columns and each check as a row. Color-code PASS green, WARN yellow, FAIL red (use emoji 🟢 🟡 🔴 if colors are not supported). Below the table, list the top 3 fixes across all pages in priority order.Prompt 3: Analisi approfondita della parita dei contenuti
Fetch [URL] with both a desktop user-agent and the Googlebot Smartphone user-agent (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).
Compare the two versions and report any differences in:
- Visible text content (highlight blocks missing from mobile)
- Structured data (JSON-LD blocks)
- Meta tags (title, description, canonical, robots, hreflang)
- Internal link count and which sections lost links
- Image alt attributes
Do not make any edits. Just produce a diff report.Prompt 4: Diagnosi INP e piano di correzione
Analyze [URL] for Interaction to Next Paint (INP) issues on mobile.
1. Check if CrUX field data is available and report the current mobile INP value.
2. If CrUX data is unavailable, run a Lighthouse mobile audit and report the Total Blocking Time (TBT) as a proxy indicator.
3. Identify the top 3 JavaScript tasks blocking the main thread during page load and after user interaction.
4. For each problem, give me: the specific file or script causing it, the impact on INP, and the one-line fix.
Format the output as a table: Problem | Source | Impact | Fix.Prompt 5: Audit crawler AI e dati strutturati
Check [URL] for AI search and AI crawler readiness:
1. Crawl robots.txt at the domain root. List all rules that mention these user-agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Amazonbot, Bytespider. If any are blocked, flag it.
2. Extract all JSON-LD blocks from the page. Validate each against Schema.org types. Report which types are present and whether they are complete (all required properties filled).
3. Check if /llms.txt exists at the domain root. If it does, report its content summary. If it does not, note that as a missing AI discovery asset.
4. Check if the page has a clear, self-contained answer (2-4 sentences) to its main topic within the first 200 words of body text.
5. Score the page on AI readiness: 0-100. Deduct points for: missing structured data (-30), blocked AI crawlers (-20 per crawler), no llms.txt (-15), no clear answer block (-20), headings not descriptive (-15).FAQ
D: Posso ancora usare un sito mobile separato (m.example.com)? Tecnicamente si, ma Google raccomanda il design responsive. URL mobile separati aggiungono complessita: devi mantenere contenuti identici, tag canonical e hreflang su due set di URL. Se qualcosa va fuori sincrono, Google indicizza la versione di cui ha fatto il crawl per ultima. Il design responsive elimina completamente questo rischio.
D: Cosa succede se il mio sito e solo desktop, nessuna versione mobile? Se Googlebot Smartphone non puo accedere e renderizzare i tuoi contenuti, quei contenuti non saranno indicizzati. Punto. Un sito solo desktop nel 2026 e di fatto invisibile a Google. Se ti trovi in questa situazione, passare a un tema responsive e la tua priorita assoluta.
D: Devo preoccuparmi delle dimensioni tablet? Googlebot esegue il crawl come smartphone, non come tablet. Concentrati sul viewport smartphone. Detto questo, gli utenti tablet sono utenti reali: assicurati che il tuo design responsive non si rompa a larghezze intermedie (768-1024px).
D: Come faccio a sapere se il mio sito ha gia completato la transizione mobile-first? Apri Google Search Console → Impostazioni → controlla la sezione "Informazioni" per "Crawler di indicizzazione: Googlebot per smartphone". Se lo dice, sei in indicizzazione mobile-first. Ormai quasi tutti i siti lo sono.
D: Google esegue ancora il crawl del mio sito con un user-agent desktop per qualche motivo? Si. Google occasionalmente esegue il crawl con un user-agent desktop per controlli specifici (verifica delle relazioni, rielaborazione di alcuni dati strutturati). Non allarmarti se vedi Googlebot desktop nei tuoi log. Quelle visite non significano che il tuo sito e in indicizzazione desktop-first.
Autore: Julian Mercer, Specialista di SEO Tecnico con 14 anni di esperienza presso Auspia. Julian scrive di crawlabilita, rendering, schema, architettura del sito e delle basi tecniche che rendono i contenuti discoverabili dai motori di ricerca e dai sistemi AI.
