Playbooks for AI agents

Use this when the user asks for the monthly link check. Only read. Change nothing.

1. Coverage. Use the Count posts tool for posts and pages. Read every published page, and published posts up to 200 unless the user gives another limit. Tell the user now how many of each you will cover out of the total. Ask whether other content types (such as products) should count too.
2. Build the exists list. Page through the Get posts tool and the Get pages tool (status publish, 50 per page) and note each item's ID, title, link and slug (the last part of its link). If you stopped at the post limit, every finding that involves a post past the limit is "unchecked", not broken and not orphaned.
3. Read the links. Page through the same tools again with include_content set to true and content_format raw, 10 per page. From each body, collect every link that points to this site's own domain (any item's link shows the domain). Ignore links to other sites: you cannot check them from here, and the report must say so.
4. Broken internal links. A link is broken when its path matches nothing in the exists list. Do not classify, and list under "Not sure" instead: the home page, category and tag archives, author archives, feeds, files in the uploads folder, links in the ?p= or ?page_id= form, and links to any content type you did not read. List each broken link with the post it sits in and the exact link text.
5. Menus. If the List menus and List menu items tools are available, read each menu. Flag custom links to this site that match nothing in the exists list, and items that point to a post or page that is not published. If the menu tools are missing, skip this step and say so.
6. Orphans. A published page or post is an orphan when no body from step 3 links to its path and no menu item points to it. For each candidate, run the Search content tool with its slug, and drop it from the list if a body holds that slug inside a link. If you did not read every published post, call each orphan "possible" rather than certain, and name the posts you did not read.
7. Reply with three tables: Broken internal links (where, link, link text), Menu problems (menu, item, problem), Orphans (title, ID, link). Largest table first. Then the "Not sure" list, the coverage line from step 1, and the three fixes you would make first.

Rules:
- Never edit a post, page or menu during this check. If the user wants a fix, they ask for it separately.
- Never call a link broken because it points to something you did not read.
- If a tool is missing, fails or stops paging early, say which part you could not check and finish the rest.

Use this when the user asks you to get a guest author's post ready. The post must still be a draft or pending review.

1. Find the post. If the user named it or gave an ID, read it with the Get post tool. If not, list posts with status pending, then draft, with the Get posts tool, and ask which one. Do not guess.
2. Status check. If the post is published, scheduled or private, stop and tell the user. This playbook only works on drafts and pending posts.
3. Read it with content_format raw. Report: the title and its length, the word count, every heading in order, any placeholder text (such as "lorem ipsum", "TODO" or "[insert"), and any paragraph that repeats another.
4. Duplicates. Search the site for the post's main topic with the Search content tool. List up to three close matches with their links, so the user can decide whether the post overlaps.
5. Links. List every link in the body. Mark links to this site and links elsewhere, and flag any link with empty or generic text such as "click here".
6. Categories and tags. Read the site's terms with the Get terms tool. Say if the post is only in Uncategorized or has no tags, and suggest existing terms that fit. Do not create new terms.
7. Featured image. Say if there is none. Offer up to three images from the Get media tool that match the topic.
8. Reply with a checklist: each item marked OK or Needs work with one line on the fix. Then list the exact changes you propose, numbered, and wait.
9. Apply only the numbered changes the user says yes to, one at a time: text fixes with the Update post tool, terms with the Add post terms tool, the image with the Set featured image tool. When you call the Update post tool, never send a status. After each change, read the post again and confirm it landed.

Rules:
- Never publish, schedule or delete the post. Tell the user it is ready for them to publish.
- Never rewrite the author's voice beyond the changes the user approved.
- Do not change the author field.
- If a write fails or a tool is off, say so and paste the text you would have saved, so nothing is lost.

Use this when the user wants an old name, phrase or address replaced everywhere it appears in posts and pages.

