--- title: "Technical SEO Audit - CMS Implementation: Agent Skill" url: "https://unilytics.ai/skills/technical-seo-audit-cms-implementation/" canonical_url: "https://unilytics.ai/skills/technical-seo-audit-cms-implementation/" summary: "Apply a finished technical SEO audit's fixes in WordPress or Drupal: meta descriptions, titles, H1s, alt text and canonicals, each checked live." last_updated: 2026-11-14 --- # Technical SEO Audit - CMS Implementation: Agent Skill > This skill is open source under the [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0): you may use, change and share it; keep the [NOTICE](https://github.com/savenjudesajen/seo-aeo-agent-skills-tools/blob/main/NOTICE) file when you redistribute. [Source on GitHub](https://github.com/savenjudesajen/seo-aeo-agent-skills-tools/tree/main/skills/technical-seo-audit-cms-implementation). To run it with each client's context and the research tools, [connect Unilytics](https://unilytics.ai/docs/connect/). Apply a finished technical SEO audit's fixes in WordPress or Drupal: meta descriptions, titles, H1s, alt text and canonicals, each checked live. ## What you get The fixes made in the CMS, each one checked on the live page, and every outcome written back to the audit workbook. **Deliverable:** Live fixes ## When to use it A technical SEO audit is done and its page fixes need to go live in the CMS. ## Install it Free and open source under the [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0). Add it to Claude Code, Codex, Cursor or another agent that reads Agent Skills: ```sh npx skills add savenjudesajen/seo-aeo-agent-skills-tools --skill technical-seo-audit-cms-implementation ``` [Source on GitHub](https://github.com/savenjudesajen/seo-aeo-agent-skills-tools/tree/main/skills/technical-seo-audit-cms-implementation). For Claude Desktop and claude.ai, upload the skill's zip from the repo's [Releases](https://github.com/savenjudesajen/seo-aeo-agent-skills-tools/releases); the [README](https://github.com/savenjudesajen/seo-aeo-agent-skills-tools#install) also installs every skill at once as a Claude Code plugin. ## The full skill The skill's SKILL.md, version 1.0.0. The Tools section is shown below. Home page: [unilytics.ai/skills/technical-seo-audit-cms-implementation](https://unilytics.ai/skills/technical-seo-audit-cms-implementation/), the canonical source of this skill. Takes a finished audit workbook and **applies the fixes in the live CMS** through a browser session the user is already logged into, fast and safely. The audit produces recommendations; this skill ships them, row by row, with proof that each change is live and that nothing else on the page broke. ### File map - load on demand | When you reach this step | Read this | |---|---| | Drupal: node IDs, Metatag field names, the safe save method, gotchas | `reference/drupal-implementation.md` | | WordPress: Yoast fields, the 3-field write, content-PATCH alt, what is not REST-writable | `reference/wordpress-implementation.md` | | Deciding which pages to fix first (by Search Console traffic) | `reference/prioritize-by-traffic.md` | | Image alt text at scale (content vs theme, content-aware pipeline) | `reference/image-alt-at-scale.md` | ### Before you start (every run) 1. **Split the audit first.** Not every item is a CMS edit. - **Developer items** (send as a web request or ticket): redirects and redirect chains, image compression, hreflang output, sitemap configuration, HTTPS/HSTS and security headers, pagination markup, anything rendered by a theme template (e.g. author avatars). The audit's detail tabs already carry per-row fixes and source pages; hand those over as they are. - **In-house CMS items** (this skill): meta descriptions, title tags, H1s, image alt text in content, and per-page noindex/canonical confirmations. - Confirm the split with the user before touching anything. 2. **Prioritise by traffic.** Issue lists are long and traffic is power-law: a few pages carry most of the value. Order each item's worklist by Search Console impressions, do the highest-traffic pages first, and reserve the deepest (content-aware) treatment for the top tier. See `reference/prioritize-by-traffic.md`. 3. **Browser access.** Confirm a browser-automation tool is connected and that **the user has logged into the CMS admin themselves**. Never enter credentials, create accounts or authenticate on the user's behalf. If an admin page returns 403, the user's role may simply lack that one path: test the specific edit path you need before concluding there is no access (see the Drupal reference). 4. **Back-out plan.** Confirm the CMS keeps revisions (Drupal node revisions, WordPress post revisions) so any bad save can be rolled back. If revisions are off, tell the user before starting. ### The clarity gate - mandatory before any on-page recommendation No title, meta, H1 or alt recommendation gets written until you know exactly what the page is about. Unless you are certain, work in this order: 1. **Scrape** the page: rendered H1, meta, the first ~6 headings and paragraphs. For a localised page, also scrape the default-language equivalent. 2. **Then do keyword research** to ground the copy in real demand (see "Writing the copy" below). 3. **Then write** the recommendation. Never infer a page's topic from its URL slug alone. Enforce it mechanically: the worklist has a **Clarity** column marking each row `confident` or `needs-scrape`. A `needs-scrape` row's final title/meta cell stays **blank** (not cleared to implement) until its scrape and keyword research are done. ### The core workflow (per audit item, non-negotiable) For each audit item (e.g. "Meta Description - Missing", then "Page Titles - Duplicate", ...): 1. **Prepare the worklist** from the audit workbook or its data export: URL, field, the exact new value, clarity. Take only rows the user is doing in-house. On multilingual sites do the default language first; titles and metas in other languages are localisation tasks - flag them, or draft localised copy for sample approval; never machine-translate silently. 2. **Test the first ~3 rows live**, then **stop and show the user** the live result: fetch the page, quote the changed field, and prove the body content survived. Get explicit approval. 3. **On approval, bulk-apply the rest**, verifying every row and tracking progress in a sheet (`URL | field | new value | status`) so the job resumes cleanly if the session drops. 4. Move to the next item only after the user signs off on the current one. Never batch-apply an entire item before the user has approved its test rows. ### Write results back to the audit workbook as you go The audit workbook is the source of truth. As you implement each item, write the outcome back into that item's detail tab **per batch, not at the end**: - Add or populate a **final value** column (the exact text you set). - Add an **Implemented** column and mark each applied row `Yes` (with date and who applied it, if useful). Rows routed elsewhere get `Deferred - developer` or `Deferred - localisation`. - Update incrementally as rows go live, so the sheet reflects reality mid-run and doubles as the resume log. - When the whole item is done: refresh the workbook, **show the user**, then move to the next item. Edit the workbook with a spreadsheet library (e.g. openpyxl in Python), recalculate any formulas, and re-deliver it. Keep the original tab layout; only add columns. ### Writing the copy #### Ground it in demand For each page in the important tier: take the topic from the scrape, pull keyword ideas with search volume for it, and look at the top-10 Google results for the leading candidate to confirm intent matches the page. Pick one **primary** keyword and a short list of **secondary / related** terms the ranking pages share. For the tail, a lighter pass is fine (primary keyword from the page's own H1 and headings), if the user agrees. #### Distribute keywords across the three surfaces Each of the title tag, the H1 and the meta description is its own relevance surface. Put the **primary keyword in all three** (the anchor), but **split the secondary and related terms across them** so together they cover the most query space with the least redundancy: - **Title** (about 60 characters or fewer): primary plus the strongest one or two secondaries, front-loaded; it must work as a SERP headline. - **H1** (visible headline): primary plus a different secondary set; it must read naturally. - **Meta description** (about 150-160 characters, or the length the site's own style guide sets): primary plus the leftover secondary terms not already used in title or H1, in one natural sentence. Don't ship a thin description. **"Title same as H1"** is flagged when no custom SEO title is set, so the title defaults to the H1. It isn't always an error, so don't blanket-rewrite. Fix the highest-traffic ones by giving each a distinct title using the split above: that clears the flag and widens coverage. The 3-field write (title + meta + H1 together) is in `reference/wordpress-implementation.md`. ### Image alt text is its own workflow Alt text is not a clean one-field bulk edit like meta or title. Where it lives (post content vs theme template), content-aware vs filename-derived drafting, and the bulk Extract, Draft, Apply, Verify pipeline are in `reference/image-alt-at-scale.md`. Read it before starting an alt item. ### Driving the CMS - Use the browser-automation tool on the logged-in admin: navigate to pages and run JavaScript in them. Programmatic JS is faster than clicking, but **safety overrides speed on content forms** (see the rule below). - Some JS-execution tools don't await a Promise returned by an `(async()=>{...})()` IIFE and hand back `{}`. End the snippet on a **top-level `await`** expression instead (`async function f(){...}; await f()`). Plain synchronous IIFEs return their value fine. - Tool output is often truncated (around 1.5-4 KB) and some tools redact strings that look like URLs, query strings or base64. Keep large data in the page (`window.__x` or `localStorage`) and return only small counts, IDs or predicates (`.length`, `.startsWith()`). - Verify every change by fetching the **live** page cache-busted (`'?cb=' + Date.now()`) and reading the field back. CDN and CMS page caches will otherwise show stale 200s. ### The one rule that prevents disasters **Do not blind-POST a content node or post edit form** (fetching the form HTML, collecting its fields and re-submitting them with `fetch`). Content edit forms are heavy with paragraph widgets, CKEditor or the block editor: the body content lives in JS-managed editors, not in the raw `