Subscribe now

Technical SEO is a fundamental part of optimizing a site. It’s the part that takes the most expertise and the longest to do.

For anyone unfamiliar with it: technical SEO means working on a site’s foundations. And even if you’ve done a great job on architecture, mapped the semantics perfectly, built valuable content, and optimized everything else — skip the technical SEO and the results will keep you waiting.

I’ll admit I prefer working on architecture and content. But I’ve discovered that if I put my headphones on and play some good music, technical SEO isn’t half bad.

AI here, I promise you, makes the work more efficient. It doesn’t replace technical understanding — that part stays pretty human — but it helps gather data, analyze it, and put strategies to work.

Let’s go process by process. Here’s where AI genuinely helps, plus a few prompts you can use.

Crawling and indexing

Every technical audit starts the same way: find out what Google can actually reach, read, and index on your site. Search Console’s “Coverage” (or “Page indexing”) report is still the mandatory starting point of any SEO audit, together with a crawl from Screaming Frog or another technical crawler.

The problem shows up right after. A crawl of a medium-to-large site easily returns a few thousand rows of errors, warnings, anomalies.

This is where AI helps find patterns in a pile of data that’s sometimes enormous. Export the crawl as CSV, feed it to the model, and ask it to group the errors by common cause, not by error type.

The difference is substantial: 900 pages showing “404” can actually hide three separate causes — a plugin that changed the URL structure, a deleted category with no redirect, a pagination bug.

Beyond the analysis, ask your AI model to create an Excel or a Drive file with specific parameters. It’ll help you isolate the causes, group them, and work through the problems.

Example prompt for crawl analysis

Act as a senior technical SEO. I’m attaching the CSV export of a crawl of [site name], a [site type: ecommerce, editorial, corporate] with roughly [n] URLs, built on [CMS]. The available columns are: URL, status code, content type, title, meta description, canonical, indexability, crawl depth, number of inbound internal links, referring URL.

Don’t list the errors one by one, and don’t group them by error type. I want you to trace them back to common causes.

Analyze the file and give me:

1. Problem clusters grouped by probable cause, not by status code. For each cluster indicate: the cause you suspect, the number of URLs involved, three example URLs, and the recurring pattern that led you to that cause (URL structure, subfolder, parameters, depth).

2. A priority estimate for each cluster, based on the number of URLs involved and the number of internal links pointing to those pages.

3. The cases you can’t trace back to a common cause, kept separate in their own section. Don’t force the attribution: if a group of URLs has no clear pattern, tell me explicitly instead of inventing an explanation.

Then generate an Excel file with two sheets. Sheet 1 “Clusters”: one row per cluster, with columns Suspected cause, N. URLs, Priority, Examples, Recommended action, Owner (SEO or Dev). Sheet 2 “Detail”: all problem URLs with their cluster next to each, so I can filter and work in blocks.

At the end, flag which hypotheses need manual verification from me before I act.

Redirects and broken links

Redirect chains (A points to B, B points to C) are one of the most common technical problems on sites that have been online for several years, especially after migrations or CMS changes.

Every extra hop in the chain slightly dilutes the authority passed through, and slows down crawling.

Spotting the chains with an audit tool is the easy part.

The tedious work comes after: deciding, for every chain, what the correct final destination is, and making sure a redirect doesn’t itself point to a page that’s getting deleted in six months.

This is where AI helps build the redirect map. You give it the list of chains found by the crawler plus the site structure, and it proposes the optimal final destination for each one, flagging the ambiguous cases that need an editorial call. Those, rightly, stay yours.

I’ve found it useful to give the model the site’s architectural context: the taxonomies, the mapping of the new categories. Without those rules, on URLs that look alike the model ends up guessing at semantic relevance.

Example prompt for the redirect map

Act as a senior technical SEO. I need to rebuild the redirect map for [site name], a [site type] on [CMS], online since [year] and migrated from [old platform] in [period].

I’m giving you three things:

1. The export of redirect chains found by the crawler (columns: starting URL, intermediate hops with their status code, final URL, final status code, number of inbound internal links on the starting URL).

2. The current site structure: taxonomies, category tree, URL logic.

3. The old-category → new-category mapping decided during the migration.

Use points 2 and 3 as binding rules. Don’t infer the destination from string similarity between URLs: if two URLs look alike but the mapping says otherwise, the mapping wins.

For each chain, give me:

• The final destination you propose, with the redirect rewritten as a single hop from the starting URL to that destination.

• The rule you applied to get there (which mapping entry, which node in the tree).

• A confidence level: high if the destination comes directly from the mapping, medium if you deduced it from the taxonomy, low if you had to guess.

Everything with low confidence goes in a separate “To decide” section, with what you’re missing to resolve it and two or three alternative destinations for me to choose from. Don’t assign a forced destination just to complete the row.

Also flag, in a separate section:

• The chains whose final destination is itself a redirecting URL, a 404, or a page excluded from indexing.

• The starting URLs with many inbound internal links: there, a redirect isn’t enough — the links in the content need updating.

• Any loops.

Finally, generate an Excel file with two sheets. Sheet 1 “Redirects to implement”: starting URL, destination URL, redirect type (301), rule applied, confidence, notes for the developer. Sheet 2 “To decide”: the low-confidence chains with the proposed alternatives.

XML sitemaps

Sitemaps remain one of the main sources crawlers use to discover a site’s URLs.

The classic check is verifying that every URL in the sitemap returns a 200 status, not a 404 or a 301. On a site with hundreds of thousands of pages, doing it by hand is unthinkable.

An AI model connected to a script that checks status codes can process the entire sitemap and hand you back only the anomalies, already sorted by priority: 404 URLs first, redirects next, timeouts last.

The technical scraping work stays with a script, not the model. But asking the model to read that output and write the report in plain language, ready to pass to the developer, makes the whole process more efficient.

Prompt 1 – generate the checking script

Write me a Python script that reads the XML sitemap of [domain], including any nested sitemap indexes, and checks the status code of every URL.

Requirements: parallel requests with a configurable concurrency limit and a pause between batches, so as not to overload the server; timeout handling with a configurable number of retries; the ability to resume from where it stopped, because the file contains roughly [n] URLs.

Output: a CSV with columns URL, status code, redirect chain if present, final URL, response time, check timestamp. Include all URLs, not just the anomalies — I’ll filter afterward.

Add a short console summary at the end with the count per status code.

Prompt 2 – turn the output into a report

Act as a senior technical SEO. I’m attaching the CSV with the results of the status-code check on the sitemap of [site name], [n] URLs total. The columns are: URL, status code, redirect chain, final URL, response time.

Don’t give me the full list. I only want the anomalies, organized by intervention priority:

• Critical – URLs returning 404, 410, or 5xx. These are dead pages inside the sitemap: remove or restore them.

• To fix – URLs returning 301 or 302. The sitemap must contain the final URL, not the one that redirects elsewhere.

• To check – timeouts, response times far from the site median, chains with more than one hop.

For each group, cluster the URLs by common pattern (subfolder, content type, recurring parameters) and hypothesize the cause: a dismissed category, a structure change, a sitemap generated by a plugin that doesn’t update. If a group has no recognizable pattern, say so instead of inventing an explanation.

Then write me the report in plain prose, ready to send to the developer. Structure: what was checked and when, what’s broken (most urgent first), what needs doing for each point in operational terms, what instead needs a decision from me before acting. No unnecessary SEO jargon: whoever reads it knows code, not the terminology of our field.

Attach a CSV with only the URLs to fix, with the required action next to each and the correct final URL where you can already determine it.

Duplicate and thin content

Internal duplication (several pages on the same site with overlapping content) is easy to spot with classic audit tools. External duplication (someone copying your content, or worse, an AI tool that reworked it by scraping your article) is trickier.

AI plays on two opposite fronts here. On one hand, you can use it to speed up genuinely differentiated content, the kind that reduces overlap between your own pages (two articles answering the same question in different words are a cannibalization problem, not just a duplication one). On the other, a language model is excellent at reading two texts and telling you how much they overlap semantically, not just lexically — something a classic string-based duplicate content tool can’t do.

For noindexing low-value pages (empty categories, orphan tags, ecommerce filter pages), AI can help you define the rules in bulk: you give it the list of URLs with their parameters, and it returns the correct logic to place in the robots meta tag or the X-Robots-Tag HTTP header, explained line by line.

Careful not to confuse the tools: noindex goes in the meta tag, not in robots.txt, which Google no longer supports for this purpose since 2019 and which controls crawling, not indexing. In fact, if you block a page with robots.txt, Googlebot can’t even read the noindex in the meta tag, and the page risks staying indexed anyway.

Prompt 1 – semantic overlap and cannibalization

Act as an SEO content strategist. I’m attaching [n] pieces of content from [site name], [section name] section, each with: URL, title, H1, full text, assigned primary keyword, main entry queries from Search Console with clicks and impressions.

Analyze the semantic overlap, not the lexical one. Two articles saying the same thing in different words are overlapping even if a duplicate content tool considers them distinct.

For each pair with meaningful overlap, give me:

• The two URLs and the estimated overlap percentage, with an explanation of what overlaps: the search intent, the topics covered, or both.

• Whether the two pages compete on the same queries in Search Console — that is, whether it’s real cannibalization and not just thematic similarity.

• What makes each of the two unique, if anything does.

• The recommended action among: merge into a single piece (indicating which URL to keep and why), differentiate the two intents (indicating which angle to assign to each), or leave unchanged because the overlap is only apparent.

If you recommend merging, tell me which parts of the content being retired should be salvaged into the surviving page, so I don’t lose information.

Don’t force the analysis: if a pair seems to overlap but it needs my editorial judgment to decide, put it in a “To evaluate” section instead of recommending an action.

Prompt 2 – noindex rules for low-value pages

Act as a senior technical SEO. I’m attaching the list of URLs of [site name] with their parameters, template type, number of products or articles contained, and Search Console data for the last 12 months (clicks, impressions, average position).

Identify the pages that are candidates for exclusion from the index: empty or near-empty categories, tags with a single associated content, ecommerce filter and sorting pages, pagination beyond the first, internal search results.

Constraints to respect:

• Noindex must be implemented in the robots meta tag or the X-Robots-Tag HTTP header. Don’t propose noindex directives in robots.txt: Google no longer supports them since 2019.

• Don’t propose blocking in robots.txt the URLs you want to noindex. If Googlebot can’t access the page, it doesn’t read the meta tag and the page can stay indexed.

• Exclude from the candidates any URL that in the last 12 months brought organic clicks or ranks on relevant queries, even if the template would seem low-value. Flag these separately as exceptions.

Give me the rules grouped by pattern (not URL by URL), each with: the affected URL pattern, the number of pages involved, the reason for exclusion, the exact directive to implement, and where it goes (template, server header, CMS configuration).

Add a note on the consequences to monitor after implementation, and on any internal links pointing to those pages that need reviewing.

Mobile usability

With mobile-first indexing fully complete for years now, the mobile usability problems that remain are the subtle ones: buttons too close together, text overflowing the viewport, elements overlapping on small screens. Mobile analysis tools flag them technically, but turning “the tap target is too small” into an actual fix still needs a human eye and work on the CSS.

AI here mostly helps with prioritization: on a site with hundreds of templated pages, asking the model to group the tool’s findings by template component (not by individual page) tells you the problem isn’t 200 pages — it’s a single header component repeated.