1. Exact text. Ask for the old text and the new text exactly as they should be. The replace is literal and case-sensitive, so "Acme Ltd" and "ACME Ltd" are separate passes. If the user says "and variations", ask them to list each one.
2. Scope. Ask which content types (posts, pages, or both) and which statuses (published only is the default).
3. Look first. Run the Search content tool with the old text, include_content true, content_format raw, 10 per page. For each hit, show the title, link and the words around the match. Search content matches words without regard to case, so its hits can differ from what the replace will change. Point out matches inside a link address, an image name or a longer word, and ask whether those should change.
4. Dry run. Run the Replace sitewide tool with dry_run left on, for one content type and status at a time. Report the counts it returns: matched, skipped for structure (the match sits in markup), skipped for page builders, skipped for permission, failed, and whether it was truncated. It does not list titles, so never name posts it skipped. If truncated, give the total and say one call covers at most 50 posts.
5. Wait for the user to say go for that exact dry run.
6. Apply. Run the Replace sitewide tool again with the same text and scope and dry_run set to false. Report updated and failed counts. If the first run was truncated, repeat the dry run and the apply for the rest, with a yes each time.
7. Check. Run the Search content tool for the new text and for the old text. Read two posts from the new-text results with the List revisions tool and confirm a new revision exists. If the old text still turns up, say where.
8. Reply with the counts from step 6, then any titles still holding the old text, labelled "found by search". Add that page-builder pages, menus, widgets and SEO fields are not covered by this tool and need changing by hand.

Rules:
- Never run with dry_run off before the user approves that exact dry run.
- Never widen the scope beyond what the user approved.
- Never use another tool to reach content this tool skipped.

Use this when the user has removed a plugin and wants its old blocks cleaned up, or asks which pages have blocks that no longer render.

1. Registered blocks. Page through the List block types tool and keep the full list of block names.
2. Pages. Page through the Get pages tool, published, 10 per page, with include_content true and content_format raw. Keep a running count and tell the user how many pages you have read out of the total. If the user named posts too, ask before covering them.
3. Find leftovers. In each page's raw markup, read every block name from the block comments, including blocks nested inside groups, columns and covers. Treat a name with no slash as core/<name>. Any name not in the list from step 1 is a likely leftover, not proof: a block registered only in JavaScript does not appear in that list. For each leftover, record its full path: its position among the top-level blocks, then its position among each parent's inner blocks. Blank lines between blocks do not count. [2, 0] is the first block inside the third top-level block.
4. Reply with a table grouped by block name: page, ID, path, and the first line of text inside the block. Ask the user to confirm which names really are leftovers. Wait.
5. For each leftover the user wants replaced, agree on the replacement (for example a core/group with a core/heading and a core/paragraph). Read each block type you plan to use with the Get block type tool, so the markup uses real attributes.
6. Show the old block markup and the exact new markup side by side. Wait for the user to say go for that block.
7. Replace it with the Replace block tool, passing the page ID, the path and the expected block name, so the call is refused if the page changed. Report any content warnings the tool returns.
8. Read the page again with the Get page tool and confirm the new block is at that path.
9. Reply with: replaced (page and path), refused (page and reason), left as is.

Rules:
- One block per call. Never resend a whole page.
- Never replace a block the user did not approve by page and path.
- Keep the old block markup in your reply so the user has a copy.

Use this when the user asks you to fix missing meta descriptions or SEO titles.

1. Which plugin. Get playbook lists which of this playbook's SEO tools this connection can use; use the tools of the SEO plugin that is available. If the List plugins tool is available and more than one SEO plugin is active, ask the user which to use. If no SEO tool is available, stop and say so.
2. Scope. Cover the 50 most recent published posts unless the user asks for more or for pages. List them with the Get posts tool.
3. Read. For each post, read its SEO fields with the read tool for that plugin. An empty meta description is the gap to fix. An empty SEO title usually means the plugin's default title template applies, which already gives a working title, so only propose titles if the user asks for titles too.
4. Propose. For each gap, write a description of about 155 characters or fewer (and, if asked, a title of about 60 or fewer), based only on what the post says. Never invent prices, dates, numbers or claims.
5. Reply with a table: post title, ID, current value, proposed value. Number the rows. Wait.
6. Save only the rows the user approves, in batches of 10 at most, with the update tool for that plugin. Send only the fields you are filling, so nothing else on the post changes.
7. After each batch, read the fields back with the read tool and confirm each value landed. List any that did not.
8. Reply with: saved (count), refused or failed (post and reason), skipped by the user (count).

Rules:
- Never overwrite a field that already has a value unless the user names that post and field.
- Never change the focus keyword, canonical, robots or social fields in this playbook.
- If the update tool is off, give the user the approved table so they can paste the values by hand.

Use this when the user wants to know whether posts on the site aim at the same focus keyword. Only read. Change nothing.

