AI SEO Strategist Platform

Upwork Post — AI SEO Strategist Platform (Fixed-Price Build) Title Build an AI SEO Strategist Platform — Replaces a Senior In-House SEO Analyst (Fixed-Price, Full Handoff) Category / Skills AI Development, Full-Stack Development, SEO Software, API Integration, Google Search Console API, LLM/Claude Integration, Vector Search / Embeddings, Supabase/PostgreSQL Read this part first — it explains everything below We are not asking you to build a content generator, a keyword tool, or another SEO dashboard. Those exist and we can buy them. We are asking you to build the software equivalent of a senior in-house SEO strategist — the person a top agency pays $150,000–$200,000+ a year to sit with a book of client accounts and answer, every month, for every client: what is happening, why, what should we do about it, in what order, and what is it worth. That distinction drives every technical decision in this scope. A dashboard shows you 47 content gaps. A strategist tells you to do three things, in a specific order, and explains what each is worth in revenue. We need the second one. If your proposal describes building the first one, we are not a fit. Our agency serves home-service businesses — HVAC, plumbing, electrical contractors — on monthly retainers. Content production is already handled by a fulfillment partner. This platform sits on either side of that: it decides what should be written, and it grades what comes back. It does not write, and it does not publish. The role we are encoding Here is what a senior SEO strategist actually does across a client roster. Each item below becomes a module in this build. This is your functional spec. What the analyst does What the system must do Audits a site and learns the business Crawl, extract entities, infer the ICP, build a service taxonomy Mines Search Console for what others miss Striking distance, cannibalization, decay, indexation, opportunity scoring Studies the competition Topical coverage deltas, publishing cadence, entity gaps Maps the topical territory Topic clusters, coverage matrix, service-area gaps Understands client economics Translate rankings into estimated booked revenue Prioritizes ruthlessly Sequenced action queue, not a ranked backlog Briefs writers Structured content briefs from gap analysis Reviews delivered work Quality grading, fact-checking, revision requests Presents monthly with a point of view A client-ready strategy deliverable Answers questions on demand Conversational diagnostic interface Module-by-module build specification Module 1 — Site connection and foundation intelligence 1.1 Domain connection and crawl User adds a domain; system crawls and stores page content as structured text Google Search Console OAuth connection per property Read-only WordPress connection: inventory pages with title, URL, type, word count, schema markup present, and analysis status Google Analytics 4 connection (optional but preferred) 1.2 Entity extraction and embeddings Extract topics/entities from every crawled page with a salience score, using structured LLM output Generate embeddings for page content, chunked appropriately, stored in a vector column (pgvector or equivalent) Link entities to the pages that mention them, with mention counts This layer powers coverage scoring throughout the platform — it is foundational, build it well 1.3 Domain profile ("Foundation") Auto-generated from the crawl, per client: Central entity — the primary thing this business does Business type classification Geo markers — every location signal found on the site (city, county, neighborhood, region) Service hints — services surfaced on the homepage, as discrete tags ICP narrative — an AI-inferred description of the ideal customer: who they are, what emotional state they search in, what device and time of day, urgency level, price sensitivity, language signals, and the factors that drive their decision. This must be genuinely useful prose, not a bulleted stub. Service taxonomy — approximately 20 services, each with a classification and a descriptive paragraph Module 2 — Search Console intelligence (the deepest module) This is where a senior analyst earns their salary, and it is the module we care most about. Surface-level GSC integration will not clear our bar. 2.1 Data sync Pull search analytics per property across configurable ranges: 7d, 14d, 28d, 90d, 6mo, 12mo, 16mo, plus custom Persist snapshots so period-over-period comparison is possible without re-querying Note: filtered GSC queries require two API calls rather than one. Account for this in your architecture. 2.2 Query analysis with position and pattern filtering Position buckets, filterable: Top Results (position 10) Page 1 (11) Striking Distance (20) Page 2–4 ( 40) Supporting Topics (50+) Keyword pattern filters: Questions, Comparisons, Educational, Long-tail (4+ words), plus custom regex. Segments: All / Growing / Decaying with percentage deltas. Per-query table: query, top-ranking URL, clicks with delta, impressions with delta, CTR, position — colour-coded and sortable. 2.3 Opportunity scoring Transparent, documented, tunable formula. Our working model: Opportunity = impressions × 0.07 (potential clicks if optimized to ~7% CTR) High: 100+ Medium: 50–99 Low: 50 Per-page rollup: URL, clicks, impressions, position, opportunity band, count of missing topics, drill-down to the specific missing keywords with their impressions and average positions. 2.4 Cannibalization detection Identify queries where multiple pages from the same site compete Report: count of cannibalized queries, count of affected pages, estimated diluted clicks Per-query expansion showing the competing pages and their respective positions Surface the query mechanics (date range, raw rows returned, unique queries, row limits) so results are auditable 2.5 Indexation and decay Indexation status per page Period-over-period decay detection with the diagnosis split out: position loss vs impression loss vs CTR loss are three different problems and must be reported as such Module 3 — Competitor intelligence Add up to 3–5 competitor domains per client; crawl and process them through the same entity/embedding pipeline Entity coverage matrix: our coverage vs each competitor, per entity, classified (strong / partial / gap) Publishing frequency comparison: posts in last 30 days, last 90 days, monthly average, ours vs theirs Semantic coverage scoring: given any keyword, score how well each domain covers it semantically. Report a document-level score and a best-matching-chunk score per URL, and rank the domains against each other. URL-level gap analysis: pages they have on a topic that we don't Module 4 — Topical mapping and service-area coverage 4.1 Topic map Hierarchical map of the site's topical territory, generated from entities and page structure Node metadata: page type/category, title, meta description, intent classification, priority score, and which money page it supports Interactive visualization: expand/collapse, node counts, detail panel on selection Identifies both what exists and what is missing from the territory 4.2 Service-area coverage (critical for our use case) Our clients are local service businesses. This module matters more to us than it will seem. Given a client's primary location and a service radius, enumerate the cities and towns within it (with population data — US Census or equivalent source) Determine whether each city has a dedicated page on the client's site, and if so which URL Report coverage as a percentage and a prioritized gap list, ordered by population and proximity Example output: "0 of 89 cities within 30 miles of Dallas have a dedicated page" Module 5 — Business value translation This module is what separates a strategist from an analyst, and it is non-negotiable. Each client carries an economic profile: average ticket value, close rate, service-line margins, seasonality. Every opportunity in the system must be expressible in estimated revenue, not just clicks. Analyst output: "This page could gain 40 clicks/month." Strategist output: "This page is worth roughly $11,000/month in booked work at a $2,400 average ticket and 22% close rate, assuming ~7% CTR at position 5." Assumptions must always be visible alongside the number. A figure we cannot defend in front of a client is worse than no figure. Module 6 — Synthesis and the monthly strategy deliverable 6.1 Cross-subsystem synthesis The system must read across all modules simultaneously and produce connected findings. A siloed tool reports three separate items. A strategist reports one play: "Furnace repair is cannibalized across two pages, our entity coverage on it is thin versus the competitor ranking #1, and we have no Sherwood Park page. Consolidate first, then expand entity coverage on the surviving page, then build the city page." 6.2 Sequenced action queue Actions ranked by value-to-effort and ordered by dependency. Sequencing is itself strategic advice: Consolidate cannibalized pages before building links to them Fix indexation before commissioning new content Expand coverage on an existing ranking page before creating a competing one 6.3 The Monthly Play — the primary output Per client, per month, exportable as a branded document an account manager presents on a call: What we did since last cycle What moved — ranking, traffic, coverage changes What we're doing next — 3 to 5 sequenced actions Why — the evidence behind each, in plain language What it's worth — estimated impact in dollars, assumptions stated Module 7 — Conversational interface Chat is the primary interaction model, not a secondary feature bolted onto a dashboard. 7.1 Architecture requirement Every module above must be exposed as an agent-callable tool with a typed schema. A capability that exists only as a UI page and cannot be reached in conversation does not meet this spec. Assume roughly 15–20 tools across the platform. 7.2 Diagnostic playbooks Real questions are diagnostic, not single lookups. Implement structured reasoning chains. "Why aren't we ranking for [keyword]?" must execute in order, stopping when a check explains the problem, always returning evidence: Do we have a page targeting it at all? Is that page indexed? Where do we actually rank? (Clients frequently believe they're invisible at position 12–18 — this check alone changes the recommendation from "write" to "optimize") Are two of our own pages competing for it? How does our entity coverage compare to the pages that do rank? Is the page type mismatched to search intent? Are we internally linking to it? Is it an authority gap? (Note: no backlink data source is currently in scope — the system must state this limitation rather than speculate.) Additional playbooks required: "What is the competitor doing?", "What should I write next?", "Why did traffic drop?" 7.3 Conversational state Resolve references across turns — "what is the competitor doing?" following a ranking question means the competitors for that keyword Persist active client/site context Retain prior recommendations per client across sessions 7.4 Evidence and citation Every claim cites the underlying data. The system must be auditable — an account manager has to defend these recommendations to a paying client. Module 8 — Content briefs and quality control 8.1 Brief generation For any roadmap item, generate a writer-ready brief: target keyword, entities and subtopics to cover, recommended heading structure, search intent notes, internal links to include, word count target, and the persuasion goal. The pipeline stops here. The system does not write the article. 8.2 Content roadmap Prioritized list: title (publish-ready headline, not a topic label), target keyword, page type, funnel stage, priority tier, exists/missing status, ICP fit, opportunity value. 8.3 Quality grading Import or paste a delivered draft and score it against multiple dimensions: keyword coverage, entity coverage, topical depth, heading structure, readability level, and compliance with the brief we issued. 8.4 Fact validation Extract verifiable claims from a draft or a live page and check them against current web sources. Return each as validated / false / unconfirmed, with a corrections table (claim, issue, correction needed) for anything flagged. This matters disproportionately for us: our clients are trades businesses. An incorrect claim about permit timelines, code compliance, or gas and electrical safety is a liability event, not a content defect. 8.5 Revision output Produce a structured revision request that can be sent directly back to the writer. Module 9 — Multi-client operations Multiple client domains under one workspace, with strict per-client data isolation Per-client voice profile used both to spec briefs and to grade delivered content Client-ready exports (PDF/DOCX) for audits, roadmaps, briefs, QA scorecards, and the Monthly Play Role-based access Suggested build sequence We are open to your sequencing, but this reflects the dependencies as we understand them. Foundation — data model, auth, crawl pipeline, job/queue infrastructure, embeddings service Search Console — OAuth, sync, snapshot storage, query analysis, opportunity scoring, cannibalization Foundation intelligence — entity extraction, domain profile, ICP inference, service taxonomy Competitor and topical layer — competitor crawl, coverage matrix, semantic scoring, topic map Local coverage and roadmap — city coverage, content roadmap, brief generation Value model and synthesis — economics profile, cross-module synthesis, sequenced actions, Monthly Play Conversational layer — tool registry across all modules, diagnostic playbooks, conversational state QA layer — grading, fact validation, revision output Multi-client hardening — isolation, exports, roles Note: we would rather see a thin version of the synthesis and Monthly Play (step 6) early, operating on whatever data exists at that point, than have it arrive last. It is the differentiating output and we want to test it early. Technical expectations Stack: standard and well-documented — Postgres/Supabase or equivalent, with pgvector or comparable vector storage. No proprietary lock-in that prevents us from maintaining it after handoff. LLM: Claude preferred. Structured/JSON output for extraction tasks rather than prompt-and-parse. Async architecture: crawling, embedding, and GSC sync must run as durable background jobs with status, logs, and retry. Long-running work cannot block the request cycle. Data sources: Google Search Console API, Google Analytics 4, a scraping provider (Firecrawl or your recommendation), a competitor/keyword data API (DataForSEO, Ahrefs, Search Atlas, or your recommendation), and a US city/population dataset. Running cost target: hosting plus third-party APIs, excluding LLM token spend, should fit within roughly $500/month at approximately 20 client domains. Enterprise SEO API tiers can consume that ceiling alone — if your recommended provider would exceed it, flag it before building. Explicitly out of scope No article or content generation. Briefs only. No publishing integrations. No WordPress/GHL/Duda publish adapters, no scheduled auto-publishing. WordPress access is read-only. No autonomous action on client sites. Everything is reviewed by a human. No ongoing support, maintenance, or feature iteration after handoff. No long-term hosting or operation on your side. Deliverables Fully functional platform per the scope above, deployed and accessible for testing Complete source code repository, handed over outright Environment and configuration documentation: required API keys, redeployment process, how to onboard a new client Documentation of every scoring formula used — opportunity scoring, coverage scoring, quality dimensions, value model — so we can tune them without reverse-engineering Architecture walkthrough (Loom or live call) covering how to operate and extend the system What to include in your proposal A fixed-price quote for the full scope. Not an hourly rate. Your realistic timeline, with milestone breakdown. Relevant experience: AI/LLM integrations, embeddings and vector search, Search Console API, competitor data APIs. Which competitor-data provider you would use and why, with its actual monthly cost at approximately 20 tracked domains. How you would approach the fact-validation module specifically. We consider this the highest-risk component and the answers will tell us a lot. How you would approach cross-module synthesis — connecting findings across Search Console, competitor, and coverage data into a single recommendation rather than parallel reports. This is the core of the product. Anything in this scope you would change, and why. Links to comparable past builds if available. Proposals that quote this as a content-generation platform, or that treat the conversational layer as a chatbot wrapper over a dashboard, will not be considered. The scope above is deliberate and detailed; we are looking for someone who engages with it. Budget Fixed price, proposed by you based on the scope above. This is a substantial build and we have budgeted accordingly — we are more concerned with someone who has clearly scoped it correctly than with the lowest number. Timeline Open. Propose your realistic timeline.