Example prompt for prioritizing mobile findings

Act as a technical SEO working closely with the frontend development team. I’m attaching the export of mobile usability findings for [site name], [n] URLs analyzed, site built on [CMS/framework] with [n] main templates.

I’m also giving you the list of the site’s templates and shared components (header, footer, menu, product card, newsletter box, cookie banner, tables, gallery), indicating which templates use them.

Don’t give me the findings page by page. Group them by template component.

For each problem component, indicate:

• The component involved and on how many URLs the error repeats.

• The type of problem (tap target too small or too close, text exceeding the viewport, overlapping elements, insufficient contrast) and where in the component it occurs.

• How many different templates use that component: an error in a component present in 8 templates out of 10 matters more than an error on an isolated template.

• Whether the pages involved generate meaningful organic traffic, so I can distinguish the widespread-but-irrelevant problem from the narrow-but-on-important-pages one.

Order the components by real impact, not by raw number of findings. A single header component breaking 200 pages is one fix, and it goes before 15 different problems scattered across 20 pages.

For each component, write what needs fixing in concrete terms for whoever touches the CSS: which property is involved and what behavior needs to result. Don’t generate the final code, because you don’t know the site’s real CSS: indicate the type of intervention and leave the implementation to the developer.

Flag separately the findings you can’t trace to a shared component, which are therefore probably content problems or single-page exceptions.

Close with an estimate of how many total findings get closed by fixing the first three components on the list.

Page Speed

Page speed remains one of the few technical areas where optimization has a direct, measurable ranking impact. It’s also the area where AI helps less than you’d expect, because the problem is almost never understanding what’s wrong (the performance analysis tools already tell you that very clearly) — it’s implementing the fix in the code.

Where AI still lends a concrete hand: reading the performance report and translating “eliminate render-blocking resources” into a concrete work plan, with priorities (what solves the problem right away, what’s a marginal improvement instead), and generating the code snippet directly for lazy loading, preloading critical fonts, or minifying a specific CSS file. It hands the developer a task already written, along with a file you can ask them to create and use for subsequent monitoring.

Example prompt for the performance work plan

Act as a technical SEO who has to hand a work plan to the developer. I’m attaching the performance analysis report for [URL], template [page type], site on [CMS/framework] with [stack: CDN, hosting, caching plugin in use].

The report already tells me what’s wrong. What I need from you is the translation into a work plan with real priorities.

For each finding in the report, indicate:

• What it means in practice on this specific site, not in general.

• The estimated gain in milliseconds or in score, and which metric it affects (LCP, CLS, INP).

• The implementation effort: a configuration change, a template edit, or a refactor.

• Who does it: solvable from the CMS panel, or does it need the developer.

Order everything by gain-to-effort ratio, not by the severity the report declares.

Tell me explicitly which findings are marginal improvements not worth tackling now, and why. I don’t want a plan with twenty items all urgent: I want to know which three interventions actually move the needle and which I can ignore for six months.

For the interventions in the top tier of the list, generate the ready-to-use code snippet: lazy loading attributes for below-the-fold images, preloading critical fonts with the correct format and crossorigin, defer or async for non-essential scripts, resource hints. For each snippet, indicate which file it goes in and where. If an intervention requires knowing the site’s real code, which you don’t have, say so and just describe the intervention.

Close by generating two files:

1. A handoff document for the developer: what to do, in what order, with the snippets and the expected result for each point.

2. A monitoring file in spreadsheet format with columns: measurement date, URL, LCP, CLS, INP, overall score, intervention implemented on that date, notes. Prefill the first row with the report’s current values, so I have the baseline to measure improvements from.

Structured data

Schema markup is a powerful tool for earning rich snippets, and with the arrival of AI Overviews and generative answers, clear, well-implemented structured data also helps conversational engines cite the source correctly.

This is probably the technical area where AI contributes the most directly and immediately: generating correct JSON-LD markup is a perfect task for a language model, because it’s a problem of structured syntax more than of creativity. Describe the page (an article, a recipe, a product, an FAQ) and the model writes the complete schema, which you then validate with Google’s Rich Results Test before publishing. The one mistake to avoid is publishing schema without validating it: a model can invent properties that don’t exist in the schema.org standard, so human review at this step stays necessary.

Example prompt for generating Schema markup

Act as a technical SEO specialized in structured data. I need to generate the JSON-LD markup for [URL or page description], which is [content type: news article, product review, recipe, service page, FAQ].

I’m giving you the page content and the available data: [title, author, publication and last-modified date, images with dimensions, price and availability if a product, times and ingredients if a recipe, questions and answers if an FAQ, publishing organization data].

Generate the markup respecting these constraints:

• Use exclusively types and properties that actually exist in the schema.org standard. Don’t invent plausible-sounding properties: if a piece of information has no corresponding property in the standard, tell me instead of creating one.

• Include all the required properties Google mandates for this type of rich result, and flag separately the recommended-but-optional ones, so I can decide whether it’s worth sourcing the missing data.

• Don’t put information in the markup that doesn’t appear in the page’s visible content.

• If multiple types apply, use nesting or the graph with @id instead of generating separate, disconnected blocks.

Give me back:

1. The complete JSON-LD, ready to insert, with an indication of where it goes in the document.

2. A line-by-line legend: what each property does and which page data you derived it from.

3. The list of properties I left empty or that are missing, with the impact of each on rich-result eligibility.

4. A bulleted list of things to check in the Rich Results Test and the schema.org validator before publishing, with the most likely errors for this type of markup.

Finally, tell me if any property you used is deprecated, or if Google has recently changed the requirements for this type of rich result: in that case, warn me that the detail needs verifying against the current official documentation.

Hreflang

Hreflang is a delicate topic, because a single unbalanced tag (page A points to B, but B doesn’t point back to A) is enough to void the whole implementation.

For sites with few languages, dedicated tag generators already solve the problem in a few clicks. For sites with dozens of language-country combinations, feeding the model the full list of URLs with target language and country and asking it to generate the complete hreflang matrix (reciprocity check included) is faster than building it by hand, row by row, and more reliable than a spreadsheet full of VLOOKUP formulas.

Prompt 1 – reciprocity audit on an existing implementation

Act as a technical SEO specialized in multilingual sites. I’m attaching the export of hreflang tags found by the crawler on [site name], covering [n] language-country combinations. The columns are: origin URL, declared hreflang value, destination URL, implementation method (HTML tag, HTTP header, sitemap), destination URL status code, origin URL canonical.

Verify the implementation and give me the errors grouped by type, not URL by URL:

• Missing reciprocity – page A declares B, but B doesn’t declare A. Give me the pair, the missing direction, and how many pairs repeat the same pattern, since it’s usually a template getting it wrong, not the individual pages.

• Missing self-reference – every URL must also declare itself.

• Canonical conflicts – pages that declare hreflang toward one version while the canonical points elsewhere. This is the error that silently voids everything else.

• Invalid codes – languages and countries not respecting ISO 639-1 and ISO 3166-1 Alpha 2, inversions between the two, nonexistent values. Also verify that x-default is present and assigned to a single destination.

• Invalid destinations – hreflang pointing to redirecting URLs, 404s, or pages excluded from indexing.

For each group, indicate the number of URLs involved, the template or section the problem comes from, and whether the error compromises the entire implementation or only the affected pairs.

Order by severity: first what invalidates the cluster’s functioning, then what weakens it.

Prompt 2 – matrix generation and developer instructions

Act as a technical SEO specialized in multilingual sites. I need to generate the complete hreflang matrix for [site name].

I’m giving you the list of equivalent URLs, grouped by page, each with: URL, language, target country, and the indication of which version to use as x-default.

Rules to respect:

• Every URL in the group must declare all the group’s versions, including itself.

• Use the codes in the correct language-country format (ISO 639-1 for the language, ISO 3166-1 Alpha 2 for the country), with the language always first.

• A single x-default per group.

• References must point to canonical, indexable URLs, never to redirecting versions.

• If matches are missing in the group (a page exists in Italian but not in German), don’t force the pairing: flag the gap instead of inventing a plausible destination.

Give me back:

1. The complete matrix in table format, one row per origin-destination pair, so I can verify it and pass it to the developer.

2. The markup generated in all three possible forms (HTML tag in the head, HTTP header, block for XML sitemap), with an indication of which is best in this case and why, considering the site has [n] combinations.

3. The operational instructions for the developer: where it gets implemented, how it should be generated dynamically from the page data rather than written by hand, and what automatic check to insert at build or deploy time to catch missing reciprocities before they reach production.

4. The list of incomplete groups that require an editorial decision from me.

What’s new

Some newer technical SEO processes, born alongside AI itself, deserve a separate mention, because until recently they didn't exist.

Log file analysis with AI