1. Which plugin. Get playbook lists which of this playbook's SEO tools this connection can use. Use the Yoast or Rank Math read tool that is available. If the List plugins tool is available and both plugins are active, ask the user which one the site uses. If neither read tool is available, stop and say so. All in One SEO and Slim SEO store no focus keyword these tools read.
2. Build the index. Page through the Get posts tool for published posts, 50 per page, up to 200 unless the user sets a limit. For each, read the focus keyword with the read tool and keep: keyword, title, ID, link, publish date. Rank Math can hold several keywords separated by commas; index the first one, which is the primary.
3. Coverage first. Before any grouping, tell the user how many posts you indexed, how many have no focus keyword, and whether you stopped at the limit.
4. Normalize each keyword: lower case, singular, words sorted. Two posts collide when their normalized keywords are the same.
5. For each collision group, compare the posts on what you can see: title, publish date, and whether the keyword appears in the title. Do not read search data; these tools have none.
6. Options. For each group, list the three usual options for the user to choose from: keep one post on the keyword and give the others a new one, merge the posts, or leave them because they answer different questions. Mark which option you lean towards and why, as a judgment call.
7. Reply with one table per group (keyword, title, ID, link, publish date, keyword in title yes or no), then your options line under each table.

Rules:
- Never change a keyword, title or redirect. If the user wants changes, they ask for them separately.
- Never claim one post ranks better than another.

Use this when the user wants to set up a sale.

1. Brief. Ask for all of these in one message if any is missing: which products or categories, the discount (a percentage or a fixed amount), how to round (for example to .99), and the start day. Do not start on a guess.
2. Size. Get the product counts with the Count WooCommerce products tool.
3. Pick the products. Page through the List WooCommerce products tool, status publish, 100 per page, and keep the ones in the named categories (use the Get terms tool with taxonomy product_cat to match names) or the named products.
4. Read prices. For each product, read it with the Get WooCommerce product tool. For a variable product, list its variations with the List WooCommerce product variations tool, because the sale price is set on each variation.
5. Existing sales. Flag every product or variation that already has a sale price. Do not overwrite those unless the user says so for that item.
6. Coupons. Read the existing coupons with the List WooCommerce coupons tool and flag any code that clashes with the sale (same products, overlapping dates).
7. Plan. Reply with one table: product, variation (if any), ID, regular price, current sale price, new sale price. Show the sum of rows and the number of products. If the user wants a coupon too, write its settings (code, type, amount, limits, expiry) as text for the user to create in WooCommerce. Do not create it.
8. Wait. Only when the user says go, on the start day, set each new sale price with the Update WooCommerce product tool, or the Update WooCommerce product variation tool for variations. Send only the sale price field.
9. After every 10 saves, read the items back and confirm the sale price landed. Stop at the first failure and report it.
10. Reply with: set (count), already on sale and skipped (count), failed (item and reason). Add the rows needed to end the sale later: the same items with an empty sale price.

Rules:
- Never change a regular price, stock, status or description in this playbook.
- Never create, edit or delete a coupon or an order, whether or not the tool is switched on. Never ask the user to unlock the high-risk lock.
- Prices are text like "14.99", with no currency sign.

Use this when the user asks which orders are stuck. Only read. Change nothing.

1. Thresholds. Use these unless the user gives others: pending payment older than 2 days, on hold older than 3 days, processing older than 5 days. If you do not know today's date, ask before you start.
2. Counts. Get the order counts by status with the Count WooCommerce orders tool, so you can tell the user how big each queue is.
3. List. For each of the three statuses, page through the List WooCommerce orders tool with that status. Keep the orders older than the threshold. List rows do not include customer details, which is fine for this step.
4. Detail. For each kept order, up to 30, read it with the Get WooCommerce order tool for its total, payment method and line items, and read its notes with the List WooCommerce order notes tool. Keep the most recent note's date and first line. If there are more than 30, say how many you did not open.
5. Reply with one table per status: order number, date, age in days, total, payment method, last note (date and first line). Oldest first. Do not include customer email, phone or address in the reply; use the order number to identify each one.
6. End with one line per status on the likely next step a person should take, based only on the notes (for example "payment failed, customer not contacted"). Mark it as a suggestion.

Rules:
- Never change an order's status, add a note, refund or cancel anything. Some of these writes are locked by default and some are not, so do not rely on the lock.
- If paging stops early or a tool is off, say what you could not check.

Use this when the user asks what to reorder. Only read. Change nothing.

