Website

Find headings and sections a page template repeats in the wrong place

Crawls the site, groups pages by template and language, and catches shared headings that name the wrong product, platform or city, untranslated text on translated pages, and headings that copy the H1.

When to use it

When you suspect a shared page template is putting the wrong product, platform or city name in headings, or leaving English text on translated pages.

What you get

One table per template listing each suspect heading, the pages it appears on, a verdict and the exact corrected heading per language, plus a short note for your developer.

Does it change anything in my account?

No. The assistant only reads your data and reports back.

Works with

SEO Intelligence

Fill in before sending

[site URL][domain][number of pages, e.g. 5]

Audit [site URL] for text that comes from a shared page template and is wrong on some of the pages that use it. Typical cases are a comparison table titled for one product that appears on every product page, a section heading that names the wrong platform, or English text left on translated pages. 1. Start a site crawl with seo_site_crawl for [domain] and collect duplicate titles, duplicate descriptions and pages without an H1. Group the affected URLs by template, meaning the shared path pattern such as /product/, /blog/ or /solutions/, and by language prefix. 2. Pick up to [number of pages, e.g. 5] pages from each template and each language and read their outline with site_read_url and outline=true: title, meta description, canonical and the full heading tree. 3. Compare the H2 and H3 headings across pages of the same template. A heading that is identical on every page but names a specific product, platform, city or competitor is suspicious. Check it against the page's own topic, taken from its H1 and URL, and mark it wrong when they disagree. 4. Check every non-English version for headings or descriptions still written in English, and every page for headings that repeat the H1 word for word. Deliver one table per template with these columns: heading text, pages where it appears, the topic it should name on each page, verdict (correct, wrong topic, untranslated, copy of H1), and the fix written as the exact new heading for each affected language. Close with a short note for the developer: which template most likely holds the fixed text, and that the heading should be built from the page's own data rather than a hard-coded string. Read only. Change nothing on the site.

1. Start a site crawl with seo_site_crawl for [domain] and collect duplicate titles, duplicate descriptions and pages without an H1. Group the affected URLs by template, meaning the shared path pattern such as /product/, /blog/ or /solutions/, and by language prefix.
2. Pick up to [number of pages, e.g. 5] pages from each template and each language and read their outline with site_read_url and outline=true: title, meta description, canonical and the full heading tree.
3. Compare the H2 and H3 headings across pages of the same template. A heading that is identical on every page but names a specific product, platform, city or competitor is suspicious. Check it against the page's own topic, taken from its H1 and URL, and mark it wrong when they disagree.
4. Check every non-English version for headings or descriptions still written in English, and every page for headings that repeat the H1 word for word.

Deliver one table per template with these columns: heading text, pages where it appears, the topic it should name on each page, verdict (correct, wrong topic, untranslated, copy of H1), and the fix written as the exact new heading for each affected language. Close with a short note for the developer: which template most likely holds the fixed text, and that the heading should be built from the page's own data rather than a hard-coded string.

Read only. Change nothing on the site.

Open in Claude Open in ChatGPT Discuss in the forum

More prompts

WebsiteChanges after your approval

Rebuild the site menu around pages that actually convert

Matches GA4 landing-page performance against your WordPress menus, flags valuable pages missing from the navbar, dead weight and broken links, and proposes a leaner main menu.

When to use itWhen your site menu feels cluttered or outdated and you suspect it does not point visitors to the pages that actually bring conversions.

Compare my navigation menu with what actually converts.

From GA4 property [GA4 property], pull the last 90 days by landing page: sessions and key events. Calculate key event rate as key events / sessions.

Then read every menu on [WordPress site], including the main navbar and the footer, with all their links.

Match menu links to GA4 rows by URL path (ignore the domain, trailing slashes and query strings). Where a link has no GA4 row, treat it as zero sessions and say so.

Check every menu link for problems:
- Fetch each linked URL and record its HTTP status. Anything 4xx or 5xx is broken; redirects are worth noting.
- Flag links that point to draft or private pages, to old slugs, or to http instead of https.

Deliver three lists:
1. Pages with at least 20 key events that are not in the main menu.
2. Menu links pointing to pages with fewer than 50 sessions or zero key events in 90 days.
3. Broken or outdated links, with the reason for each.

Then propose a new main menu:
- Max 7 top-level items, ordered by commercial importance.
- Exact labels of 2 to 3 words, in plain language a customer would use.
- The contact page stays as the last item.
- Move low-value pages to the footer menu instead of deleting them.

Show the current menu and the proposed menu side by side, with the exact list of menu actions you would run (add, rename, relink, reorder, remove), as a preview. Do not edit anything until I approve. After approval, apply the changes, purge the cache and read the menus back to confirm the final structure.

WebsiteChanges after your approval

Plugin and tracking health check before it breaks your conversions

A plugin-by-plugin action list that flags outdated, duplicate and conflicting plugins and double-firing tags.

When to use itWhen your WordPress site has too many plugins, updates piling up, or you fear duplicate tags are inflating the conversions your ads optimize toward.

WebsiteChanges after your approval

Replace an old phone number everywhere on the site, safely

A full map of where the old number appears, a dry-run diff of the bulk replace, and a list of places that need manual fixes.

When to use itWhen your phone number has changed and you need to be sure the old one no longer shows anywhere on your website.

WebsiteChanges after your approval

Check that your money pages are indexed and canonicals are correct

Batch-inspects your key WordPress pages in Search Console, compares Google's canonical with the one set in your SEO plugin, flags noindex and sitemap problems, and prepares fixes for your approval.

When to use itWhen important pages may be missing from Google, or you suspect noindex tags, wrong canonicals or sitemap gaps are keeping them out of search.

Check whether Google has indexed my most important pages on [WordPress site]. The Search Console property is [Search Console property].

These are the pages I use as ad landing pages: [paste your ad landing page URLs, or write "none"]

1. List the published pages and posts on the WordPress site so you have each URL and its post ID.
2. Pull Search Console page data for the last 90 days, sorted by impressions.
3. Pick up to 50 key URLs: service pages, product categories, the contact page, the ad landing pages I listed above, and the pages with the most impressions. Show me the list before you inspect.
4. Inspect them with the batch URL inspection, 20 URLs per call (so up to 3 calls). If you hit the Google quota, stop, tell me which URLs are still unchecked, and continue later.
5. For each URL, report: index verdict and coverage state, last crawl date, Google-selected canonical, and indexing or robots state.
6. Sitemap check: list the submitted sitemaps and their status (errors, warnings, pending). Then use each URL's coverage state to spot sitemap gaps. A state like "Indexed, not submitted in sitemap" or "URL is unknown to Google" means the page is likely missing from the sitemap. Treat this as a strong signal, not proof.
7. For every problem page, read its SEO fields in WordPress: meta title, canonical, focus keyword and noindex. Compare the declared canonical with Google's choice. If a single URL needs more detail (mobile usability, rich results, the user-declared canonical as Google sees it), run a single URL inspection on it.

Deliver a table sorted by severity, in this order: not indexed, canonical mismatch, noindex, likely missing from sitemap. For each row, give the likely cause and the exact fix.

If a WordPress canonical points to the wrong URL, or a page that should rank is set to noindex, show me the exact field, the current value and the new value, and wait for my approval before setting it. Do not resubmit any sitemap without asking me first. Remember that no tool can press "Request Indexing", so for pages that need a recrawl, list them so I can request it by hand in Search Console (about 10 a day).