After Leaving WordPress, Who Handles All the SEO Work?
SEO does not disappear when you leave WordPress. What changes is who takes responsibility for technical hygiene, launch checks and the long term.
AI × WordPress Series · Part 5 of 8
SEO does not disappear when you leave WordPress. What changes is who takes responsibility for technical hygiene, launch checks and the long term.View the series contents
The previous article, In the AI Era, You May Not Need WordPress for Your Website at All, explored another route for new sites. The practical question that follows is:
I understand the reasoning, but leaving WordPress means losing plugins such as Yoast. Who handles all the SEO work?
This concern is real. Anyone accustomed to SEO develops a kind of muscle memory: mention SEO, and the first thought is to install a plugin.
But Yoast has never done the real SEO for you. It handles technical hygiene. The work that truly affects rankings has always been yours, largely independent of whether you use WordPress.
Once you understand that, responsibility becomes much easier to assign.
1. What have plugins actually done for you?
Lay out the functions of plugins such as Yoast and Rank Math: generating meta titles and descriptions, handling canonicals, maintaining sitemaps, outputting structured data and managing robots rules.
These tasks share a feature: clear rules. Once you define how metadata is assembled, where canonicals point and when sitemaps update, a plugin can execute automatically.
But plugins do not choose keywords, plan content or directly raise rankings. They address something else: helping search engines crawl, understand and index pages smoothly. I call this technical hygiene. Doing it well does not necessarily bring immediate growth, but doing it incorrectly can directly affect indexing.
What actually drives rankings is examining GSC queries, interpreting search intent, deciding what to write or change and how to build internal links, then waiting through an indexing cycle and reviewing the data. Plugins have never run that cycle for you. Longtime readers will recognize this from my earlier article about GSC queries.
So asking who handles SEO after leaving WP actually covers three areas: technical hygiene, processes requiring long-term follow-up and real SEO.
You still handle real SEO. Much of technical hygiene can be assigned to AI. The easily missed work is the process that needs attention over weeks or months.
2. AI can handle technical hygiene, but five decisions remain yours
After leaving WordPress, frontend code owns technical hygiene. It outputs metadata and canonicals when rendering pages, generates sitemaps during builds and derives structured data from content.
This sounds like the trouble of writing a lot of code yourself. But things have changed over the past two years: code with clear rules and fixed patterns is exactly what AI writes well. Asking Codex to configure metadata and an automatically updated sitemap for Next.js or Astro usually produces a working version quickly.
The problem is that working and correct are different things.
Much of this is execution that AI can take over. But the following five items are business decisions. AI will supply an answer without knowing which answer fits your site. Worse, mistakes often trigger no immediate alarm and only appear in the data a month or two later.
First, the hard part of canonicals is the rule, not the tag. Anyone can add a canonical to a homepage. What needs thought is where pagination, parameter URLs and filter pages should point. Incorrect rules can make pages look duplicated and split their signals.
Second, hreflang. Export business sites can rarely avoid it. AI-generated multilingual annotations often contain incomplete reciprocal links, incorrect language codes or inconsistent page mappings. Pages appear normal, while Google may simply ignore the annotations, silently breaking language and regional matching.
Third, choosing structured-data types. Whether to use Article or Product, and where to attach FAQ data, is a content decision rather than a coding decision. AI can generate syntactically valid schema that passes every validator while using the wrong type and being ignored by Google.
Fourth, robots rules must match the environment. Test sites should block crawlers; production should allow them. Mixing these up during deployment can launch a production site with noindex. Most people who have launched sites have seen it happen.
Fifth, rendering. For content pages relying on search traffic, prefer static generation or server-side rendering. Pure client-side rendering is not necessarily unindexable, but you must confirm that Googlebot sees complete body content, links and metadata after rendering. Acceptance has two stages: inspect the page source for the body first, then use Search Console's URL Inspection tool to confirm what Google actually saw.
Many of these five issues arise when AI writes tags from scratch. Earlier this year, someone compiled a list of common SEO mistakes in LLM output and vibe coding; missing canonicals and incorrect hreflang were near the top.
Fortunately, established solutions exist. Next.js's Metadata API and Astro SEO component packages encapsulate many rules, even details such as whether to omit a canonical when a page is noindex. Rather than asking AI to handwrite every tag and then checking them individually, require established components in the brief.
This removes a large set of implementation mistakes. What remains is the set of decisions components cannot make for you: canonical rules, schema types and how multilingual sites are organized.
Put simply, AI implements code using established components; you make decisions and verify the result.
Do not interpret this as configuring it once and forgetting it. Recheck whenever you launch, redesign or add a page type. Template changes can break canonicals, schema and robots rules.
3. AI will not proactively watch the results weeks later
I only understood this after encountering it myself. It is also rarely mentioned in current discussions about AI doing SEO.
After using AI on websites for a while, you notice that it handles one-off on-page and technical tasks well, but often misses work requiring ongoing follow-up over time.
Here are two examples from my own experience.
The first is version changes and 301 redirects. Code-based sites are easy to modify, so releasing several versions is normal, and each redesign may change a batch of URLs. But nobody automatically reminds you: have you added 301 redirects for the important pages?
Old URLs may already be indexed, have backlinks and bring traffic. Turning them directly into 404s after a redesign disrupts traffic and indexing continuity. This error raises no immediate alarm. By the time you notice in GSC, weeks have often passed.
The second is new-site indexing. Indexing stagnation after launch is not uncommon on new stacks outside WordPress.
My habit is to crawl the entire site with Screaming Frog after launch. It checks URLs, status codes, canonicals, metadata, internal links and rendering from a crawler's perspective. Most of the five decision areas in the previous section can reveal problems in that crawl.
AI-written code looking correct does not mean crawlers see it correctly. Screaming Frog provides another acceptance check through a crawler's eyes.
After ruling out serious issues, begin ongoing observation: GSC's Page Indexing report, sitemap status and URL Inspection results. The difficulty is not one check, but watching for several weeks after launch and deciding what comes next based on the changes. AI will not proactively appear in week three and say, "Indexing looks wrong; you should check it."
I initially thought this was a memory problem, but later realized that was incomplete. Today's AI can read repositories and search history. What it really lacks is three things: a historical baseline, a time trigger and closed-loop responsibility.
Without a historical baseline, it cannot tell what changed. Without a time trigger, it will not return one or three weeks after launch. Without closed-loop responsibility, even if it finds an anomaly, it will not automatically decide who investigates next and when to recheck.
AI can perform checks, but continuity requires a process.
Before leaving WordPress, therefore, put these tasks into your operations checklist: a complete Screaming Frog crawl after launch, 301 mapping checks at every redesign, weekly Page Indexing report reviews and a predefined order for investigating indexing anomalies. Keep old URL lists and version history so AI has a baseline for each check.
The checklist need not be complicated, but it must exist independently of AI and someone must actually execute it. For SEO practitioners, this is one of the most essential things to retain when switching stacks, and one of the easiest to lose in the excitement that AI can do everything.
4. Real SEO has never belonged to plugins
Think again about where you actually spend time doing SEO.
Watching GSC queries and assessing opportunities; deciding whether to write a separate blog post or add an FAQ to an existing page; linking to service pages; revising content in two-week cycles and using data to judge whether the changes were right.
You do this in WordPress and still do it on another stack. Only the content-publishing backend changes; the judgment and iteration cycle remains.
If the new site's content structure is cleaner and its interfaces are more AI-friendly, the cycle can run even faster. AI can organize GSC opportunities in batches, diagnose pages and draft changes. But what to write, which page to change first and where to invest resources are still your decisions. This method, discussed in the article on improving existing WordPress sites with AI, also applies to a new stack.
Leaving WordPress therefore does not mean losing SEO capability. AI can take over much of technical hygiene, while you verify it and maintain the process. Real SEO, meaning data-based judgment and content iteration, has always been in your hands.
5. One situation where I advise against switching yet
After explaining how these responsibilities can be handled, I still need to temper the enthusiasm, because this determines whether you should switch stacks now.
If you have not established the GSC-driven content cycle at all, perhaps your main service pages have no query visibility, nobody checks the queries that do appear, or the team does not know how to act on them, WordPress is not the problem. No technology stack will solve that.
The more practical approach is to stay on your existing site and get the content cycle working first. Using AI to Improve an Existing WordPress Site: What You Can Change, and What You Should Leave Alone describes the approach for established sites in detail. Use the low-risk work with clear benefits first. Once the cycle works and you have a feel for the data and content, decide whether to change the underlying system. The choice will be easier then.
Finally
The division of SEO work after WordPress is not complicated.
Have AI implement technical hygiene in code, retain control over the five decisions and recheck at every launch. Put work that spans time, such as 301 redirects, indexing and GSC monitoring, into the operations checklist beforehand and keep a comparable historical baseline. Real SEO remains yours, because plugins never took it over.
The sense of security plugins provide often exceeds the work they actually do. Seeing that clearly gives you much more freedom in choosing a stack.
For teams without a working SEO cycle, switching stacks is not the first priority. Establishing an AI-assisted efficiency process on the existing WordPress site is usually more reliable.
Define website and SEO responsibilities
Tell us who manages content, SEO and development, and what you need delivered when building or taking over a website.
Continue reading
Next: Using AI to Improve an Existing WordPress Site: What You Can Change, and What You Should Leave Alone
Previous: In the AI Era, You May Not Need WordPress for Your Website at All · View the full series