1. Best sellers. Read the top sellers with the Get WooCommerce top sellers report tool, limit 100, period month unless the user asks for week or year. The month report covers the current month so far, so early in the month the figures are small.
2. Stock. Page through the List WooCommerce products tool, status publish, 100 per page. Keep products whose stock status is out of stock or on backorder.
3. Low stock. For products that are in stock and appear in the best sellers, read them with the Get WooCommerce product tool and note the stock quantity when stock is managed. Treat 5 or fewer as low unless the user gives another number. For variable products, check each variation with the List WooCommerce product variations tool.
4. Rank. Put products in this order: out of stock and a best seller, low stock and a best seller, out of stock and not a best seller.
5. Reply with one table: product, variation (if any), ID, stock status, quantity (or "not tracked"), units sold in the period. End with one line saying which period the sales figures cover and that it may be a partial month.

Rules:
- Never change stock, prices or status. If the user wants stock updated after a delivery, they ask for that separately.
- Never estimate sales you did not read from the report.

Use this when the user wants the custom field data on one content type cleaned up.

1. Scope. Ask which content type and which fields matter, if the user has not said. If the Get post types tool is available, use it to find the content type's slug.
2. Field map. Read the field groups with the List ACF field groups tool for each field's key, label and type. The list does not say which content type a group belongs to or what names the fields use, so read one existing item of that content type with the Get post ACF fields tool, match its field names to the labels, and confirm the match with the user. Use only names and keys confirmed this way in every later step.
3. Items. Page through the Get posts tool for that content type, published, 50 per page, up to 100 unless the user gives another limit.
4. Read values. For each item, read its fields with the Get post ACF fields tool. Note: empty fields the user said matter, values in mixed formats (for example phone numbers written three ways, dates in two formats), and values that look wrong for the field's label or type, such as text in a date field.
5. Propose. For each problem, propose a value only when it comes from the item's own title or content, or from a format rule the user gives. Otherwise mark it "needs the user".
6. Reply with a table: item, ID, field name, current value, proposed value. Number the rows. Wait.
7. Save only the approved rows with the Update post ACF fields tool, one item per call, sending only the fields in the approved rows. If a call is refused because a field name is unknown, stop, show the refusal, and check the name against step 2 before going on.
8. After each save, read the item again with the Get post ACF fields tool and confirm the value.
9. Reply with: saved, refused (item, field, reason), left for the user.

Rules:
- Never clear a field unless the user approved clearing that exact field.
- Never invent a value such as a phone number, price or address.
- Repeater and flexible content fields: report them, but do not rewrite their rows in this playbook.

Use this when the user asks you to get the coming week's events ready.

1. Dates. Use today through 7 days from today. If you do not know today's date, ask first.
2. Events. Page through the Get events tool (status publish) and keep the events whose start date falls inside the range. Do not assume the list is sorted by start date. Read every page before you decide nothing is left.
3. Detail. For each event in range, read it with the Get event tool. Check: a start and end time, a venue, at least one organizer, and a description that is not empty.
4. Venue and organizer. Read each linked venue with the Get venue tool and each organizer with the Get organizer tool. Flag a venue with no address and an organizer with no contact details.
5. Tickets. If the Get tickets tool is available, list each event's tickets and flag an event with none. If the Get attendees tool is available, count attendees per event. Do not list attendee names or emails in the reply.
6. Reply with one row per event: title, start, venue OK or problem, organizer OK or problem, tickets (count or none), attendees (count), and what to fix. Sort by start time.
7. Fixes. Offer to fix only what can be fixed from information the user gives you (for example a missing end time). Make each fix with the Update event tool after the user says yes to that exact change, then read the event again to confirm.

Rules:
- Never change an event's date, status or price without the user naming that exact change.
- Never trash an event.
- If The Events Calendar tools are missing, stop and say which ones.

Use this when the user asks for a write-up of an event that has happened.

1. Event. Read it with the Get event tool. If the user did not name it, ask. Confirm its end date is in the past; if not, stop.
2. Venue. Read it with the Get venue tool for the place name.
3. Notes. Ask the user for what happened: highlights, speakers, quotes they approve, and photos. Do not write the recap until you have these. Never invent a quote, a number or a name.
4. Attendance. If the Get attendees tool is available and the user wants a number, give the count. Never name attendees.
5. Images. If the user mentioned photos, find them with the Get media tool and list what you found.
6. Write: a title of about 60 characters, a short intro with the event name, date and venue, a section per highlight, and a closing line pointing to the next event if the user named one. Put [CHECK: what is needed] wherever a fact is missing.
7. Category. Pick one existing category with the Get terms tool. Do not create one.
8. Save with the Create draft tool, status draft. Give the user the link to the draft and every [CHECK] note.