Server logs tell you exactly what Google's crawler visited, when, and how often: it's the most honest data there is on your site's real crawl budget, far more reliable than an external tool's estimates. A mid-sized site's log file easily contains millions of rows. A model connected to a parsing script can isolate, in minutes, the sections of the site Googlebot rarely visits, or that receive unusual status codes, handing you the list of real crawling priorities, not guessed ones. The operative point is exactly this: you don't feed the raw log of millions of rows to the model (it often weighs hundreds of megabytes, it doesn't fit). The script works on it first, and the AI gets the already-aggregated output to read and interpret.

Prompt 1 – the parsing and aggregation script

Write me a Python script that analyzes the server access logs of [site name], format [combined/common/JSON], for a period of [n] days, roughly [n] million rows. The script must run in streaming, row by row, without loading the file into memory.

Filter the requests from search engine bots, distinguishing Googlebot desktop, Googlebot smartphone, Googlebot Image, and the other crawlers declared in the user agent. Include a fake-bot verification via reverse DNS lookup on the IPs, with the option to disable it to speed up execution.

Aggregate the data and produce these CSVs:

• Per section: first- and second-level subfolder, number of hits, unique URLs visited, status code distribution, bytes transferred, date of first and last visit.

• Per URL: only the URLs with anomalies (status other than 200, response times above the median, requests repeated many times in the same day), with crawl frequency and prevailing status.

• Time distribution: hits per day and per user agent, to see the trend over the period.

• Crawl frequency: every URL with its visit count and the days since the last one, to identify those never or rarely visited.

• Resources: how much of the crawl is absorbed by static files, images, JS, CSS, tracking parameters.

No personal data in the outputs: exclude real users’ IPs and limit processing to bot traffic.

Prompt 2 – interpreting the aggregated output

Act as a senior technical SEO. I’m attaching the aggregated CSVs of the logs of [site name] for [n] days: data per section, anomalous URLs, time distribution, crawl frequency, consumption by resource type. I’m also attaching the sitemap export and the list of the site’s strategic sections, with organic traffic data per section.

Analyze how Googlebot is actually spending the crawl budget and give me:

• Under-crawled sections: strategic areas, or ones that generate traffic, that Googlebot visits rarely or not at all. Cross-reference with the sitemap to identify URLs present in the sitemap and never visited in the period.

• Wasted crawl budget: sections, parameters, resources, or URL patterns absorbing many requests without corresponding value, with the estimated percentage of budget you free up by intervening.

• Status anomalies: patterns of 404, 301, and 5xx served to the crawler, grouped by probable cause and not by individual URL.

• Trend over the period: significant variations in crawl frequency, with a hypothesis of what may have caused them.

• Sitemap vs. reality gap: what you declare you want indexed versus what Googlebot actually visits.

For each point, indicate the recommended action and who does it (SEO or dev). Distinguish observed data from your hypotheses: when you propose a cause, state that it’s a hypothesis to verify.

Bear in mind the analyzed period is [n] days: flag which conclusions would need a longer window to be reliable.

Debugging JavaScript rendering

Sites built on heavy JS frameworks hide a classic problem: what the user sees in the browser isn't always what Googlebot can render and index. Comparing raw HTML against the rendered DOM, which used to require manual inspection page by page, is now automated by asking a model to compare the two outputs and flag only the relevant content discrepancies (titles, body text, links), ignoring the cosmetic differences that don't count for indexing.

Prompt 1 – the extraction and comparison script

Write me a Python script that, for a list of URLs of [site name], built on [framework: React, Vue, Angular, Next.js], extracts and compares two versions of each page:

1. The raw HTML returned by the server, with no JavaScript execution.

2. The DOM rendered after full script execution, using a headless browser with Googlebot smartphone user agent and mobile viewport.

For each version, extract: title, meta description, meta robots, canonical, headings from H1 to H3, the main content text with word count, all internal links with their anchor text, image alt attributes, JSON-LD blocks, and hreflang tags.

Produce a CSV with one row per URL and, for each element, the value in the raw version, the value in the rendered version, and a flag indicating whether they match. Add the time the rendering took and any JavaScript errors caught in the console.

Provide a second output with the full text of both versions for the URLs that show differences, so I can pass it to a later analysis.

Handle rate limiting with a configurable pause between requests and the ability to resume execution from where it stopped.

Prompt 2 – interpreting the discrepancies

Act as a technical SEO specialized in JavaScript sites. I’m attaching the comparison between raw HTML and rendered DOM for [n] URLs of [site name]. For each URL you’ll find the values of title, meta tags, headings, content text, internal links, JSON-LD, and hreflang in both versions.

Analyze the discrepancies and classify them by impact on indexing. Ignore the cosmetic differences: CSS classes, style attributes, dynamically generated ids, attribute order, spacing, wrappers added by the framework. I don’t want a list of every diff, I want to know what changes for Googlebot.

Give me back:

• Critical – elements present only after rendering: title or meta robots or canonical injected via JS, main content absent from the raw HTML, internal links generated client-side only, JSON-LD not present in the source. For each, indicate what risks not being indexed.

• To check – partial differences: truncated text, headings differing between the two versions, word count significantly lower in the raw version, links present in both but with different anchor text.

• Irrelevant – everything that changes without consequences for indexing, reported only as an aggregate count, with no detail.

Group the problems by template or component type, not by individual URL: if the same element is missing on 50 pages of the same template, it’s one problem.

For each critical problem, indicate which rendering approach would solve the case (server-side rendering, static pre-rendering, partial hydration, moving the element into the source) and what it entails as an intervention, without writing the code: you don’t know the application’s real architecture.

Finally, flag whether there are JavaScript console errors that could prevent rendering from completing on Google’s side, and which URLs are slowest to render, because a too-heavy render can be interrupted before it completes.

Monitoring citability in generative engines

This isn’t classic technical SEO yet, but it’s becoming a parallel process that earns a spot on this list: periodically checking whether AI Overviews, Perplexity, or ChatGPT cite your pages correctly, with the right URL and attribution, and not an expired domain or a stale cached version. It’s a check you can automate with recurring queries and a model that compares the citation against the page’s actual state.

To help you monitor mentions across generative models, I recommend using my Brand Observability Tracker. Try it out, and don’t forget to send me your feedback.

Brand Observability Tracker by Debora Tesauro

The bottom line

Technical SEO doesn't change its nature with AI. It changes its speed.

The fundamentals (a site that crawls, indexes, loads fast, and makes sense) are the same as ten years ago.

What's changed is how long it takes to get from problem to solution.

And in a job made mostly of log files, crawls with thousands of rows, and sitemaps to check one by one, saved time is, in the end, the only thing that really counts.

Who isn’t using AI for brainstorming these days?

It’s convenient, it’s fast, it condenses into thirty seconds what used to take an afternoon of research. And it’s not just a habit of the few: Harvard Business Review’s analysis of how people actually use generative AI puts idea generation right at the top. In professional settings, instead of asking a colleague or combing through the SERPs, we consult the oracle.

The problem is that the oracle is giving the same answers to your competitor. And to your competitor’s competitor. A conceptually similar prompt, the same twenty ideas served back, the same carbon-copy editorial calendar.

As for the content we see around as a result — let’s describe it politely. A former boss of mine, stern but fair, would have labeled it with a word that ends in “-rap”.

There’s a technical reason behind this, a rather complex one, but worth understanding. A language model estimates, word by word, the most probable sequence. When you ask it for ideas, it’s handing you the statistical average of everything it has read. Its outputs chase consensus, not intuition — let alone originality.

The result, as I said, is already circulating: flattened content. It fills our feeds, our inboxes and, I swear, even our WhatsApp chats, because people now lean on AI to write even simple professional messages. Not wrong, mind you. Correct, tidy, reasonable. But completely identical, serial, impersonal, and at times a little ridiculous, because they lack the nuances — and any even mildly demanding reader can feel it and walks away.

So how is an SEO supposed to find content worth writing today — and, more importantly, content that human beings actually want to read?

My answer: go back to the old methods. The ones we used before ChatGPT. But without nostalgia and without masochism, because AI absolutely has a role in this work. It just needs to be put in the right place.

AI should be your sieve, not your source

The old content research method worked for a precise reason: it started from raw human data. What people type into Google, what they write in reviews, what they ask in forums. It was tedious, but it was true.

Today’s lazy method starts with AI and ends with AI. And it’s exactly in that perverse loop that content flattens out.

The method that works is a hybrid one, but the place where you gather the data — and the feelings — remains entirely human-driven: ideas live where people talk and write spontaneously. AI does the sieving: you feed it the raw material, hundreds of reviews or thousands of comments, and ask it to find patterns, clusters, recurring questions. The boring work that used to cost us entire days. The editorial angle stays yours: what to say, and from which perspective, is an editorial decision. Delegate that final part too, and you’re back to square one: mediocre, flattened content.

Google Autocomplete: the real questions

Remember typing your keyword into the search bar and watching what Google suggested? Those suggestions are not the output of a model: they’re real searches made by real people, ranked by frequency and freshness. That’s why Autocomplete, along with the People Also Ask box, remains one of the clearest sources we have. No vector-based semantic proximity — just real, up-to-date searches.

The limit of this method has always been the collection: keyword plus a, keyword plus b, keyword plus c, all the way to z, and then again with “how”, “why”, “how much does it cost”. Hours of mechanical work.

Well, that’s the work to hand over to AI. Gather the suggestions in bulk — with a tool like AlsoAsked or AnswerThePublic, or with systematic copy-pasting — and then pass everything to the model with a precise request: group these searches by intent, flag the questions that recur in multiple variants, tell me which clusters don’t find a satisfying answer in the top results.

The AI hasn’t invented anything. It has sieved real data. And in ten minutes you have a map of intents that would have taken you half a day.

One more suggestion: comparing Google’s suggestions with the follow-up questions that ChatGPT or Perplexity propose on the same topic is an exercise I recommend. Where the two worlds diverge, there’s almost always an emerging question that existing content isn’t covering yet.

Amazon, where market research lives

Another old-but-gold method, one that got shelved far too quickly in recent years: going on Amazon, using its autocomplete there too, and reading the reviews in your market.

You used to read fifty and stop, inevitably. Today you gather five hundred and hand them to the model, asking for two things: the needs readers declare unmet and — this matters — the most representative verbatim quotes.

That “verbatim” is not a detail. You need people’s real vocabulary, not the model’s paraphrase. The exact words people use to describe a problem are gold for headlines, for long-tail keywords and, incidentally, for generative systems too: as I explained when writing about semantic search, these systems work on the proximity of meaning between question and content. Writing with the words of the people who search has never been as effective as it is today — as a strategy for visibility, and for differentiation.

And yes, we do have to talk about differentiation strategy now. When everyone produces content by generating some output, your job becomes shining in the middle of the slop.

Remember to explore the “Questions & Answers” section of products too, and the reviews of competing products. All raw material, all human (well, there’d be rivers of words to write there as well about AI-generated reviews... synthetic text strips a review of its authority, and it’s a problem marketplaces will have to face soon).

YouTube: do you still read the comments?

The classic YouTube method was spotting outlier videos: the ones that far exceed their channel’s average views. If a channel averaging 10,000 views per video lands one at half a million, that topic has hit a nerve. This method remains a very solid signal.

But the part that’s worth more today is another one: the comments. Under every successful video there are hundreds of people asking questions, requesting deep dives, correcting, telling their own story. A source no one has ever used effectively, for a reasonable motive: reading three thousand comments is inhuman.

Exactly: inhuman. Perfect for AI.

Export the comments from the ten most-viewed videos on your topic — there are tools and scripts for that — and ask the usual questions: which requests keep coming back? Which ones does the video not answer? What words do people use to describe the problem?

The questions left unanswered under a video with half a million views are, in all likelihood, searches that no content is broadly satisfying yet.

Reddit and online communities

This method has aged beautifully, for a precise reason: in communities, people articulate problems before they know what the solution is called. And that naive, extremely concrete, often ungrammatical phrasing is exactly what neither keyword tools nor models can give you back.

It’s no coincidence that Google has filled its SERPs with Reddit results: it applied the principle that people look for human answers.

The update to the method is straightforward. Identify the three or four subreddits, groups or forums where your audience lives, gather the most-commented threads of the past few months, and use AI to extract the hot topics, the recurring misconceptions (excellent for debunking content) and the questions that the top-voted answers handle poorly.

Search Console: your own dataset

While everyone asks the same AI for ideas, you have a proprietary source of ideas that no competitor can query. Your data.

The queries your site shows up for without you ever deciding it. The ones with plenty of impressions and a CTR that looks like a rounding error. The “almost right” ones, where you intercept a question with a piece of content that actually answers a different one.

The old method was exporting into a spreadsheet. Today you export the last twelve months of queries and ask the model to find the patterns: clusters of questions you’ve never dedicated a piece to, emerging angles, seasonality you hadn’t noticed. And it’s the only case in which AI brainstorming is, by definition, not flattened — because the dataset is yours alone.

The same goes, if you have them, for internal site searches, customer support emails, sales call transcripts. Every company is sitting on an archive of human questions, and AI models help read through that mass of data and hand it back, in the end, to the human being who has to decide what to do with it.

Using AI in reverse

Take your content outline and break it into questions. Ask the AI model to answer those questions, and read the answers. Good: that is the average. That is what anyone, with zero effort, obtains in a few seconds thanks to the reasoning of a synthetic neural network. Which makes it the exact list of things your article cannot limit itself to repeating.

Your content begins where that answer ends: the first-hand data, the test you ran yourself, the real case you followed, the opinion you can argue for, the mistake you saw someone make in the field. Everything the model cannot know, because it hasn’t lived it. Because a trained AI model has no experience and no emotions to share — the very things that keep a reader glued to your content, because they recognize themselves in what they’re reading.

These systems don’t look for the most optimized content: they look for the most reliable, most useful source to include in an answer. Another page repeating what the model can already say on its own serves no one — least of all the model. New information, on the other hand, is precisely what makes content citable. Anti-flattening isn’t just an editorial choice: it’s becoming a visibility factor.

AI at the ideation stage isn't the problem. The problem is where you make it start from. If it starts from AI models and stops there, you'll write content that will probably not even get indexed by Google. If it starts from the raw human sources we've seen — Autocomplete, Amazon, YouTube, the communities and your proprietary data — it gives you back the boring hours and leaves you time for the one thing it cannot do in your place: choosing a point of view.

È comoda, è veloce, sintetizza in trenta secondi quello che prima richiedeva un pomeriggio di ricerche. E non è nemmeno un vizio di pochi: l’analisi di Harvard Business Review su come le persone usano davvero l’AI generativa mette la creazione di idee ai primissimi posti. In ambito professionale, invece di chiedere a un collega, spulciare le SERP, interroghiamo l’oracolo.

Il problema è che l’oracolo sta dando le stesse risposte anche al tuo competitor. E al competitor del tuo competitor. Prompt concettualmente simile, stesse venti idee riproposto, stesso calendario editoriale fotocopiato.

E i contenuti che vediamo in giro, li possiamo chiamare in maniera molto gentile. Il mio datore di lavoro di qualche anno fa, severo ma giusto, li avrebbe etichettati con una parola che finisce per “erda”.

C’è una ragione tecnica dietro molto complessa ma che vale la pena capirla. Un modello linguistico, stima parola dopo parola la sequenza più probabile. Quando gli chiedi delle idee, ti sta restituendo la media statistica di quello che ha letto. Gli output cercano il consenso, non l’intuizione, men che meno l’originalità.

Il risultato, come dicevo, lo vediamo già circolare: contenuti appiattiti. Riempie i nostri feed, le nostre caselle email, e vi giuro, anche le chat WhatsApp, perché le persone si affidano alle AI anche per scrivere semplici messaggi professionali. Non sbagliati, sia chiaro. Corretti, ordinati, ragionevoli. Ma completamente identici, seriali, impersonali, a volte anche un po’ ridicoli, perché mancano quelle sfumature che respingono un lettore appena un poco esigente.

E allora, come deve fare un SEO oggi per trovare contenuti che valga la pena scrivere, ma soprattutto che essere umani abbiano voglia di leggere?

La mia risposta è: tornare ai vecchi metodi. Quelli che usavamo prima di ChatGPT. Ma senza nostalgia e senza masochismo, perché l’AI in questo lavoro serve eccome. Serve solo metterla al posto giusto.

L’AI deve essere il tuo setaccio, non la tua miniera

Il vecchio metodo di content research funzionava per una ragione precisa: partiva da dati umani grezzi. Cosa digitano le persone su Google, cosa scrivono nelle recensioni, cosa chiedono nei forum. Era faticoso, ma era vero.

Il metodo pigro di oggi parte dall’AI e finisce con l’AI. Ed è proprio in questo loop perverso che i contenuti si appiattiscono.

Il metodo che funziona è ibrido, ma il luogo dove recuperi i dati, i sentimenti resta totalmente human-driven: le idee si trovano dove le persone parlano e scrivono spontaneamente. L’AI fa il setaccio: le dai in pasto il materiale grezzo, centinaia di recensioni o migliaia di commenti, e le chiedi di trovare pattern, cluster, domande ricorrenti. Il lavoro noioso che prima ci costava intere giornate. L’angolo editoriale rimane il tuo, la scelta di cosa dire e da quale prospettiva è una decisione editoriale. Se la deleghi anche nella parte finale, torni al punto di partenza: il contenuto mediocremente appiattito.

Google Autocomplete: le domande reali

Ricordate quando digitate la vostra keyword nella barra di ricerca e osservavate cosa suggeriva Google? Quei suggerimenti non sono output di un modello: sono ricerche reali fatte da persone reali, ordinate per frequenza e freschezza. È il motivo per cui Autocomplete, insieme al box People Also Ask, resta una delle fonti più chiare che abbiamo. Nessuna vicinanza semantica vettoriale, ma ricerche vere e aggiornate.

Il limite di questo metodo è sempre stato la raccolta: keyword più a, keyword più b, keyword più c, fino alla z, e poi da capo con “come”, “perché”, “quanto costa”. Ore di lavoro meccanico.

Ecco, quello è il lavoro da dare all’AI. Raccogli i suggerimenti in blocco con un tool come AlsoAsked o AnswerThePublic, o con un copia-incolla sistematico e poi passa tutto al modello con una richiesta precisa: raggruppa queste ricerche per intento, segnala le domande che ricorrono in più varianti, dimmi quali cluster non trovano una risposta soddisfacente nei primi risultati.

L’AI non ha inventato niente. Ha setacciato dati veri. E tu in dieci minuti hai una mappa di intenti che prima ti avrebbe richiesto mezza giornata.

Aggiungo un suggerimento: confrontare i suggest di Google con le domande di follow-up che propongono ChatGPT o Perplexity sullo stesso tema è un esercizio che consiglio. Dove i due mondi divergono, c’è quasi sempre una domanda emergente che i contenuti esistenti non stanno ancora coprendo.

Amazon, dove fare le ricerche di mercato

Un altro metodo old but gold, che è stato archiviato con troppa fretta negli ultimi anni, è quello di andare su Amazon fare anche li autocomplete e leggersi le recensioni del proprio mercato.

Prima ne leggevi cinquanta e ti fermavi, per forza. Oggi ne raccogli cinquecento e le dai al modello, chiedendo due cose: i bisogni che i lettori dichiarano insoddisfatti e importante, le citazioni testuali più rappresentative.

Quel “testuali” non è un dettaglio. Ti serve il lessico reale delle persone, non la parafrasi del modello. Le parole esatte con cui la gente descrive un problema sono oro per i titoli, per le long tail e, per inciso, anche per i sistemi generativi: come ho raccontato parlando di ricerca semantica, questi sistemi lavorano sulla vicinanza di significato tra domanda e contenuto. Scrivere con le parole di chi cerca non è mai stato così efficace come oggi, come strategia di visibilità e di distinzione.

Eh si, perché dobbiamo parlare di strategia di distinzione ormai. Quando tutti producono contenuti perché li crei con qualche output, il tuo compito diventa brillare in mezzo allo slop.

Ricordati di esplorare anche la sezione “Domande e risposte” dei prodotti, le recensioni dei prodotti concorrenti. Tutto materiale grezzo, tutto umano (beh, anche lì ci sarebbe da scrivere fiumi di parole sulle recensioni AI generated…un testo sintetico toglie autorevolezza a una recensione, è un problema che presto i marketplace dovranno affrontare).

YouTube: li leggete ancora i commenti?

Il metodo classico su YouTube era individuare i video outlier: quelli che superano di molto la media di visualizzazioni del loro canale. Se un canale con una media di 10.000 visualizzazioni a video ne piazza uno da mezzo milione, quell’argomento ha toccato un argomento di estremo interessa. Questo metodo resta un segnale validissimo.

Ma la parte che oggi vale di più è un’altra: i commenti. Sotto ogni video di successo ci sono centinaia di persone che fanno domande, chiedono approfondimenti, correggono, raccontano il loro caso. Una fonte che nessuno ha mai utilizzato in modo efficace, per un motivo ragionevole: leggere tremila commenti è disumano.

Appunto: disumano. Perfetto per l’AI.

Esporta i commenti dei dieci video più visti sul tuo tema, esistono tool e script per farlo, e fai le solite domande: quali richieste ricorrono? A quali il video non risponde? Con quali parole le persone descrivono il problema?

Le domande rimaste senza risposta sotto un video da mezzo milione di visualizzazioni sono, con ottima probabilità, ricerche che nessun contenuto sta ancora soddisfacendo ampiamente.

Reddit e le community

Questo metodo è invecchiato benissimo, per una ragione precisa: nelle community le persone formulano i problemi prima di sapere come si chiama la soluzione. E quella formulazione ingenua, concretissima, spesso sgrammaticata, è esattamente ciò che né i keyword tool né i modelli sanno restituirti.

Non è un caso che Google abbia riempito le SERP di risultati Reddit: ha applicato il principio che le persone cercano risposte umane.

L’aggiornamento del metodo è lineare. Individua i tre o quattro subreddit, gruppi o forum dove vive il tuo pubblico, raccogli i thread più commentati degli ultimi mesi e usa l’AI per estrarre i temi caldi, le convinzioni sbagliate ricorrenti (ottime per i contenuti di smontaggio) e le domande a cui le risposte più votate rispondono male.

Search Console: il tuo dataset

Mentre tutti chiedono idee alla stessa AI, tu hai una fonte di idee proprietaria, che nessun concorrente può interrogare. I tuoi dati.

Le query per cui il tuo sito compare senza che tu l’abbia mai deciso. Quelle con tante impression e un CTR da prefisso telefonico. Quelle “quasi giuste”, dove intercetti una domanda con un contenuto che in realtà risponde a un’altra.

Il metodo vecchio era esportare in un foglio di calcolo. Oggi esporti le query degli ultimi dodici mesi e chiedi al modello di trovare i pattern: cluster di domande a cui non hai mai dedicato un contenuto, angoli emergenti, stagionalità che non avevi notato. Ed è l’unico caso in cui il brainstorming con l’AI è per definizione non appiattito, perché il dataset è solo tuo.

Stesso discorso, se le hai, per le ricerche interne al sito, le email al supporto clienti, le trascrizioni delle call commerciali. Ogni azienda è seduta su un archivio di domande umane e i modelli AI aiutano a leggere questa mole di dati e le restituiscono infine all’essere umano che deve prendere le decisioni su come utilizzarle.

Usare l’AI al contrario

Prendi la scaletta del tuo contenuto e dividilo in domande. Chiedi al modello AI di rispondere alle domande e leggi le risposte. Bene: quella è la media. Quello è ciò che chiunque, con zero sforzo, ottiene in pochi secondi, grazie al ragionamento di una rete neurale sintetica. Ed è quindi l’elenco esatto delle cose che il tuo articolo non può limitarsi a ripetere.

Il tuo contenuto comincia dove finisce quella risposta: il dato di prima mano, il test che hai fatto tu, il caso reale che hai seguito, l’opinione che sai argomentare, l’errore che hai visto commettere sul campo. Tutto ciò che il modello non può sapere, perché non l’ha vissuto. Perché il modello AI è addestrato non ha esperienza e non ha emozioni da condividere, quelle che fanno rimanere il lettore incollato al tuo contenuto perché si sta identificando in quello che legge.

Questi sistemi non cercano il contenuto più ottimizzato: cercano la fonte più affidabile e più utile da includere in una risposta. Un’altra pagina che ripete ciò che il modello sa già dire da solo non serve a nessuno, tantomeno al modello. L’informazione nuova, invece, è precisamente ciò che rende un contenuto citabile. L’anti-appiattimento non è solo una scelta editoriale: sta diventando un fattore di visibilità.

L’AI in fase di ideazione non è il problema. Il problema è da dove la fai partire. Se parte dai modelli AI e si ferma lì, scriverai un contenuto che probabilmente non verrà nemmeno indicizzato da Google. Se parte da dati umani grezzi che abbiamo visto, Autocomplete, Amazon, YouTube, le community e i tuoi dati proprietari, ti restituisce le ore noiose e ti lascia il tempo per l’unica cosa che non può fare al posto tuo: scegliere un punto di vista.

C’è una domanda che chi fa SEO si pone da qualche mese: sto ancora ottimizzando per qualcosa che ha senso?

La risposta è assolutamente sì, ma il “qualcosa” è cambiato profondamente.

Quello che chiamiamo “ricerca” , ovvero l’atto di digitare una query e aspettarsi una risposta, ha attraversato in pochissimo tempo una trasformazione radicale. Un’affascinante rivoluzione che si è sviluppata attraverso decenni di salti evolutivi, ognuno dei quali ha aggiunto un layer di intelligenza sopra al precedente.

In questo articolo ripercorro tutta la storia, dal keyword matching agli agenti AI autonomi, spiegando che cosa è cambiato a ogni passaggio e, soprattutto, che cosa significa concretamente per chi oggi produce contenuti e fa SEO.

La domanda: dove compare questa parola?

I primi sistemi di ricerca non si chiedevano che cosa volesse sapere l’utente,si chiedevano solo dove una determinata parola compariva.

Il meccanismo alla base era l’indice: una mappa che associava ogni parola ai documenti in cui appariva. Cerchi “salotto moderno”? Il sistema trova tutti i documenti che contengono quelle due parole e li restituisce, ordinati per frequenza e rilevanza del termine.

Era potente. Era veloce. Ed è ancora alla base di molti sistemi che usiamo oggi, inclusa una parte di Google.

Il sistema trattava le parole come simboli, non come significati. Chi cercava “crociera estate Mediterraneo” trovava le pagine che ripetevano più volte quelle esatte parole, non necessariamente le più utili al suo intento. Chi scriveva “vacanza in nave luglio” era invisibile al motore, anche se stava cercando esattamente la stessa cosa. Era l’utente a doversi adattare alla macchina, non il contrario.

Il primo salto: le parole diventano significati

La ricerca semantica ha cambiato la prospettiva di base: invece di cercare parole, si comincia a cercare significati.

Il meccanismo sono gli embedding vettoriali: ogni parola, frase o documento viene rappresentato come un punto in uno spazio ad alta dimensionalità. Parole con significati simili finiscono vicine nello spazio, anche se non si assomigliano graficamente.

“Caffè” ed “espresso” sono punti molto vicini. “Caffè” e “automobile” sono lontanissimi.

Questi vettori non vengono programmati a mano: emergono da reti neurali addestrate su enormi quantità di testo. La macchina impara le relazioni tra concetti leggendo miliardi di frasi in contesto.

Il risultato pratico: per la prima volta, un motore di ricerca riesce ad approssimare la comprensione dell’intento. Anche se usi parole diverse da quelle che l’autore ha usato, il sistema capisce a che cosa ti stai riferendo.

La ricerca semantica non ha sostituito quella a keyword: le ha affiancate. I sistemi ibridi, che combinano la precisione del matching testuale con la capacità di recupero semantico, sono diventati lo standard.

Il secondo salto: arrivano i modelli linguistici

Poi è arrivata la terza ondata, quella che ha cambiato tutto nell’immaginario collettivo e che cambierà il modo di fare ricerca online: i Large Language Models.

Gli LLM non recuperano documenti: generano risposte. Sono addestrati su corpus enormi di testo e imparano a prevedere la sequenza più probabile di parole in risposta a un input. Non archiviano fatti come un database: assorbono pattern.

Questo li rende straordinariamente capaci di produrre testo fluido, coerente, approfondito. Ma hanno, nelle loro prime versioni, mostrato un limite evidente: la loro conoscenza è congelata al momento dell’addestramento.

La soluzione: i sistemi RAG

La risposta a questo limite si chiama RAG, Retrieval Augmented Generation.

L’idea è semplice: prima di generare una risposta, il sistema effettua una ricerca su una base di conoscenza esterna , un database vettoriale, documenti interni, il web, e usa i risultati trovati per arricchire il contesto che viene passato all’LLM.

In pratica: l’utente fa una domanda,il sistema cerca documenti pertinenti, i documenti vengono aggiunti al contesto, l’LLM genera una risposta basata su quel contesto specifico, non solo su quello che “ricorda” dall’addestramento.

Questo ha risolto i principali problemi degli LLM standalone: le risposte possono citare fonti verificabili, includere informazioni recenti, lavorare su domini specializzati senza riaddestramento costoso.

I primi sistemi RAG erano però lineari e statici: recupero singolo, pipeline predefinita, nessuna capacità di adattarsi alla complessità della domanda. La qualità della risposta dipendeva interamente dalla qualità del primo recupero. Se la ricerca sbagliava, sbagliava tutto il sistema.

Nel tempo sono stati aggiunti layer di raffinamento: reranker per riordinare i risultati, riscrittura automatica della query, sistemi ibridi keyword+semantica.

Il salto che cambia tutto: gli agenti AI

Ed è qui che arriviamo al presente.

Gli agenti AI sono sistemi che usano LLM come motore di ragionamento e strumenti esterni per eseguire compiti in modo autonomo. Non seguono una pipeline fissa: ragionano sul problema, decidono quali passi compiere, eseguono, valutano i risultati e, se necessario, iterano.

Applicato alla ricerca, questo cambia tutto. Un sistema RAG classico riceve una domanda e fa una ricerca singola. Un agente, invece, si pone domande preliminari: “Ho davvero bisogno di cercare? Dove e come devo farlo? La query va riformulata? Ho informazioni sufficienti o devo approfondire? Le fonti sono coerenti o devo verificare?”

Oggi i principali sistemi di AI search adottano architetture agentiche (Agentic RAG), ma con livelli di maturità diversi. Perplexity (soprattutto in modalità Deep Research) e ChatGPT Deep Research sono tra i più avanzati: effettuano ricerche multiple, riformulano query autonomamente, verificano fonti e costruiscono report attraverso iterazioni successive.

Google AI Mode e Gemini, invece, pur essendo agentici, mantengono un approccio più cauto e controllato, privilegiando scala, velocità e affidabilità su miliardi di query quotidiane.Google AI Mode, ChatGPT Search, Perplexity, Gemini Deep Research, Microsoft Copilot: tutti questi sistemi pianificano, utilizzano più strumenti, recuperano informazioni più volte, valutano i risultati e decidono se continuare la ricerca.

E questa non è la fine della SEO. E’ il suo reboot

Per anni si è potuto lavorare sugli angoli: keyword giusta, titolo ottimizzato, qualche link e via. Il sistema era abbastanza meccanico da premiare chi conosceva le regole del gioco, indipendentemente dalla qualità reale del contenuto.

Quegli angoli si stanno chiudendo uno a uno.

Gli agenti AI non cercano il contenuto più ottimizzato. Cercano il contenuto più affidabile, più chiaro, più utile da includere in una risposta. E per farlo ragionano, verificano, confrontano — esattamente come farebbe un ricercatore umano esperto a cui è stato chiesto di trovare le fonti migliori su un argomento.

Questo, paradossalmente, è una buona notizia per chi ha sempre fatto SEO nel modo giusto: capire le persone, rispondere a domande reali, costruire autorevolezza nel tempo su argomenti specifici.

Il campo di gioco non è sparito. Si è spostato.

E chi inizia adesso ad adattarsi ,strutturando meglio i contenuti, dimostrando esperienza reale, costruendo fiducia verificabile, ha ancora un vantaggio enorme, soprattutto in Italia, dove la maggior parte dei contenuti online non ha ancora fatto questo salto.

La prossima volta che scrivi un articolo, chiediti non solo “si posizionerà su Google?” ma “un agente AI lo sceglierebbe come fonte affidabile per rispondere a questa domanda?”.

Se la risposta è sì a entrambe, sei sulla strada giusta.

Se in Italia dici “Pinterest”, la maggior parte delle persone lo associa ancora al “social delle idee carine”: arredamento, outfit, makeup e ispirazione leggera. In realtà, brand e creator lo stanno trattando sempre più come un vero motore di ricerca visuale, con logiche di SEO, funnel di vendita e integrazioni sempre più sofisticate di intelligenza artificiale. Mentre tutti sono ipnotizzati dai modelli di ricerca generativa di Google e ChatGPT, Pinterest sta facendo qualcosa di molto interessante: sta portando la stessa logica conversazionale e agentica all’interno di una piattaforma fatta di immagini, gusti personali e intenzioni d’acquisto.

In questo articolo rivediamo le basi della Pinterest SEO — profilo, board, pin e keyword — aggiornandole al funzionamento attuale della visual search e agli esperimenti di AI della piattaforma. L’obiettivo è darti fondamenta solide, così che i tuoi contenuti funzionino bene sia con le persone sia con i modelli che li raccomandano.

Pinterest è un motore di ricerca?

Chiarisco subito: Pinterest non è “solo un social”ma è un motore di ricerca visuale con dinamiche proprie.

Da moodboard a motore di ricerca

Negli ultimi anni, diversi studi (tra cui una ricerca Adobe su 800 consumatori e 200 business) mostrano che una fetta crescente di persone usa Pinterest come punto di partenza per cercare idee, prodotti e soluzioni, non solo ispirazione creativa.
Non è l’ennesimo social in cui scrolli per abitudine: è un posto dove entri con una domanda in testa, anche se ancora non ha un intento chiaro e ben definito.

Esempi tipici:

• “Arredare salotto piccolo moderno”

• “Outfit colloquio lavoro estivo”

• “Menu cena vegetariana semplice”

La differenza rispetto a Google è che qui la risposta parte dall’immagine, non dalla riga di testo blu della SERP o dalle risposte sintetizzate delle AIO.

Visual search e intent‑driven discovery

Pinterest ragiona da anni in termini di “visual search” e “intent‑driven discovery”: invece di limitarsi a restituire risultati per una keyword, cerca di capire stile, atmosfera, gusti estetici, e ti mostra idee coerenti.
Dietro le quinte, questo significa usare modelli che leggono immagini, testi, pin salvati e board per costruire una sorta di “mappa dei gusti”, il Taste Graph.

Per chi crea contenuti, questo ha una conseguenza semplice: non stai solo “pubblicando pin”, stai alimentando un sistema che deve capire:

• Di cosa ti occupi

• A chi ti rivolgi

• Che tipo di estetica/stile rappresenti

Ogni decisione – titolo, descrizione, immagine, board – manda segnali a questo sistema.

Pinterest è un social?

Se si analizzano le query di ricerca e le discussioni più frequenti in lingua italiana sul tema “Pinterest e SEO”, emerge un quadro ancora legato alle prime fasi di adozione della piattaforma. Domande come “Pinterest è un social?”, “Come farsi conoscere?” o “Come aumentare i follower?” indicano che lo strumento viene ancora percepito principalmente attraverso la lente del social media marketing tradizionale.

In Italia, l’attenzione si concentra raramente sulle caratteristiche più avanzate della piattaforma, come la ricerca multimodale (multimodal search), l’ottimizzazione basata sul search intent visivo o l’interazione con i nuovi modelli di intelligenza artificiale.

Questo scenario, tuttavia, delinea un preciso vuoto competitivo per chi si occupa di posizionamento organico:

• gran parte dei contenuti presenti nel feed italiano non è ottimizzata secondo criteri SEO moderni. Spesso si tratta di Pin generati in automatico o privi di una struttura testuale coerente.

• Se sulla SERP testuale classica il posizionamento per parole chiave ad alto intento commerciale richiede investimenti a lungo termine e storicità del dominio, su Pinterest molte nicchie (specialmente nei settori arredo, moda, beauty e travel) presentano ampi margini di inserimento.

Abbandonare l’approccio “social” per adottare un modello mentale orientato ai motori di ricerca consente di intercettare gli utenti in una fase precoce e strategica del funnel d’acquisto, posizionando i propri contenuti dove la concorrenza non sta ancora ottimizzando.

Come ragiona l’algoritmo di Pinterest

Dietro la superficie di un feed visuale apparentemente semplice opera un sistema di classificazione ed elaborazione dati in tempo reale. Per comprendere la SEO su Pinterest, è necessario superare l’idea che esista un unico algoritmo lineare. Oggi la piattaforma si basa su un’architettura a più livelli: i segnali tecnici tradizionali non sono stati sostituiti, ma sono diventati le fondamenta necessarie per alimentare i nuovi modelli predittivi e generativi.

Capire come questi strati comunicano tra loro è il prerequisito essenziale per fare ottimizzazione nel panorama tecnologico attuale.

I pilastri “classici”

La struttura portante dell’algoritmo si basa su metriche di pertinenza e segnali di interazione che ricordano da vicino i fattori di posizionamento della SEO on-page tradizionale. Questo livello iniziale si focalizza su quattro macro-aree: pertinenza, engagement, freschezza e autorità.

• Pertinenza testuale strutturale: Pinterest mappa il contesto analizzando la presenza di parole chiave nei punti nevralgici del profilo e dell’architettura informativa (nome utente, biografia, titoli e descrizioni delle bacheche, titoli e descrizioni dei singoli Pin, fino al testo alternativo).

• Segnali di Engagement qualitativo: il sistema non misura solo il clic superficiale. Valuta il tasso di salvataggio (il vecchio Repin, che indica un alto valore di intent), i clic verso l’URL di destinazione e il tempo di permanenza sul Pin ingrandito (Close-up), interpretato come segnale di reale interesse.

• Fattore Freshness (Freschezza degli asset): l’algoritmo è progettato per diversificare il feed. Di conseguenza, attribuisce una priorità distributiva ai “Fresh Pin”, intesi come nuovi file di immagine o varianti grafiche inedite, penalizzando la duplicazione ripetitiva dello stesso identico file visivo sul medesimo URL.

• Qualità e autorità del profilo: viene valutata la coerenza tematica complessiva dell’account nel corso del tempo. Un profilo focalizzato stabilmente su una nicchia verticale acquisisce maggiore autorevolezza algoritmica rispetto a account che pubblicano contenuti frammentati o che adottano comportamenti considerati di spam.

In questa prima fase, la logica è puramente tassonomica: pulizia del codice, coerenza della struttura e organizzazione logica delle informazioni.

Il layer multimodale: testo + immagine

A questa base testuale e comportamentale, Pinterest sovrappone un sofisticato livello di analisi multimodale. I modelli di classificazione della piattaforma non elaborano più il testo e l’immagine come due entità separate, ma li interpretano congiuntamente per comprenderne il significato profondo.

Attraverso tecnologie di Computer Vision, Object Recognition (riconoscimento degli oggetti) e OCR (Optical Character Recognition, per la lettura del testo sovrimpresso sulla grafica), Pinterest estrae dati semantici direttamente dalla componente visiva. Come evidenziato nel paper tecnico di riferimento ACM “Introducing Multi-Modal Search at Pinterest: A New User Experience”, questo approccio serve a ridurre il divario tra ciò che l’utente cerca a parole e l’estetica del contenuto che si aspetta di trovare.

Per chi fa SEO, questo layer introduce un vincolo di coerenza assoluta: se i metadati testuali indicano “arredamento salotto minimal bianco”, ma i modelli di classificazione visiva rilevano un ambiente massimalista e saturo di colori, il segnale inviato all’algoritmo risulta contraddittorio. Questa discrepanza riduce l’affidabilità del Pin, penalizzandone la visibilità sia nella ricerca interna che nei sistemi di raccomandazione correlati.

Il layer generativo: esperienze conversazionali e tool AI in rollout

L’ultimo strato dell’architettura algoritmica è quello generativo, che trasforma Pinterest da motore di risposta statico a ecosistema assistenziale e conversazionale. Questo livello elabora i dati immagazzinati dal Taste Graph (la mappa proprietaria degli interessi e delle preferenze degli utenti) per abilitare nuove modalità di scoperta: sistemi assistenziali visual-first, interfacce di ricerca conversazionali e automazione pubblicitaria e ottimizzazione dinamica.

• Sistemi assistenziali visual-first: funzionalità concepite come assistenti intelligenti basati sull’IA generativa consentono agli utenti di formulare query complesse in linguaggio naturale (es. “mostrami idee per un salotto boho, adatte a chi ha animali domestici e con budget medio”). L’IA non si limita a cercare la parola chiave esatta, ma sintetizza e seleziona i Pin e i prodotti che meglio rispondono a quell’insieme di criteri specifici.

• Interfacce di ricerca conversazionale: progetti sperimentali e applicazioni dedicate (come i test legati ad Ask Pinterest) ridefiniscono la classica barra di ricerca, trasformando l’esplorazione in un dialogo continuo dove i Pin salvati dall’utente fanno da contesto per le risposte successive dell’intelligenza artificiale.

• Automazione pubblicitaria e ottimizzazione dinamica: strumenti dedicati ai brand (come la suite Performance+) sfruttano l’apprendimento automatico per testare varianti creative, ottimizzare i budget e prevedere le conversioni, basandosi storicamente sulla qualità organica e sui segnali SEO dei contenuti nativi.

Sebbene queste funzionalità siano soggette a evoluzioni e i loro nomi commerciali possano variare in base alle aree geografiche o alle fasi di rollout, la transizione strategica è evidente. I tuoi contenuti non devono più semplicemente posizionarsi all’interno di una griglia di risultati statica; devono possedere una struttura dati e visiva così chiara e autorevole da essere selezionati, elaborati e raccomandati dagli agenti intelligenti della piattaforma.

Che cos’è davvero la “Pinterest SEO” nel 2026

Fermiamoci ora un attimo a riflettere su tutto questo: alla luce dell'evoluzione tecnologica della piattaforma, che cosa intendo concretamente, quando parlo di ottimizzazione per Pinterest?

Dalla keyword al sistema di segnali

Avete ormai capito per usare Pinterest come strumento per la vostra strategia SEO non si limita più alla compilazione meccanica di un campo di testo o all’inserimento di una parola chiave nel titolo del Pin. Oggi, ottimizzare significa progettare un ecosistema di segnali coerenti e interconnessi (profilo, bacheche, Pin, componenti visive e dati strutturati) configurato per dimostrare l’autorevolezza del contenuto sia all’algoritmo centrale sia ai modelli di intelligenza artificiale sovrastanti.

Per essere efficace, questo ecosistema informativo deve soddisfare contemporaneamente tre requisiti tecnici: allineamento semantico, decodifica multimodale e strutturazione del dato.

• Allineamento semantico (persone): deve intercettare il linguaggio naturale, i bisogni reali e i diversi livelli di search intent espressi dagli utenti nelle loro ricerche.

• Decodifica multimodale (modelli di Machine Learning): la componente testuale (metadati) e la componente visiva (computer vision) devono confluire verso lo stesso identico significato, eliminando qualsiasi ambiguità interpretativa per i modelli di classificazione.

• Strutturazione del dato (layer generativi): le descrizioni, i link di destinazione e le informazioni di catalogo devono essere chiari, approfonditi e privi di rumore, così da risultare facilmente digeribili e utilizzabili dagli assistenti conversazionali per formulare le proprie risposte agli utenti.

Obiettivi concreti

L’attività di ottimizzazione deve essere guidata da due obiettivi strategici principali, strettamente legati al ritorno sull’investimento (ROI) del canale.

• Presidiare la parte alta del funnel (Early Discovery): Pinterest offre l’opportunità unica di intercettare l’utente nelle primissime fasi del suo percorso decisionale, quando si trova ancora in una modalità di pura esplorazione, pianificazione o creazione di wishlist. Posizionarsi in questo momento permette di orientare le preferenze di acquisto prima ancora che l’utente si sposti sui motori di ricerca tradizionali.

• Diventare una fonte di addestramento e raccomandazione ricorrente: se un ecosistema di Pin dimostra nel tempo coerenza tematica, chiarezza strutturale e ottime metriche di interazione, i sistemi predittivi e i modelli generativi della piattaforma tenderanno a registrarlo come fonte autorevole, inserendolo ripetutamente nei flussi di raccomandazione automatica e nelle risposte degli assistenti AI.

In quest’ottica, Pinterest rappresenta la palestra ideale per la cosiddetta SEO “post-keyword”: un contesto avanzato che abitua professionisti e brand a ottimizzare non più per singole stringhe di testo isolate, ma per scenari d’uso, intenti visivi e contesti d’esperienza complessi.

Dove (e come) mettere le keyword su Pinterest

In questa sezione vediamo insieme l'applicazione pratica della SEO on-page applicata a Pinterest. L'inserimento dei metadati testuali segue regole precise di architettura dell'informazione: ogni campo di testo rappresenta un punto di contatto fondamentale per i sistemi di indicizzazione e indicazione semantica.

Le aree testuali chiave

Su Pinterest l’ottimizzazione testuale non si esaurisce nel singolo contenuto, ma si sviluppa in modo gerarchico attraverso diversi contenitori di testo. Ciascuno di essi contribuisce a definire il contesto generale.

• Nome profilo / Display name: è il segnale di massima autorità a livello di account. Accanto al nome del brand o del professionista, è fondamentale inserire la macro-keyword verticale che descrive il core business (es. “Debora Tesauro | SEO & AI per e-commerce”). Questo aiuta l’algoritmo a categorizzare l’intero profilo fin dall’inizio.

• Bio del profilo: dispone di uno spazio limitato che va ottimizzato inserendo una descrizione sintetica del posizionamento di mercato. Spiega chiaramente quale valore offri, a quale pubblico ti rivolgi e quali argomenti tratti, distribuendo da due a tre parole chiave secondarie in modo perfettamente fluido e naturale.

• Titoli delle bacheche (Board titles): le bacheche fungono da “cartelle” tematiche. È necessario evitare titoli astratti, creativi o generici (come “Idee carine” o “Ispirazione”) e utilizzare invece stringhe testuali che riflettano le query di ricerca reali digitate dagli utenti (es. “Arredamento salotto piccolo moderno”).

• Descrizioni delle bacheche (Board descriptions): questo paragrafo serve a definire il perimetro semantico della bacheca. Specifica a chi si rivolge, quali problemi risolve e che tipo di Pin raccoglie, integrando sinonimi, parole chiave correlate (long-tail) e varianti del search intent.

• Titoli dei Pin: rappresentano il fattore testuale con il maggior peso specifico per il singolo asset. Devono essere chiari, focalizzati e strutturati inserendo una parola chiave forte all’inizio, preferibilmente associata a un elemento di beneficio o a un gancio informativo (es. “Guida salotto piccolo: 5 layout facili da copiare”).

• Descrizioni dei Pin: composte idealmente da due o tre frasi complete. Questo testo non deve limitarsi a una serie di tag, ma deve contestualizzare l’immagine, riprendere le parole chiave principali, espandere l’intento di ricerca e concludersi sempre con una chiara chiamata all’azione (Call to Action), invitando l’utente al clic o al salvataggio.

• Alt text (Testo alternativo) e Nome file: svolgono una duplice funzione strategica. Da un lato garantiscono l’accessibilità del contenuto per i lettori di schermo; dall’altro offrono un ulteriore livello di metadati puliti che i sistemi di computer vision estraggono per verificare la pertinenza del Pin, a partire dal nome del file immagine caricato.

L’obiettivo dell’utilizzo strategico di questa mappatura non è il keyword stuffing (il riempimento artificiale e forzato di parole chiave), bensì la creazione di una ridondanza intelligente. Fornire dati coerenti in ognuno di questi campi genera una serie di segnali univoci che guidano i modelli di classificazione nella stessa identica direzione, aumentando l’indice di affidabilità e la visibilità del contenuto.

Fresh pin, immagini e segnali che contano

La componente visiva su Pinterest non assolve a una funzione puramente estetica; rappresenta un vero e proprio fattore di posizionamento diretto. Poiché la piattaforma elabora le immagini come dati strutturati, la qualità grafica e la struttura dell'asset determinano la capacità dell'algoritmo di indicizzare e distribuire il contenuto.

Formato e qualità visiva

L’architettura del feed di Pinterest è ottimizzata per la visualizzazione verticale, in particolare sui dispositivi mobili, che catalizzano la maggior parte del traffico. Le linee guida ufficiali raccomandano un rapporto d’aspetto di 2:3 Discostarsi da questo standard compromette la resa visiva e la distribuzione organica del Pin.

Al di là delle proporzioni, i modelli di computer vision e object recognition della piattaforma richiedono elevati standard di chiarezza per poter decodificare gli elementi presenti nell’immagine. File sfocati, sottoesposti o caratterizzati da testi sovrimpressi eccessivamente piccoli o con font complessi generano due problemi principali: penalizzano l’esperienza utente (riducendo drasticamente il tasso di clic e di salvataggio) e impediscono all’algoritmo di estrarre segnali semantici puliti.

Le linee guida tecniche per l’ottimizzazione dell’asset prevedono: identificabilità, ottimizzazione del testo sopra l’immagine e coerenza cromatica.

• Isolamento del soggetto: l’oggetto o il concetto centrale del Pin deve essere immediatamente identificabile, nitido e posizionato in modo predominante per favorire il riconoscimento automatico da parte dei modelli IA.

• Ottimizzazione del testo on-image: i titoli grafici inseriti direttamente sull’immagine devono presentare un contrasto cromatico elevato rispetto allo sfondo e dimensioni tali da garantire la leggibilità OCR (Optical Character Recognition) anche da schermi mobile ridotti.

• Coerenza cromatica di nicchia: l’utilizzo di una palette di colori coerente e rilevante per il proprio settore non solo favorisce il riconoscimento del brand da parte dell’utente, ma aiuta i modelli predittivi a inserire il Pin all’interno dei cluster estetici corretti nel Taste Graph.

Errori da evitare

L’applicazione di logiche superficiali o non aggiornate alla gestione dei contenuti su Pinterest comporta una serie di errori metodologici ricorrenti. Questi scostamenti dalle linee guida ufficiali non si limitano a ridurre la visibilità immediata, ma compromettono la capacità dei modelli di intelligenza artificiale e di computer vision di comprendere, indicizzare e raccomandare correttamente gli asset.

Sostituire queste abitudini con pratiche di ottimizzazione avanzata è il primo passo per costruire un ecosistema organico che lavori a favore delle vostre strategie SEO.

Pinterest, e‑commerce e SEO del sito: come si parlano

Per i brand e le piattaforme di e-commerce, Pinterest deve essere configurato come come un'estensione diretta e sinergica dell'ecosistema SEO complessivo. I segnali generati sulla piattaforma influenzano e integrano la visibilità del sito web, creando un travaso di dati utile sia al posizionamento sia alla conversione.

Pinterest come luogo della ricerca informativa

L’analisi dei comportamenti d’acquisto evidenzia che una fetta consistente di consumatori, con una prevalenza marcata all’interno della Gen Z, utilizza Pinterest nella fase informativa della ricerca. Ricordo: in questa fase, l’utente non cerca un brand specifico, ma compone bacheche e wishlist visive per definire una rosa ristretta di opzioni prima di procedere al confronto dei prezzi e all’acquisto finale.

Questo comportamento si rivela centrale per i settori merceologici in cui l’estetica, il design e il contesto d’uso sono fattori determinanti: arredamento, moda, beauty, wedding, cucina e progetti fai-da-te. All’interno di questo scenario, la strategia SEO del brand deve mirare a due obiettivi precisi, massimizzare il tasso di salvataggio e presidiare la fase di transizione.

• Massimizzare il tasso di salvataggio: inserirsi stabilmente nelle bacheche di “ispirazione” create dagli utenti, posizionando il prodotto all’inizio del processo decisionale.

• Presidiare la fase di transizione: diventare il punto di riferimento visivo e informativo nel momento esatto in cui l’utente passa dall’esplorazione astratta alla selezione commerciale del prodotto.

Dati strutturati, cataloghi e Shopping API

Sotto il profilo strettamente tecnico, la piattaforma mette a disposizione un’infrastruttura di strumenti nativi progettati per dialogare in tempo reale con i principali CMS di e-commerce.

• Integrazione dei cataloghi: il collegamento diretto del feed prodotti con piattaforme come Shopify o WooCommerce permette di generare automaticamente i Pin Prodotto, trasformando l’inventario in asset indicizzabili.

• Sincronizzazione dei dati strutturati: l’implementazione dei metadati strutturati consente la visualizzazione dinamica di informazioni critiche direttamente sul Pin, quali il prezzo aggiornato, la disponibilità a magazzino e le specifiche tecniche dell’articolo.

• Utilizzo delle Shopping API: l’adozione delle API dedicate automatizza la sincronizzazione tra il catalogo e la piattaforma, riducendo le discrepanze di inventario ed eliminando il rischio di mostrare agli utenti o nelle campagne prodotti non più disponibili.

L’importanza di questa architettura tecnica supera la mera ottimizzazione delle campagne pubblicitarie. Questi dati strutturati e puliti rappresentano il nutrimento essenziale per i modelli di intelligenza artificiale di Pinterest, alimentando sia gli algoritmi di raccomandazione predittiva basati sugli interessi, sia le risposte fornite dagli assistenti in contesti di ricerca conversazionale

Pinterest come laboratorio di keyword e prodotto

I dati racchiusi all’interno di Pinterest Analytics offrono un osservatorio privilegiato per analizzare i comportamenti del pubblico, tracciando con precisione quali Pin, bacheche e formati grafici registrano i tassi più elevati di salvataggio, clic all’URL e conversione.

Questa mole di informazioni può essere capitalizzata per ottimizzare la SEO del sito web attraverso tre azioni strategiche.

• Ottimizzazione delle Schede Prodotto: utilizzare i dati sui Pin più performanti per perfezionare il copy testuale e la scelta delle immagini principali direttamente sulle schede prodotto dell’e-commerce.

• Espansione del piano editoriale SEO: identificare keyword a coda lunga (long-tail) e angoli comunicativi emersi dalle ricerche degli utenti su Pinterest, per poi esportarli e presidiarli nella SEO testuale classica su Google.

• Pianificazione commerciale assistita dai dati: rilevare i trend nascenti in anticipo rispetto ai volumi di ricerca tradizionali, decidendo quali categorie di prodotto spingere o rifornire in base agli interessi reali e manifesti manifestati dagli utenti, superando la logica dell’intuizione empirica.

Come usare l’AI per la tua Pinterest SEO

L'integrazione dei modelli di intelligenza artificiale flussi di lavoro SEO non deve tradursi in un'automazione cieca che satura la piattaforma di Pin sintetici e di scarsa qualità. La strategia corretta risiede nell'utilizzare l'IA generativa come un moltiplicatore di efficacia, delegando l'elaborazione dei dati e la produzione di bozze, ma mantenendo il controllo saldo sulla direzione strategica e sul controllo editoriale.

AI per ricerca e strategia

I modelli linguistici di grandi dimensioni (LLM) si rivelano alleati eccellenti nelle fasi analitiche e preparatorie della campagna, ottimizzando i tempi di ricerca e mappatura del mercato.

• Scomposizione in cluster tematici: partendo da una macro-nicchia di riferimento, l’IA è in grado di mappare e organizzare l’argomento in sotto-cluster semantici logici e strutturati.

• Generazione di ipotesi di keyword long-tail: i modelli possono elaborare liste estese di parole chiave a coda lunga basate su specifici intenti di ricerca. Queste liste fungono da base ideale che il professionista dovrà successivamente validare attraverso gli strumenti ufficiali della piattaforma, come la funzione di autocompletamento della Pinterest Search e lo strumento Pinterest Trends.

Un flusso di lavoro metodologico prevede di partire da un tema verticale (es. “arredamento piccoli spazi”), richiedere all’IA la mappatura dei sotto-temi e dei relativi search intent, verificare le stringhe direttamente sulla barra di ricerca di Pinterest per analizzare i suggerimenti e, infine, selezionare esclusivamente i termini che restituiscono risultati organici coerenti con la propria offerta commerciale.

AI per titoli, descrizioni e varianti

L’IA generativa accelera la creazione di varianti testuali necessarie a supportare la strategia di freshness senza duplicare i testi.

• Sviluppo di batch di titoli differenziati: consente di generare rapidamente declinazioni di titoli focalizzati su angoli specifici e intenti diversi (guide informative, liste di idee, risoluzione di problemi puntuali).

• Diversificazione delle descrizioni: permette di redigere descrizioni complete che arricchiscono il contesto informativo del Pin, evitando la ripetizione meccanica delle medesime formule testuali.

Per ottenere un output qualitativamente idoneo, è indispensabile configurare il contesto d’azione del modello (prompting): occorre specificare l’identità del brand, il target di destinazione e il tono di voce desiderato, vietando esplicitamente pratiche di keyword stuffing o l’uso di formule linguistiche inflazionate. L’intervento umano rimane essenziale nella fase finale per selezionare, uniformare e adattare i testi al lessico del pubblico italiano, prediligendo concretezza informativa rispetto a formule eccessivamente commerciali.

AI per automazione e analisi

L’ecosistema dei software di terze parti integra soluzioni basate sul machine learning in grado di ottimizzare la gestione operativa.

• Analisi predittiva degli asset visivi: esistono strumenti capaci di scansionare le immagini prima del caricamento per suggerire metadati e descrizioni SEO-friendly coerenti con gli oggetti rilevati.

• Programmazione e ottimizzazione dei flussi: algoritmi dedicati analizzano le metriche di performance dei Pin esistenti per identificare i contenuti con i tassi di interazione più elevati, suggerendo i momenti ideali per la pubblicazione e supportando la creazione di calendari editoriali automatizzati.

L’attegiamento ideale verso questi strumenti si riassume in una netta divisione dei compiti: l’automazione va applicata ai processi ripetitivi e a basso valore aggiunto (come la pianificazione dei post, la stesura delle prime bozze o la reportistica dei dati); la visione d’insieme, l’analisi del ROI e le decisioni di business devono rimanere centrali e guidate dall’operatore, poiché nessun modello linguistico possiede la comprensione del contesto aziendale complessivo.

Che cosa cambia con la ricerca generativa (e cosa resta uguale)

Esaminare l'evoluzione della piattaforma permette di tracciare un bilancio chiaro tra i principi immutabili del posizionamento organico e le nuove dinamiche introdotte dall'intelligenza artificiale generativa.

Cosa non è cambiato

Le fondamenta strategiche della SEO rimangono stabili, poiché l’obiettivo primario dei motori di ricerca non è mutato. Al di sotto dei livelli algoritmici avanzati, i requisiti essenziali per ottenere visibilità continuano a basarsi su tre pilastri: comprensione dell’utente, produzione di valore e architettura dei dati.

• Comprensione dell’utente: identificare con precisione i bisogni reali, le intenzioni e le domande formulate dalle persone.

• Produzione di valore concreto: creare asset informativi e commerciali che siano chiari, utili, approfonditi e capaci di risolvere un problema specifico.

• Architettura e accessibilità del dato: fornire una struttura logica, pulita e codificata che risulti facilmente leggibile sia dagli utenti sia dai crawler delle macchine.

Indipendentemente dal fatto che l’output finale venga mostrato su una classica pagina web, all’interno di una griglia visiva di Pin o sintetizzato da un assistente virtuale, il nucleo della SEO non cambia: si tratta sempre di organizzare l’informazione per rispondere a un bisogno umano.

Cosa aggiunge il layer generativo

La vera discontinuità rispetto al passato non sta nei dati in sé, ma in come le informazioni vengono elaborate, messe insieme e restituite all’utente.
Oggi l’interazione non si ferma più alla singola query statica: si sta spostando verso una ricerca sempre più conversazionale.

In pratica, le persone possono avviare dialoghi complessi, per esempio chiedere: “organizza una cena vegetariana low budget per sei persone”.
Di fronte a richieste di questo tipo, i sistemi assistivi della piattaforma non si limitano a cercare la parola chiave nei Pin, ma combinano in tempo reale più segnali: cronologia dei Pin salvati, schede prodotto del catalogo, ingredienti, abbinamenti estetici e così via.

Questo passaggio dalla ricerca testuale rigida al dialogo fluido è legato alla diffusione della multimodalità in tutto l’ecosistema dei motori di ricerca.
L’esperienza di scoperta non è più lineare: salta continuamente tra testo, immagini e cataloghi e‑commerce, spesso in parallelo.

In questo contesto, i contenuti ottimizzati vivono dentro un flusso dinamico in cui conta soprattutto una cosa: quanto riescono a essere compresi dai modelli multimodali.
È questa capacità di “farsi leggere” da testo+immagine che decide se e come verranno selezionati e combinati nelle risposte generate dagli assistenti intelligenti.

Iscriviti ora

La recente sentenza preliminare arrivata dal tribunale regionale di Monaco (Reuters) ci dice molto su questo punto: per i giudici tedeschi, ciò che appare dentro gli AI Overviews di Google non è più solo “contenuto di terzi che il motore rende trovabile”, ma un insieme di affermazioni nuove, autonome, di cui Google può essere ritenuta direttamente responsabile quando risultano false o diffamatorie.

Per il tribunale, questo basta a cambiare la natura della responsabilità: quando un sistema non si limita a indicizzare, ma genera affermazioni sue, nate da un’interpretazione (che in questo caso sarebbe sbagliata) di più fonti, chi gestisce quel sistema non può nascondersi dietro al ruolo neutrale di “motore di ricerca”.

Le persone si fidano di ciò che leggono su Google?

Parto da un’osservazione che sarebbe banale, ma che ancora non viene affrontata con la serietà che merita: le persone tendono a fidarsi moltissimo di quello che leggono nelle pagine dei motori di ricerca.

Una survey su oltre 1.100 persone (Moz – 2020 Google Search Survey) ha rilevato che il 51% degli intervistati dichiara di prendere molto spesso o spesso decisioni importanti, anche in ambito finanziario, medico o legale, basandosi sulle informazioni trovate su Google, mentre solo tra il 10 e il 13% afferma di non usare mai Google per questo tipo di scelte.

Cambiare la superficie di ricerca, come stiamo vedendo, significa che i comportamenti cambiano luogo ma non cambiano intento: le persone cercano informazioni, conferme, soluzioni; vogliono fonti autorevoli a cui affidare la propria fiducia.

Lo stesso filone di ricerca evidenzia un paradosso: molti riconoscono di imbattersi in informazioni poco affidabili, e tuttavia continuano a usare quei risultati come base decisionale, soprattutto nelle fasce con minore alfabetizzazione digitale, che a volte non distinguono una risposta umana da un output AI.

Se questi sono i comportamenti di base con la “vecchia” search, è difficile fingere di non vedere il salto di responsabilità quando, al posto di un elenco di link, ci troviamo davanti un’unica risposta sintetica.

Le “ricette Frankenstein” e che cosa ci raccontano sull’AI

Faccio un piccolo passo indietro. Negli ultimi mesi abbiamo visto circolare un piccolo fenomeno divertente nel nostro settore: le “ricette Frankenstein”.

Per chi non lo sapesse, sono quelle ricette generate da sistemi AI che mescolano pezzi di istruzioni da fonti diverse, creando risultati esilaranti: tempi di cottura improbabili, ingredienti che compaiono solo nella lista e non nel procedimento, passaggi di preparazione combinati in modo totalmente illogico.

Queste ricette non esistono da nessuna parte, così come sono, nelle pagine web da cui vengono estratte le informazioni. Esistono solo come output del modello, che prende frammenti da contenuti diversi, li pesa, li rimescola e li riformula in un’unica risposta plausibile. È, in estrema sintesi, così che funziona la maggior parte dei sistemi generativi che usiamo:

• recuperano, o hanno già incorporato nel loro addestramento, informazioni da molte fonti

• stimano, parola dopo parola, quale sequenza risulta più coerente con il prompt e con il contesto

• non verificano, in modo nativo, la corrispondenza con una fonte specifica, a meno che non vengano progettati e collegati a sistemi di retrieval e validazione ad hoc

Quando l’oggetto della generazione è una ricetta, il peggio che può succedere è che ti ritrovi con una torta immangiabile e una storia divertente da raccontare su Facebook.

Ma cosa succede quando la query riguarda un tema “Your Money Your Life” (salute, finanza personale, decisioni legali) e l’AI crea collegamenti che nella logica umana non sarebbero mai messi in un’unica risposta, perché necessiterebbero di una contestualizzazione migliore? Qui la posta in gioco esce dall’ambito comico e entra nell’ambito reputazionale, economico, psicologico e in tanti altri aspetti, che stiamo ancora vedendo giorno per giorno, man mano che aumenta l’ambito in cui la SERP classica non è più la prima cosa che vede un utente, ma si imbatte immediatamente in una risposta AI.

Distinguere tra opinione e output

Un passaggio centrale della sentenza, secondo me, è quello in cui i giudici affermano che i risultati generati dall’AI non potrebbero essere protetti come semplice libertà di espressione. Non stiamo infatti parlando dell’opinione di un blogger, ma di un output prodotto da un sistema progettato, addestrato e controllato da un’azienda, che decide come funziona, con quali dati, con quali limiti e con quali guardrail di sicurezza.

È una linea di demarcazione importante anche per tutti gli altri attori: OpenAI, Anthropic, Perplexity e chiunque altro stia integrando sistemi generativi in prodotti usati da milioni di persone.

I contenuti YMYL e le decisioni reali

Torniamo ai temi Your Money Your Life.

Se le persone usano Google (andando avanti, sempre più spesso i layer AI sopra Google) per decidere a quale medico rivolgersi, come investire, se una certa terapia ha senso, se un’azienda è affidabile o no, la qualità della risposta diventa importante, perché come ribadito, cambiano gli scenari ma non cambiano gli intenti di ricerca: informativi, navigazionali e commerciali. E sappiamo bene che questi macro-intenti a volte contengono tutto quello che passa nella vita di una persona, dalla nascita alla morte.

"Da un grande potere derivano grandi responsabilità" - Zio Ben

Ora immagina questo scenario:

• l’utente cerca informazioni su un integratore, una terapia, una pratica finanziaria;

• AI Overviews restituisce un riassunto in apparenza ben argomentato, che però nasce dalla combinazione di fonti eterogenee, alcune magari solide, altre borderline (faccio l’esempio dei temi della salute: mi è capitato di vedere risposte che in parte erano prese da siti ufficiali, mescolate a frasi estratte da fonti meno autorevoli);

• il modello introduce un collegamento inesistente perché “statisticamente plausibile” nel suo spazio vettoriale e lo presenta come dato di fatto.

Non serve molto per capire dove possiamo andare a inciampare.
La sentenza tedesca, riconoscendo che questi sistemi possono produrre “affermazioni nuove e autonome”, mette un paletto importante: chi progetta e distribuisce questi modelli può essere ritenuto responsabile degli output, almeno quando producono danni concreti.

Perché una cosa è ridere delle “ricette Frankenstein”. Un’altra è ribadire il valore di un contenuto scritto dalle persone per le persone.

Seguo Jeff Bullas dai tempi del mio primo progetto come cruise blogger, quando correva l’anno 2011: molti dei fondamentali di web marketing e contenuti che uso ancora oggi, spesso senza nemmeno rendermene conto da quanto li ho inglobati nel mio modo di lavorare, li ho imparati leggendo il suo blog, guardando i suoi video e cercando di applicare quello che condivideva e che poteva essere utile nei miei progetti, anche quando da blogger mi sono affacciata al mondo della SEO.

Per chi non lo conoscesse, Jeff è uno dei veterani del digital marketing internazionale: da anni lavora su contenuti, crescita dei business online e, oggi, sempre di più su AI, GEO (Generative Engine Optimization) e human‑centred marketing, anche attraverso Human Signal Lab.

Da qualche giorno avevo iniziato a seguire il suo Substack proprio perché trovo molto interessante e necessaria questa visione di human‑centred marketing. È un tema che mi sta molto a cuore: capire quando ha davvero senso usare l’AI e quando, invece, il risparmio di tempo (o la mancanza di competenze) rischia di trasformarsi in un boomerang che indebolisce le strategie di marketing. Non tutto ciò che è tecnicamente automatizzabile andrebbe automatizzato, soprattutto quando parliamo di posizionamento, contenuti e scelte editoriali.

E, soprattutto, credo che questo sia il momento di fare scelte davvero differenzianti: stare alla larga dall’“AI slope”, la china scivolosa in cui si delega troppo alle macchine e si perde quel contributo umano che fa la differenza nel medio-lungo periodo. È un tema su cui tornerò.

Vedere “La SEO ai tempi dell’AI” tra le newsletter che Jeff consiglia, con la frase “offers very cool insights about GEO and more”, per me è una forma di validazione del lavoro che sto facendo su GEO e sui segnali umani che algoritmi, motori di ricerca e sistemi generativi non possono ignorare.

Questa bella sorpresa di oggi è soprattutto un incoraggiamento a continuare a studiare, sperimentare e condividere in modo onesto e concreto quello che imparo, in un momento in cui il rumore intorno all’AI è fortissimo e poco costruttivo.

Se ti interessano questi temi, ti consiglio di seguire Human Signal Lab di Jeff Bullas, che lavora proprio all’intersezione tra AI, human signals e marketing:

Human Signal Lab

Grazie a Jeff per la fiducia e grazie a chi legge, commenta e mette in discussione questi temi ogni settimana.