Building an AI SEO Strategist: Turning Scattered Data into Prioritized Actions

A website can have search reports, analytics dashboards, keyword lists, and crawl exports while its owner still struggles to answer a simple question: what should I work on next? Each tool describes part of the situation. Someone has to compare those findings, decide which ones belong together, and turn them into a practical task.

I built AI SEO Strategist around that decision. My aim was to bring the evidence into one n8n workflow and produce a short list of recommendations that someone could inspect and act on. I chose a Top 5 action plan because prioritization matters more than filling another report with everything a tool can measure.

The central engineering problem was keeping the connection between a recommendation and its evidence clear as information moved through several sources and two AI analysis stages.

I used four complementary sources. Google Search Console contributes search visibility: the pages and queries associated with impressions and clicks. GA4 contributes organic landing-page activity, including sessions and engagement. OpenSEO research contributes keyword demand, intent, and potential topic gaps. Screaming Frog contributes technical findings such as response codes, indexability, titles, and internal links.

These sources answer different questions. A page may attract attention in search but have a technical issue that deserves investigation. Keyword research may suggest a useful topic even when no corresponding page exists. Bringing the sources together lets the analyst consider those relationships while retaining where each finding came from.

I kept keyword estimates distinguishable from measured website performance. I also used manual CSV and JSON imports for the research and crawl data. That kept the first version manageable while preserving a clear record of the source and collection date.

I made page selection repeatable, with up to five relevant URLs during testing. The workflow uses an explicit reporting window so a recommendation can be traced back to the period it describes. Running the same selection again should mean inspecting the same pages, rather than receiving a different sample.

The next step was connecting records to the right page. I normalized URLs by removing fragments and known tracking parameters and applying a consistent trailing-slash rule. Meaningful query parameters remain intact. The join uses that normalized identity instead of assuming that records arrive in the same order.

Each page record keeps search queries, analytics, research, crawl findings, source dates, and coverage together. Unmatched keyword research also stays in the analysis as a proposed topic. It does not inherit performance figures from another page simply because it appears in the same input file.

Parallel branches introduced an important failure case: one source could reach the assembly step before the others. I added Merge nodes in Append mode as synchronization points, then performed the URL join after those branches completed. That separates waiting for evidence from deciding which records belong together.

Another issue was processing that looked correct for one page but handled only the first input. I corrected the per-item execution settings and preserved item links so the page identity follows each request and analysis result. The report needs contributions from the full selected scope.

Imports needed attention too. I replaced unsupported extraction settings and mapped actual Screaming Frog headers, including Address, Status Code, and Title 1. I also kept missing measurements separate from measured zero. A failed request becomes a visible limitation that the analyst and reviewer can consider.

I split AI analysis into two stages. The first receives one page or proposed-topic record and generates action candidates from that evidence. The second receives the records and candidates together and prioritizes the strongest actions across the selected scope. This gives the final planner context without asking it to interpret every raw export from scratch.

Each candidate has a defined shape: the page or topic, target keyword, finding, evidence, priority, recommended action, business reason, confidence, and limitations. Validation checks field types, supported priority and confidence values, and nonempty evidence. The final planner must reuse evidence from the validated candidates.

Those checks make errors easier to catch, but a valid response still needs judgment. I treat model explanations as recommendations for review. The supplied evidence remains the basis for deciding whether an action makes sense.

The report is designed around a decision rather than a page-by-page inventory. Every action explains what was found, what should change, why the change matters to the business, and how much confidence the evidence supports. The source findings and limitations appear beside the recommendation so the reviewer can assess its reasoning.

I added duplicate removal and enforced a maximum of five distinct actions. The workflow can return fewer when the evidence does not justify five. That keeps the format from encouraging filler recommendations merely to complete a list.

The output includes a readable HTML report and structured JSON. It also carries the reporting dates, pages analyzed, external collection dates, and missing or stale coverage. My goal is to make the next conversation specific: which action is worth taking, and what finding supports it?

I used a local verification harness with controlled fixtures to exercise the workflow's data-processing and validation logic. The two-page case checks that both pages reach analysis and contribute to one combined report. Other cases supply a failed GA4 response, missing source matches, real crawl-header names, and an unmatched research topic.

I also checked invalid model output, duplicate actions, unsupported final evidence, and more than five distinct recommendations. These cases examine whether the workflow preserves useful information and rejects results that break its contract. A convincing report is only useful if the processing behind it behaves predictably.

The fixtures provide repeatable checks of those behaviors. They helped me catch errors that a single successful page could conceal, and they give the implementation a practical way to detect regressions when its inputs or logic change.

The delivered work includes an importable n8n workflow, a structured evidence model, a Top 5 report format, CSV and JSON import support, templates, setup documentation, and automated checks. Together, those pieces show how I approached integration, data handling, troubleshooting, and AI-assisted analysis as one system.

The most useful lesson was that recommendation quality depends on the evidence path. Page identity, timing, source coverage, and missing-data behavior all influence what an analyst can reasonably conclude. Improving those foundations makes the model's role more focused and the report easier to inspect.

I kept the scope practical: a small page selection, four sources, and a concise report for human review. The project demonstrates the kind of applied AI engineering I value—connecting real tools, resolving concrete failure cases, and shaping the output around a decision someone needs to make.