Rules:
- Never publish, schedule or change the event itself.
- If saving fails, paste the full post into the chat.

Use this when the user asks you to deal with the comment queue.

1. Read the queue with the Get pending comments tool, page by page, up to 100 comments. Note the total the tool reports.
2. For each comment, decide: spam, genuine, or not sure. Give one short reason (link stuffing, off-topic, gibberish, a real question, and so on). For a comment that looks like a question, read the post it is on with the Get post tool so you understand the question.
3. Reply with a table: comment ID, author name, the post it is on, a short excerpt, your call, the reason. Do not include emails or IP addresses; the tools do not return them.
4. Wait for the user to say what to do with each comment, or with groups ("spam all the spam calls").
5. Apply only those actions with the Moderate comment tool: approve, spam or trash. Work in batches of 20 and report after each batch.
6. Replies. For genuine questions the user wants answered, draft a reply of two to four sentences in the chat. Only after the user approves a reply's exact text, post it with the Create comment tool, with the post ID and the comment ID as the parent. Tell the user it is waiting in moderation for them to approve.
7. Reply with: approved, spammed, trashed, replies waiting (each a count with IDs), and how many are still in the queue.

Rules:
- Never permanently delete a comment.
- Never approve a reply on the user's behalf.
- Never answer a question about prices, refunds, orders or legal matters in a reply. Flag those for the user.

Use this when the user wants the media library checked.

1. Size. Use the Count media tool to get the total and the count of images.
2. Read. Page through the Get media tool for up to 200 of the newest items. Skip files that are not images.
3. Alt text. Note every image with empty alt text.
4. Attached or not. For images with empty alt text and for any image the user asks about, read it with the Get media item tool and note its parent. An image with no parent is unattached. For each unattached image, search the site for its file name with the Search content tool. If a post mentions it, it is in use.
5. Alt text proposals. For up to 30 images with empty alt text, propose alt text of 125 characters or fewer, based on the file name, title, caption and the post it is attached to. Do not describe what you cannot see. If there is nothing to go on, mark it "needs the user".
6. Reply with two tables. Missing alt text: image title, ID, attached to, proposed alt text, numbered. Unattached and not found in content: title, ID, upload date, file URL. Say clearly that "not found" is not proof the file is unused, because themes, widgets and page builders can use images this check cannot see.
7. Save only the alt text rows the user approves, with the Update media tool, sending only the alt text. Read each item back and confirm.

Rules:
- Never delete, rename or replace a file.
- Never change titles, captions or descriptions unless the user asks for that exact change.

Use this when the user asks you to check the site's navigation.

1. Menus. List them with the List menus tool, with item counts.
2. Items. Read each menu with the List menu items tool. Keep each item's ID, title, URL, type, what it links to, parent and order.
3. Check each item:
- an item that points to a page or post: read it with the Get page or Get post tool. Flag it if it is not published or cannot be read.
- a custom link to this site: search for the target with the Search content tool. Flag it if nothing matches.
- a custom link to another site: list it under "external, not checked". You cannot test other sites from here.
- an item whose title no longer matches the page it points to.
- a child item whose parent is missing.
4. Reply with one table per menu: item title, ID, target, problem, suggested fix. Put menus with the most problems first.
5. Fixes. Offer title fixes for any item, and URL fixes for custom links only (a page or post item takes its address from the page). Apply each one with the Update menu item tool, passing the menu ID and the item ID, after the user says yes to that exact change. Then read the menu again and confirm.

Rules:
- Never delete a menu or a menu item. Tell the user which items they may want to remove by hand.
- Never create a new menu or change which menu sits in which theme location.

Use this when the user asks for a client's monthly report. Only read. Change nothing. If you are connected to more than one site, run every step for each site in turn and label everything with the site name.

1. Site. Read the name and URL with the Get site info tool. Put them at the top of the report.
2. Month. Use the previous calendar month unless the user names another. If you do not know today's date, ask.
3. Content. Page through the Get posts tool for published posts and keep the ones published in the month. Post dates in GMT can shift an item across a month boundary; if the user has not given the site's timezone, use GMT and say so. List titles with dates. Use the Count posts tool for the totals by status and label them "all time".
4. Comments. Read the Get pending comments tool total and report it as "waiting now".
5. Software. List plugins with the List plugins tool: name, version, active or not. Read the theme with the Get active theme tool. Flag inactive plugins as candidates for removal; do not say anything is out of date, because these tools do not show available updates.
6. Store. If the WooCommerce tools are available, read the month's sales with the Get WooCommerce sales report tool (start_date and end_date set to the month) and the order counts by status with the Count WooCommerce orders tool.
7. Agent activity. If the Get activity log tool is available, page back through it, 200 per page, newest first, until you pass the start of the month. Log times are UTC. If that takes more than 10 pages, stop, say so, and report only what you read. Count rows by status (started, success, error, denied) and list the five abilities used most.
8. Reply as a short report a client can read: a two-sentence summary, then sections for Content, Comments, Software, Store (if any) and Agent activity, each a few lines or a small table. Any section whose tool was not available says "not available on this connection". End with three suggested actions for next month, marked as suggestions.

Rules:
- Every number must come from a tool in this session. Write "not available" instead of a guess.
- Never include customer names, emails or order addresses.

Use this when the user asks what agents did on the site this week. Only read. Change nothing.

1. Range. The last 7 days up to now. Log times are UTC. If you do not know today's date or the site's timezone, ask, and state the timezone you used in the report.
2. Read. Page through the Get activity log tool, 200 per page, newest first, until you pass the start of the range. The tool cannot filter by date or user, so a busy site takes more pages. If you stop early, say how far back you got.
3. Group the rows in range by ability and status. Count started, success, error and denied for each ability. Treat a call as a read when the part after aafm/ (and after any plugin prefix such as wc-, tec-, yoast-, rankmath-, aioseo-, slim-seo-, acf-, avada-, geodirectory-) begins with get, list, count or search. Everything else is a write. If you are unsure, list it under writes and say so.
4. Writes. For each successful write, keep the user login and the detail (an ID or slug). For up to 20 writes on posts or pages, read the item with the Get post tool and note its title and current status.
5. Problems. List every error and denied row with the ability, time, user login and detail code. Group repeated ones.
6. Reply with: a summary line (rows in range, writes, errors, denied), a table of writes (time, user, ability, item), a table of errors and denied calls, and three questions the user should ask themselves (for example "Did you expect this user to delete anything?").

Rules:
- The log shows ability names, outcomes and identifiers only. Do not guess at what was sent in a call.
- The admin Activity Log tab shows more, such as refusal reasons and source address. Point the user there for any denied row they want explained.
- This log covers this plugin's own tools. Tools from other plugins served by another MCP server are not in it, and the report must say so.

Use this when the user is about to launch a site and wants a final check. Only read. Change nothing.

1. Basics. Read the site name, tagline and URL with the Get site info tool, and the timezone and date formats with the Get site settings tool. Flag a tagline still set to a default such as "Just another WordPress site", and a timezone that looks wrong for the business if the user told you where it is.
2. Placeholder text. Run the Search content tool for each of: lorem ipsum, TODO, [insert, sample page, hello world, coming soon. List every hit with its title and link.
3. Pages. List pages with the Get pages tool once for each status: publish, draft, private. Flag drafts and private pages the user expects to be live, and published pages that are very short (about 300 bytes of stored content or less in content_length, which counts block markup too).
4. Menus. Read each menu with the List menus tool and the List menu items tool. Flag items that point to a page that is not published.
5. Posts. List published posts with the Get posts tool, up to 100. Flag the default "Hello world" post and posts with no featured image.
6. Images. Page through the Get media tool for up to 100 items and count images with empty alt text.
7. SEO. If one of the SEO read tools is available, read the fields for the home page and the five most important pages the user names (or the first five in the main menu). Flag an empty meta description, and any page marked noindex.
8. Software. List plugins with the List plugins tool and the theme with the Get active theme tool. Flag inactive plugins and any plugin whose name suggests a staging or maintenance mode that should be switched off at launch.
9. Reply with one ranked list: blockers first (placeholder text on live pages, noindex on key pages, menu items to drafts), then should-fix, then nice-to-have. Each line: what, where (title and link), and the fix. End with what you could not check and why.

Rules:
- Never change anything, even a one-character fix. The user fixes or asks for fixes after reading the list.
- Never claim the site is ready. Say what you checked and what you found.
- If a tool is not available on this connection, skip that check and list it under what you could not check.