This pack gives SEO specialists, in-house marketers and agency teams 51 prompts for the jobs that fill a working week: cleaning and clustering keyword exports, writing content briefs, auditing pages, shipping technical fixes, running local SEO and earning links honestly. Each prompt is written to work in ChatGPT, Claude and Gemini, with a role, clear rules and a defined output format.
Language models do not know what people search for or how often, so the prompts that use volumes, clicks or positions take them from rows you paste from Search Console, Semrush, Ahrefs or a crawler. The cleaning, clustering and gap prompts also forbid the model from inventing or adjusting a number, and most prompts that total or compare numbers ask it to show the sums so you can check them.
Statements about Google's rules are limited to what Google publishes on Search Central and in Business Profile help: structured data must match visible content, link spam, scaled content abuse, doorway pages, hreflang, redirects, sitemaps, Core Web Vitals and faceted navigation. Where a rule changes often, the prompt tells you to confirm the current page. Nothing in the pack promises rankings or traffic, because no prompt can.
Keyword Research, Clustering & Intent
Clean an export, group keywords into pages, label intent from what the results show, localise keywords for another market, find overlaps and quick wins in Search Console, and turn clusters into a site plan. Volumes and rankings always come from rows you paste.
Best for: Getting a messy export ready for clustering without losing rows
You are a senior SEO analyst preparing a keyword list for clustering. Clean the export below without changing any number in it.
Site and offer: {{SITE_DESCRIPTION}}
Our brand terms to flag: {{OUR_BRAND_TERMS}}
Competitor brand terms to flag: {{COMPETITOR_BRAND_TERMS}}
Export rows (keyword, plus any volume, difficulty, CPC or position columns exactly as exported):
{{KEYWORD_EXPORT}}
Rules:
- Never invent, estimate or "correct" a volume, difficulty or CPC. Copy numbers exactly as pasted; leave blank cells blank.
- Merge only true duplicates (case, plural, word order, obvious typo). List every merge you make with both originals.
- Flag, do not delete: brand terms, off-topic terms for this site, questions, and terms that look like a location or product code.
- If a row is ambiguous, keep it and mark "check".
- If you could not process every row, say how many rows you handled and where you stopped.
Output:
1. A table: keyword | numbers as pasted | flag (brand, off-topic, question, location, check, none).
2. A merge log table: kept term | merged term | reason.
3. Three observations about the list that affect clustering (for example mixed languages or very uneven volumes), each tied to rows.
Fill in: SITE_DESCRIPTION OUR_BRAND_TERMS COMPETITOR_BRAND_TERMS KEYWORD_EXPORT
Paste the rows from Semrush, Ahrefs, GSC or a spreadsheet. If the export is long, run it in batches of a few hundred rows.
Best for: Turning a flat keyword list into page-level targets
Act as an SEO strategist who groups keywords into the pages a site should build or fix.
Site and offer: {{SITE_DESCRIPTION}}
Keyword rows (keyword | monthly volume | difficulty, from the tool and country named here: {{DATA_SOURCE}}):
{{KEYWORD_ROWS}}
Maximum number of clusters: {{MAX_CLUSTERS}}
Rules:
- Use only the keywords and numbers pasted. Do not add keywords, and never invent or adjust a volume.
- One cluster = one page that could satisfy all its keywords. If two keywords need different page types, split them.
- Name the primary keyword of each cluster as the highest-volume member, and say so.
- Label the dominant intent (informational, commercial, transactional, navigational) from the wording only, and mark "unconfirmed: check the live results" because you cannot see them.
- Show the arithmetic for each cluster total (for example 900 + 480 + 110 = 1,490).
- Put keywords that fit no cluster in "unassigned" with a reason.
Output:
1. A table: cluster name | page type | primary keyword | all keywords | total volume (with sum shown) | intent (unconfirmed) | difficulty range.
2. The unassigned list.
3. The two clusters I should check first in the live results, and what to look for.
Fill in: SITE_DESCRIPTION DATA_SOURCE KEYWORD_ROWS MAX_CLUSTERS
Use cleaned rows that include a volume column. Totals are only as good as the volumes you paste, so say which tool and country they come from.
Example output · Claude (example written by The Prompt Index)
Sample inputs: SITE_DESCRIPTION = Harbour and Co (fictional), a UK online shop selling standing desks for home offices. DATA_SOURCE = Semrush, UK database, monthly volume (sample export). MAX_CLUSTERS = 4. KEYWORD_ROWS = standing desk | 2900 | 52; electric standing desk | 1600 | 48; best standing desk uk | 880 | 41; standing desk for small spaces | 210 | 30; how to set up a standing desk | 320 | 22; standing desk height calculator | 590 | 18; standing desk converter | 1300 | 45; ergonomic desk setup | 480 | 27; standing desk benefits | 390 | 24.
1. Clusters
| Cluster name | Page type | Primary keyword | All keywords | Total volume | Intent (unconfirmed: check the live results) | Difficulty range |
|---|---|---|---|---|---|---|
| Standing desks | Category page | standing desk (2,900, highest in cluster) | standing desk; electric standing desk; standing desk for small spaces | 2,900 + 1,600 + 210 = 4,710 | Transactional | 30 to 52 |
| Best standing desk (UK) | Comparison guide | best standing desk uk (880) | best standing desk uk | 880 | Commercial investigation | 41 |
| Standing desk converters | Category page | standing desk converter (1,300) | standing desk converter | 1,300 | Transactional | 45 |
| Desk setup and ergonomics | Guide with an embedded calculator | standing desk height calculator (590, highest in cluster) | standing desk height calculator; ergonomic desk setup; how to set up a standing desk; standing desk benefits | 590 + 480 + 320 + 390 = 1,780 | Informational | 18 to 27 |
2. Unassigned
None. All 9 keywords are placed: 3 + 1 + 1 + 4 = 9. If the live results show that "standing desk height calculator" is served by tool pages rather than guides, split it out as a separate page, which would need a fifth cluster, so raise the maximum if you want that.
3. Check these two first
- Standing desks: open "standing desk" and "electric standing desk" and look for whether the results are mostly shop category pages or guides. Also check whether "standing desk for small spaces" is answered by the same page or by a separate page.
- Desk setup and ergonomics: open "standing desk height calculator" and "standing desk benefits" and check whether the results are tools, guides or product pages. If they differ, this cluster should not be one page.
Volumes and difficulty are exactly as pasted; I did not add or adjust any.
Best for: Settling arguments about what a query really wants
You are an SEO analyst who classifies search intent from observed results, not from the wording of the query.
Business and page we could publish: {{PAGE_IDEA}}
For each query below I pasted what the live results show (top organic titles and URL types, plus SERP features I saw):
{{QUERIES_WITH_RESULTS}}
Rules:
- Base every label only on the pasted results. Quote the titles or features that support it.
- Use these labels: informational, commercial investigation, transactional, navigational, local, mixed, or "unclear". Choose "unclear" or "mixed" rather than forcing a label.
- If the results are dominated by one page type (guides, category pages, tools, product pages, forums), say so, and say whether my page idea matches that type.
- Do not claim you can see current rankings. Treat the pasted data as a snapshot with the date I give if I gave one.
Output:
1. A table: query | intent label | evidence (quoted titles or features) | dominant page type | does my page idea fit (yes, partly, no).
2. For every "no" or "partly": what page type or angle would fit instead.
3. Queries where results are mixed, and a suggestion for how to cover both intents without one muddled page.
Fill in: PAGE_IDEA QUERIES_WITH_RESULTS
Open each query yourself and paste what you see: result titles, URLs, and any features such as video, map or shopping blocks.
Best for: Finding queries where several of your URLs compete
You are a technical SEO consultant reviewing Search Console data for pages that compete with each other.
Site: {{SITE_DESCRIPTION}}
Rows (query | page URL | clicks | impressions | average position), from this date range: {{DATE_RANGE}}
{{GSC_ROWS}}
Rules:
- Use only these rows. Work out CTR as clicks / impressions and show it.
- A query is a "possible overlap" only if two or more of my URLs have impressions for it. Several URLs on one query is not proof of a problem: say so, and note when one URL clearly dominates.
- Check whether the URLs could be serving different intents (for example a guide and a product page). If so, say it may be fine as is.
- Do not recommend deleting or redirecting a page from this data alone. Recommend what to inspect first.
- Say which conclusions need a look at the live results or the page content.
Output:
1. A table of possible overlaps: query | URLs with clicks, impressions, CTR and position | dominant URL (if any).
2. For each overlap, one of: leave alone, differentiate the pages, consolidate (merge and redirect), or inspect first, with the reason in one line.
3. A short list of the three overlaps with the most impressions at stake.
Fill in: SITE_DESCRIPTION DATE_RANGE GSC_ROWS
Export Performance > Queries with the Pages dimension for the last 3 months. Pasted rows only.
Best for: Prioritising quick wins from queries that almost rank well
You are an SEO analyst finding queries where a small improvement could matter. Use the Search Console rows below.
Site: {{SITE_DESCRIPTION}}
Date range: {{DATE_RANGE}}
Rows (query | page | clicks | impressions | average position):
{{GSC_ROWS}}
Rules:
- Keep only rows with average position between 8 and 20. Show how many rows you kept and dropped.
- Compute CTR as clicks / impressions for each kept row, rounded to one decimal place, and rank by impressions.
- Average position is an average across many results pages. Do not describe a position as a fixed rank.
- For each kept row choose ONE first action from: improve the title or snippet, add or expand a section, add internal links, check whether the page matches the intent, or leave it. Explain the choice from the row itself.
- Do not predict traffic gains or rankings.
Output:
1. A table: query | page | impressions | clicks | CTR | position | first action | why.
2. The five rows to start with and the reason for the order.
3. Rows where the page looks wrong for the query, so a new page may be needed.
Fill in: SITE_DESCRIPTION DATE_RANGE GSC_ROWS
Export query rows with impressions and position. This prompt looks at average position 8 to 20 as a working definition; change the range in the prompt if you prefer.
Best for: Deciding which competitor keywords are worth your time
Act as an SEO strategist reviewing a keyword gap. I will paste two exports from the same tool and country.
My business and what a good visitor looks like: {{BUSINESS_DESCRIPTION}}
Keywords where my site ranks (keyword | my position | volume):
{{MY_KEYWORDS}}
Keywords where the competitor ranks (keyword | their position | volume | their URL if given):
{{COMPETITOR_KEYWORDS}}
Rules:
- Gap = keywords in the competitor list that are not in mine. Show how many you found and how you matched them.
- Judge each gap keyword for fit to my business. A gap is not automatically an opportunity; mark "not relevant" with a reason when it does not fit.
- Do not invent volumes, difficulty or ranking data. Use only the pasted numbers.
- Do not treat a competitor's page as proof it deserves its rank; note when a keyword seems to depend on their brand or product.
Output:
1. A table: gap keyword | competitor position | volume | fit (high, medium, low, not relevant) | suggested page type | reason.
2. Gap themes, with the count of keywords in each.
3. The five gaps to investigate first and what to check in the live results before committing.
Fill in: BUSINESS_DESCRIPTION MY_KEYWORDS COMPETITOR_KEYWORDS
Paste the competitor export from your own SEO tool. Read the tool's terms about pasting its data into other services.
Best for: Planning a site section that groups related pages
You are an information architect for SEO. Turn the keyword clusters below into a section of a site.
Site and audience: {{SITE_DESCRIPTION}}
Clusters (name | primary keyword | other keywords | intent):
{{CLUSTER_TABLE}}
Existing URLs on the site that might already cover these topics (URL | title):
{{EXISTING_URLS}}
Rules:
- Reuse an existing URL wherever it can serve a cluster. Propose a new page only when no existing URL fits, and say why.
- Pick one hub page and a set of supporting pages. Keep URLs short, lowercase and readable.
- Every supporting page must link to the hub and to at least one sibling, and the hub must link to every supporting page. Write the planned link as source URL > target URL > suggested descriptive anchor text.
- Do not add keywords that are not in the clusters.
- Flag any cluster that is too thin to deserve its own page and suggest merging it.
Output:
1. A tree of the section with URL, page type, primary keyword and "existing or new".
2. A table of planned internal links: from | to | anchor text.
3. The order I should build or fix the pages in, with a one-line reason for each.
4. Risks: clusters that overlap or pages that may compete.
Fill in: SITE_DESCRIPTION CLUSTER_TABLE EXISTING_URLS
Use after clustering. Include your real current URLs so the plan reuses pages you already have.
Best for: Choosing what people in another market actually type
You are an international SEO specialist planning keywords for a new language market.
Business: {{BUSINESS_DESCRIPTION}}
Source-market keywords we target (keyword | page it belongs to):
{{SOURCE_KEYWORDS}}
Target language and country: {{TARGET_MARKET}}
Keyword export for the target country, if I have one (keyword | volume | tool and date), otherwise "none":
{{TARGET_KEYWORD_DATA}}
Rules:
- A literal translation is not a keyword. For each source keyword, propose how a person in the target market would more likely phrase the need, and mark every proposal as a hypothesis until it appears in the target-country data or is confirmed by a native speaker.
- You cannot know volumes. Use only numbers in the pasted target-country data; if it is "none", give no numbers.
- Flag source keywords with no natural equivalent, different product names, regional spelling differences, or a different meaning in that market.
- Where a term is ambiguous, list two candidates and the question a native speaker should answer.
Output:
1. A table: source keyword | translation (literal) | likely local phrasing (hypothesis) | in pasted data? | confidence | question for a native speaker.
2. Source keywords to drop in this market, with reasons.
3. A review checklist for the native speaker.
Fill in: BUSINESS_DESCRIPTION SOURCE_KEYWORDS TARGET_MARKET TARGET_KEYWORD_DATA
Run with your source keywords and, if you have it, an export from a keyword tool for the target country. A native speaker should review the result.
Content Briefs & Research
SERP-led briefs built from the outlines of pages you opened, draft checks against the brief, and a template review before you publish pages at scale.
Best for: A brief a writer can follow, built from what the results actually cover
You are a senior content strategist writing an SEO brief for a freelance writer.
Target query: {{TARGET_QUERY}}
Audience and what they are trying to do: {{SEARCHER_GOAL}}
Heading outlines of the top-ranking pages I opened (one block per page, with its URL):
{{COMPETING_OUTLINES}}
What we can add that these pages cannot (original data, expert, product experience, case): {{OUR_UNIQUE_INPUT}}
Page type and word range I want, if any: {{FORMAT_NOTES}}
Rules:
- Count how many pasted outlines cover each topic and show the count (for example "5 of 7"). Topics in most outlines are the baseline; do not pad the brief with topics none cover.
- Set length by what the reader needs, not by a word count target.
- Do not invent statistics, quotes or sources. Where a fact is needed, write "source needed" and say what kind.
- Build the angle from our unique input. If it is thin, say so.
Output:
1. Search intent in one sentence and the reader's next step.
2. A coverage table: topic | pages covering it | include (must, should, skip).
3. Recommended H2/H3 outline with one line of guidance each.
4. Our unique angle, and three places to use it.
5. Questions to answer, source types to gather, and internal link placeholders.
6. What to avoid.
Fill in: TARGET_QUERY SEARCHER_GOAL COMPETING_OUTLINES OUR_UNIQUE_INPUT FORMAT_NOTES
Paste the headings (H1 to H3) of the top 5 to 8 results you opened, not the full text. Add what only you can say.
Best for: Editing against requirements instead of by feel
You are an SEO editor checking whether a draft delivers its brief.
Brief:
{{BRIEF}}
Draft:
{{DRAFT}}
Rules:
- Judge only against the brief. If the brief is vague on a point, say so rather than inventing a requirement.
- Quote the sentence or heading that proves each requirement is met. If you cannot quote evidence, mark it "not found".
- Flag any statement presented as fact without a source in the draft, and any claim that sounds like it came from a general-knowledge guess. Do not check facts yourself; list them for a human to verify.
- Flag repeated keyword phrases that read as forced, quoting the lines.
- Note anywhere the draft only summarises common knowledge and adds nothing of our own.
Output:
1. A table: requirement from the brief | met, partly or not found | quoted evidence | fix.
2. Claims to verify, each with the exact sentence.
3. Sections that add no original value and what to ask the writer for.
4. A verdict: send back, revise lightly, or ready for fact-check, with the three highest-priority edits.
Fill in: BRIEF DRAFT
Paste the brief and the draft. Works for freelancers' drafts and for AI-assisted drafts.
Best for: Testing whether a template adds value or just multiplies near-identical pages
You are a search quality reviewer. Evaluate a page template that will be used to generate many pages.
Site: {{SITE_DESCRIPTION}}
What the pages are for: {{PAGE_PURPOSE}}
Number of pages planned: {{PAGE_COUNT}}
Data fields filled in per page: {{DATA_FIELDS}}
Three sample generated pages (full text):
{{SAMPLE_PAGES}}
Rules:
- Compare the three samples. Quote the sentences that are identical or differ only by a swapped name, number or place.
- Count unique versus repeated sentences in each sample; this is a rough count, not something Google measures.
- Test whether a visitor gets something useful that they could not get from a competing page, and say what.
- Check the plan against Google's published spam policies on scaled content abuse and doorway pages. Say you cannot know how Google would treat these pages, and tell me to read the current policy text myself.
Output:
1. A table: page | unique sentences | repeated sentences | what unique value it has.
2. Risk rating (low, medium, high) with the specific evidence from the samples.
3. What data or editorial input would make each page distinct.
4. A recommendation: publish a small batch first, improve the template, or do not scale, with the reason.
Fill in: SITE_DESCRIPTION PAGE_PURPOSE PAGE_COUNT DATA_FIELDS SAMPLE_PAGES
Run on two or three real sample pages from the template, plus the data fields. Do this before publishing hundreds of pages.
On-Page Audits & Snippets
Audit a single URL, write title and meta description options, and fact-check AI-assisted drafts, metadata included, before anything goes live.
Best for: A prioritised fix list for a single page
You are a senior on-page SEO reviewer. Audit the page below against the query it should serve.
Target query: {{TARGET_QUERY}}
Page URL: {{PAGE_URL}}
Title tag: {{TITLE_TAG}}
Meta description: {{META_DESCRIPTION}}
Headings and body text:
{{PAGE_TEXT}}
Rules:
- Judge only what I pasted. You cannot see the live page, the rendering, speed, links or rankings; list what you could not check.
- Every finding must quote the exact text it refers to and have a severity: high, medium or low.
- Check: does the title describe the page and match the intent; is it unique-sounding and free of stuffing; does the meta description summarise the page honestly; is the H1 clear; do headings form a logical outline; are key questions answered early; is anything repeated or padded; are claims unsourced.
- Do not suggest repeating the keyword more often. Prefer clearer wording.
- Do not predict ranking changes.
Output:
1. A table: finding | quoted text | severity | fix.
2. Rewritten title and meta description (two options each), with a note that Google may choose its own title link and snippet.
3. The five changes to make first.
4. What to check in the live page and in Search Console.
Fill in: TARGET_QUERY PAGE_URL TITLE_TAG META_DESCRIPTION PAGE_TEXT
Paste the title, meta description, headings and the body text (or the first 800 words). State the query you want the page to serve.
Best for: Titles that describe the page instead of stuffing the keyword
You are an SEO copywriter writing title elements for one page.
Page summary: {{PAGE_SUMMARY}}
Query the page should serve: {{TARGET_QUERY}}
Current title: {{CURRENT_TITLE}}
Brand name to include at the end, or "none": {{BRAND_NAME}}
Tone: {{TONE}}
Audience: {{AUDIENCE}}
Rules:
- Write six options. Each must describe what the page actually contains and match the query's intent; do not promise anything the summary does not support.
- No keyword repetition inside a title, no all-caps, no year unless the summary shows the page is date-specific.
- Put the most important words first, because titles may be shortened to fit the device width.
- Give the character count of each option so I can compare, and remind me that there is no fixed limit and that titles may be truncated.
- Make the six options differ in approach (plain descriptive, benefit, question, specific detail, comparison, how-to) instead of rewording each other.
Output:
1. A table: option | title | characters | approach | what it assumes about the reader.
2. Your pick and the reason in two sentences.
3. One risk for each approach to test, for example a title that may be too long for mobile.
4. A reminder of what to check in Search Console after the change.
Fill in: PAGE_SUMMARY TARGET_QUERY CURRENT_TITLE BRAND_NAME TONE AUDIENCE
Google can rewrite titles and has no fixed character limit, so judge the preview in your own tool, not only the count.
Best for: Rewriting snippets for pages that get shown but not clicked
You are an SEO copywriter improving meta descriptions for pages that earn impressions but few clicks.
Site: {{SITE_DESCRIPTION}}
Date range of the data: {{DATE_RANGE}}
Pages (URL | main query | clicks | impressions | current meta description | what the page really contains in one line):
{{PAGE_ROWS}}
Rules:
- Compute CTR as clicks / impressions to one decimal place for each page and show it.
- Rewrite each description to summarise what is truly on the page. Do not promise features, prices, results or guarantees that the one-line page summary does not state.
- Use plain, specific language. Mention the main query naturally once at most.
- Google mostly builds snippets from page content and may ignore the description, and there is no length limit but it is truncated to fit. Keep each concise and note the character count.
- Do not claim the new text will raise CTR.
- If a page's summary is too vague to write from, say "need more detail" instead of guessing.
Output:
1. A table: URL | CTR | current description | rewrite | characters.
2. For each page, one sentence on why the old description may underperform (hypothesis, not fact).
3. How to compare the pages fairly after a few weeks, and what could confuse the result.
Fill in: SITE_DESCRIPTION DATE_RANGE PAGE_ROWS
Export page rows from Search Console with clicks, impressions and the current meta description. Pick pages whose query matches the page.
Best for: A pre-publish check for drafts produced with AI help
You are a fact-checker and editor reviewing a draft that was written with AI assistance. Nothing in it should be published until a human has confirmed it.
Draft:
{{DRAFT}}
Source material I have in hand (quotes, links, documents, notes):
{{SOURCE_MATERIAL}}
Title, meta description, structured data text and image alt text that go with the draft:
{{METADATA_TEXT}}
Rules:
- Extract every checkable claim (names, numbers, dates, quotes, rules, comparisons, how-to steps).
- For each claim, say whether the pasted source material supports it, quoting the matching passage. If it is not in my sources, mark "unsupported" and do not try to confirm it from memory.
- Treat the metadata with the same scrutiny as the body text: flag anything in it the page does not support.
- Flag fabricated-looking items: precise statistics without sources, quotes without speakers, references you cannot match.
- Note generic passages that add nothing specific to our experience or data.
Output:
1. A table: claim | supported, unsupported or partly | matching source quote | action (keep, fix, cut, find a source).
2. A list of metadata issues.
3. Passages to replace with first-hand detail, with a question for the author for each.
4. A publish decision: not ready, ready after the listed fixes, or ready.
Fill in: DRAFT SOURCE_MATERIAL METADATA_TEXT
Paste the draft, the sources you actually hold, and the title, meta description and alt text. Google asks for human review of AI-generated content before publishing.
Technical SEO: Schema, Redirects, Canonicals & Hreflang
Drafts and audits for JSON-LD, redirect maps and chains, canonical conflicts, hreflang sets, XML sitemaps, robots.txt, Core Web Vitals, JavaScript rendering and pre-launch checks, plus a prompt that turns any finding into a developer ticket.
Best for: Structured data that matches what visitors can see
You are a structured data specialist. Draft JSON-LD for one page using only what is visible on it.
Page URL: {{PAGE_URL}}
Schema.org type I think fits (or "suggest one"): {{SCHEMA_TYPE}}
Visible page content (copy exactly what a visitor sees, including author, dates and contact details):
{{VISIBLE_PAGE_CONTENT}}
Rules:
- Include a property only if its value appears in the pasted content. Never invent ratings, review counts, prices, dates, authors, logos or social profiles. Leave a property out rather than guess.
- Google's structured data guidelines say not to mark up content visitors cannot see, and not to mark up irrelevant or misleading content. Follow that.
- Output one JSON-LD block in a script tag with valid JSON (double quotes, no trailing commas, ISO 8601 dates only where the page shows a date).
- After the code, list required and recommended properties for this type that I must check against Google's current documentation for the specific rich result. You cannot confirm which types currently produce rich results; tell me to check, because Google retires some features.
Output:
1. The JSON-LD block.
2. A table: property | value used | where it appears on the page.
3. Properties omitted because the page does not show them.
4. Validation steps to run before publishing.
Fill in: PAGE_URL SCHEMA_TYPE VISIBLE_PAGE_CONTENT
For articles, organisations, local businesses, events, recipes and similar pages. For product pages use the ecommerce pack. Validate with Google's Rich Results Test and the schema.org validator before deploying.
Best for: Catching markup that claims more than the page says
You are a structured data auditor. Compare the JSON-LD on a page with the content visitors see.
Page URL: {{PAGE_URL}}
JSON-LD from the page source:
{{EXISTING_JSON_LD}}
Visible page content:
{{VISIBLE_PAGE_CONTENT}}
Rules:
- Check, property by property, whether each value is visible on the page. Quote both sides.
- Flag: values not shown on the page, values that differ from it, ratings or reviews with no visible reviews, prices or dates that contradict the page, a type that does not describe the page, duplicate or conflicting blocks, and invalid JSON.
- Google's guidelines say structured data must be a true representation of the page and must not describe content visitors cannot see. Treat violations as high severity. Missing recommended properties are low severity.
- Do not say that fixing the markup will improve rankings: Google says structured data problems affect rich result eligibility, not ranking. Do not claim any rich result is currently available; tell me to check Google's documentation for the type.
- If the JSON is malformed, show the line and fix it.
Output:
1. A table: property | value in markup | what the page shows | match, mismatch or not visible | fix.
2. The corrected JSON-LD.
3. A short list of what to retest and where.
Fill in: PAGE_URL EXISTING_JSON_LD VISIBLE_PAGE_CONTENT
Paste the JSON-LD from the page source and the visible text. Useful after a template or plugin change.
Best for: A redirect plan that a developer can implement and QA
You are a migration lead mapping old URLs to new ones for a site redesign or move.
Old URLs (URL | title or H1 | monthly clicks if known):
{{OLD_URLS}}
New URLs (URL | title or H1):
{{NEW_URLS}}
Server or platform where the rules will live (for example Apache .htaccess, Nginx, Cloudflare rules, WordPress plugin): {{PLATFORM}}
Rules:
- Match old to new by content, not by similar slugs. Give a confidence level (high, medium, low) and the reason.
- If no new page is a fair match, say "no match" and suggest the closest category or a deliberate 410, not the homepage by default.
- Use permanent redirects for moves that will not be reverted, one hop from each old URL to its final URL. Google says permanent server-side redirects are recommended for URL changes.
- Do not chain: if a new URL is itself being redirected, point the old URL at the final one.
Output:
1. A table: old URL | new URL | confidence | reason | needs human review (yes or no).
2. The rule syntax for {{PLATFORM}} for the high-confidence rows only, with a note on rule order.
3. A QA checklist: sample URLs, expected status codes, and what to monitor in Search Console.
4. Old URLs with traffic and no match, ranked by clicks.
Fill in: OLD_URLS NEW_URLS PLATFORM
Paste URL lists from your crawl and the staging site. Test the rules in staging first.
Best for: Collapsing chains so every old URL reaches its destination in one hop
You are a technical SEO analyst resolving redirect chains. I will paste redirect pairs from a crawl.
Redirect pairs (source URL | target URL | status code):
{{REDIRECT_PAIRS}}
Final-status notes for any destination URL, if known (URL | status):
{{DESTINATION_STATUSES}}
Rules:
- Follow each source through the pairs until you reach a URL that is not a source in the list. That is its final destination. Count the hops.
- Detect loops (a URL reaching itself) and stop; mark them "loop".
- Use only the pairs pasted. If a final destination's status is not in my notes, mark it "status unknown" and do not assume it returns 200.
- Flag mixed signals: a permanent redirect that ends in a temporary one, or a chain that ends at a URL with a non-200 status.
- Show the hop path for every chain of 2 or more hops.
Output:
1. A table: source | hops | final destination | path | issue.
2. The corrected list: source | final destination | recommended redirect type, for chains and loops only.
3. Counts: total pairs, single-hop, chains of 2 or more, loops, status unknown. Check that the counts add up to the total pairs.
4. What to change first and what to retest.
Fill in: REDIRECT_PAIRS DESTINATION_STATUSES
Paste source and target pairs from your crawler. Works best on a few hundred redirecting URLs at a time.
Example output · Claude (example written by The Prompt Index)
Sample inputs: REDIRECT_PAIRS = /old-a | /old-b | 301; /old-b | /new-b | 301; /old-c | /new-c | 301; /old-d | /old-e | 302; /old-e | /old-f | 301; /old-f | /new-f | 301; /loop-1 | /loop-2 | 301; /loop-2 | /loop-1 | 301; /old-g | /new-g | 301; /old-h | /old-a | 301. DESTINATION_STATUSES = /new-b 200; /new-c 404; /new-f 200; /new-g 200.
1. Chains and destinations
| Source | Hops | Final destination | Path | Issue |
|---|---|---|---|---|
| /old-a | 2 | /new-b | /old-a > /old-b > /new-b | Chain |
| /old-b | 1 | /new-b | /old-b > /new-b | None |
| /old-c | 1 | /new-c | /old-c > /new-c | Final destination returns 404 |
| /old-d | 3 | /new-f | /old-d > /old-e > /old-f > /new-f | Chain of 3 hops; mixed redirect types (302 then 301s) |
| /old-e | 2 | /new-f | /old-e > /old-f > /new-f | Chain |
| /old-f | 1 | /new-f | /old-f > /new-f | None |
| /loop-1 | loop | none | /loop-1 > /loop-2 > /loop-1 | Loop |
| /loop-2 | loop | none | /loop-2 > /loop-1 > /loop-2 | Loop |
| /old-g | 1 | /new-g | /old-g > /new-g | None |
| /old-h | 3 | /new-b | /old-h > /old-a > /old-b > /new-b | Chain |
2. Corrected list (chains and loops only)
| Source | Final destination | Recommended type |
|---|---|---|
| /old-a | /new-b | 301 |
| /old-d | /new-f | 301, if the move is permanent (confirm why the first hop is a 302) |
| /old-e | /new-f | 301 |
| /old-h | /new-b | 301 |
| /loop-1, /loop-2 | no destination in the data | Decide the real target; neither URL can be fixed from this list |
3. Counts
Total pairs: 10. Single-hop: 4 (/old-b, /old-c, /old-f, /old-g). Chains of 2 or more hops: 4 (/old-a, /old-d, /old-e, /old-h). Loops: 2 (/loop-1, /loop-2). Status unknown: 0. Check: 4 + 4 + 2 + 0 = 10.
4. Change first, then retest
- /old-c is a single hop but lands on a 404 (/new-c): fix or replace the destination first.
- Resolve the loop by choosing the correct target for /loop-1 and /loop-2.
- Replace /old-d, /old-e, /old-a and /old-h with direct redirects, then recrawl to confirm each is one hop ending in 200.
Best for: Finding URLs that send contradictory signals
You are a technical SEO analyst checking canonical and indexability signals from a crawl.
Platform: {{PLATFORM}}
Preferred domain and protocol: {{PREFERRED_URL_FORM}}
Crawl rows (URL | status | indexable? | canonical URL | meta robots | in sitemap yes/no):
{{CRAWL_ROWS}}
Rules:
- Use only the pasted rows. You cannot see the pages.
- Flag these patterns with the row quoted: canonical pointing to a URL that redirects or is not 200; canonical chains; canonical to a different protocol or host than the preferred one; relative canonicals; noindex URLs in the sitemap; sitemap URLs that are not indexable or not 200.
- Google describes redirects and rel=canonical as strong signals and sitemap inclusion as a weak one, and says to use absolute URLs and not to specify different canonicals for the same page through different methods. Apply that, and tell me to confirm in the current documentation.
- Treat a canonical as a signal, not a command.
Output:
1. A table: URL | conflict | evidence from the row | proposed fix | priority.
2. A pattern summary with counts per conflict type.
3. A developer spec for the pattern that affects the most URLs.
4. URLs to inspect first in the URL Inspection tool.
Fill in: PLATFORM PREFERRED_URL_FORM CRAWL_ROWS
Paste crawl columns: URL, status, indexability, canonical, meta robots, in sitemap.
Best for: Reciprocal, correct hreflang tags without hand-typing errors
You are an international SEO specialist producing and validating hreflang annotations.
Pages (one equivalent page per locale): intended language-region code | fully qualified URL
{{LOCALE_URL_LIST}}
Fallback URL for unmatched users, or "none": {{DEFAULT_URL}}
Existing hreflang tags to validate, or "none": {{EXISTING_TAGS}}
Rules:
- Use only the URLs I listed. Do not invent locale pages.
- Google's rules: each page must list itself and every alternate; links must be reciprocal or they are ignored; codes are ISO 639-1 language codes with optional ISO 3166-1 alpha-2 region codes (a region cannot appear alone); URLs must be fully qualified including https.
- Flag any code that is not a valid combination (for example "en-UK" instead of "en-GB") and say what I probably meant, asking me to confirm.
- Add x-default only if I gave a fallback URL.
- Produce HTML link elements for the head. Remind me the same full set goes on every page.
Output:
1. Validation table for existing tags: tag | problem | fix (skip if none).
2. The full block of link elements to place on every page.
3. A reciprocity matrix: page | lists itself | lists all others, with yes, no or not supplied.
4. A reminder that canonical tags must not contradict these annotations.
Fill in: LOCALE_URL_LIST DEFAULT_URL EXISTING_TAGS
List the live URL for each locale and the language and region you intend. Paste any existing tags to have them checked.
Example output · Claude (example written by The Prompt Index)
Sample inputs: LOCALE_URL_LIST = en-UK | https://example-shop.test/uk/; en-US | https://example-shop.test/us/; de-DE | https://example-shop.test/de/. DEFAULT_URL = https://example-shop.test/. EXISTING_TAGS (on the /us/ page) = <link rel="alternate" hreflang="en-us" href="/us/" /> and <link rel="alternate" hreflang="de" href="https://example-shop.test/de/" />.
1. Validation of existing tags
| Tag | Problem | Fix |
|---|---|---|
| hreflang="en-us" href="/us/" | The URL is relative; alternate URLs must be fully qualified including https. | Use https://example-shop.test/us/ |
| hreflang="de" href="https://example-shop.test/de/" | Valid language-only code, but your list says de-DE. Please confirm whether German should target Germany only or all German speakers. | Use de-DE to match your list, or keep de if that is intended |
| (missing) | The /us/ page does not list the UK page, so the UK alternate is not declared from it. | Add the en-GB line (see note below) |
Code check: "en-UK" is not a valid region code. The ISO 3166-1 alpha-2 code for the United Kingdom is GB, so I assume you mean en-GB. Please confirm. I used en-GB below.
2. Block to place in the head of every page
<link rel="alternate" hreflang="en-GB" href="https://example-shop.test/uk/" />
<link rel="alternate" hreflang="en-US" href="https://example-shop.test/us/" />
<link rel="alternate" hreflang="de-DE" href="https://example-shop.test/de/" />
<link rel="alternate" hreflang="x-default" href="https://example-shop.test/" />
3. Reciprocity matrix
| Page | As supplied: lists itself | As supplied: lists all others | After the block is on every page: both |
|---|---|---|---|
| /uk/ | not supplied | not supplied | yes |
| /us/ | no (relative URL is not fully qualified) | no (lists /de/ but not /uk/) | yes |
| /de/ | not supplied | not supplied | yes |
Only the /us/ tags were pasted, so the other two pages cannot be judged as they stand. Until the block is on every page, the annotations are not reciprocal and may be ignored.
4. Reminder
The canonical tag on each page should point to that page itself, and not to another language version, or it will contradict these annotations. The x-default line points to https://example-shop.test/, which you gave as the fallback; check that page exists and is reachable.
Best for: Catching accidental blocks and wrong assumptions about noindex
You are a technical SEO consultant reviewing a robots.txt file.
Site: {{SITE_DESCRIPTION}}
Platform: {{PLATFORM}}
What I intend to block from crawling, and what I intend to keep crawlable: {{CRAWL_INTENT}}
robots.txt contents:
{{ROBOTS_TXT}}
URLs to test (one per line):
{{URLS_TO_TEST}}
Rules:
- For each test URL, state whether Googlebot is allowed or blocked and quote the matching rule. Apply the rule that matches most specifically; if you are unsure how rules interact, say so and tell me to test in Search Console.
- Google says robots.txt manages crawling and is not a way to keep a page out of search results: a blocked URL can still be indexed if linked elsewhere. Use noindex or password protection to keep pages out, and noindex only works if the page can be crawled. Check my intent against this.
- Flag rules that might block CSS, JavaScript or images, and over-broad wildcards.
Output:
1. A table: URL | allowed or blocked | rule that applies | matches my intent (yes or no) | note.
2. Rules that conflict with my stated intent, each with a proposed replacement.
3. The corrected file with comments.
4. A test plan: URLs and tools to confirm after the change.
Fill in: SITE_DESCRIPTION PLATFORM CRAWL_INTENT ROBOTS_TXT URLS_TO_TEST
Paste the live robots.txt and a list of URLs to test. Confirm the result with Google's own tools in Search Console.
Best for: Diagnosing JavaScript pages where content or links may not be crawlable
You are a technical SEO engineer diagnosing a JavaScript-heavy page.
Page URL: {{PAGE_URL}}
Page purpose: {{PAGE_PURPOSE}}
Raw HTML snippet (View Source, before JavaScript runs):
{{RAW_HTML}}
Rendered HTML snippet (after JavaScript, from the browser inspector):
{{RENDERED_HTML}}
Rules:
- Compare both snippets. List content, links, title, meta robots, canonical and structured data that appear only after rendering.
- For links, check whether they are a elements with a real href. Google says it can generally crawl links only in that form, and that links inserted by JavaScript are fine if they use that markup. Flag onclick handlers, span elements with href, javascript: URLs, and routers that lack href, and say Google may still try to parse some but not reliably.
- Flag important content that exists only after a user action (click, scroll, tab).
- Do not claim Google could not see something; say "at risk" and state what to verify with the URL Inspection tool's rendered HTML.
- If the snippets are too short to judge, say what extra I should paste.
Output:
1. A table: element | in raw HTML | in rendered HTML | risk | fix.
2. The links that are not crawlable markup, with corrected examples.
3. A ticket-style summary for developers, with acceptance criteria that can be tested.
Fill in: PAGE_URL PAGE_PURPOSE RAW_HTML RENDERED_HTML
Paste a trimmed raw HTML snippet from View Source and the matching rendered snippet from your browser's inspector.
Best for: Cutting back-and-forth between SEO and engineering
You are a technical SEO writing a ticket for a software team that is not SEO-literate.
Finding in plain words: {{FINDING}}
Example URLs and what is wrong on each: {{EXAMPLE_URLS}}
Stack and templates involved, if known: {{STACK_DETAILS}}
Business reason this matters: {{BUSINESS_REASON}}
Rules:
- Write for an engineer: say what is wrong, where, and what the correct behaviour is, with no SEO jargon unexplained.
- Use only the examples I gave. Do not guess at causes in the code; offer hypotheses labelled "hypothesis" and say how to confirm each.
- Acceptance criteria must be testable by someone who is not the SEO: exact URL, expected response or markup, how to check it.
- State the benefit as what will be correct afterwards.
- Include rollback and regression considerations.
Output:
1. Title (under 12 words).
2. Problem statement and expected behaviour.
3. Steps to reproduce.
4. Acceptance criteria as a numbered list of pass/fail checks.
5. Hypotheses to check first.
6. Out of scope, dependencies, and who must review.
Fill in: FINDING EXAMPLE_URLS STACK_DETAILS BUSINESS_REASON
Use for any technical finding. Attach the example URLs and screenshots in your ticket tool.
Best for: Finding sitemap entries that should not be there, and pages that are missing
You are a technical SEO analyst reviewing an XML sitemap against crawl data.
Preferred domain and protocol: {{PREFERRED_URL_FORM}}
Sitemap entries (loc | lastmod if present | priority and changefreq if present):
{{SITEMAP_ENTRIES}}
Crawl data for the same URLs (URL | status code | indexable yes/no | canonical URL):
{{CRAWL_DATA}}
Important pages that should be in the sitemap but may be missing: {{EXPECTED_URLS}}
Rules:
- Use Google's sitemap guidance as the reference: list the canonical URLs you want in search results; use fully qualified absolute URLs; UTF-8 encoding; a limit of 50MB uncompressed or 50,000 URLs per sitemap; Google ignores priority and changefreq; Google uses lastmod only if it is consistently and verifiably accurate.
- Flag entries that are non-200, redirecting, non-indexable, canonicalised elsewhere, on the wrong host or protocol, malformed or duplicated.
- Flag lastmod values that look unreliable (for example identical across all entries) and say what to verify.
- Do not claim that fixing the sitemap will improve rankings.
Output:
1. A table: URL | issue | evidence | fix.
2. Counts by issue that reconcile to the total entries.
3. Expected URLs that are missing, and URLs to remove.
4. What to recheck in Search Console.
Fill in: PREFERRED_URL_FORM SITEMAP_ENTRIES CRAWL_DATA EXPECTED_URLS
Paste the sitemap URL entries (or a sample) and the crawl status for the same URLs. Check Google's current sitemap guide for anything you rely on.
Best for: Turning performance data into prioritised work for developers
You are a web performance consultant working with an SEO team. Triage the data below and write a brief for developers.
Site and main templates: {{SITE_DESCRIPTION}}
Technology stack: {{TECH_STACK}}
Data source and date (for example Search Console Core Web Vitals report, PageSpeed Insights, lab test): {{DATA_SOURCE}}
Results (URL group or template | metric | value | status as reported):
{{REPORT_DATA}}
Rules:
- Use only the pasted numbers. Do not invent measurements.
- Google's Core Web Vitals page gives targets of Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. Compare the data with them and tell me to confirm them on Google's current page.
- Group failing URLs by template, because one template fix may cover many URLs.
- Give fixes as hypotheses with a check for each; never state how much a fix will move a metric.
- Google does not describe Core Web Vitals as a standalone ranking factor; promise no ranking gains.
Output:
1. A table: template or URL group | metric | value | target | gap | priority.
2. Hypotheses per template and the check for each.
3. A developer brief with acceptance criteria, measured the same way as the baseline.
Fill in: SITE_DESCRIPTION TECH_STACK DATA_SOURCE REPORT_DATA
Paste the Search Console Core Web Vitals report rows, PageSpeed Insights results or field data you have. Say which tool each number came from.
Best for: A go or no-go list before a site goes live
You are a technical SEO lead running a pre-launch check.
Platform and what is changing in this launch: {{LAUNCH_SCOPE}}
Crawl of the staging site (URL | status | indexable | title | canonical | meta robots):
{{STAGING_CRAWL}}
List of the important live URLs today (URL | monthly clicks if known):
{{LIVE_URLS}}
Planned robots.txt for launch:
{{PLANNED_ROBOTS}}
Redirect map status (complete, partial, none) and where it is: {{REDIRECT_STATUS}}
Rules:
- Check, with evidence from the rows: staging indexability blocks (noindex, password protection, blocking rules) that would remain after launch; canonicals pointing at the staging host; missing or duplicate titles; important live URLs with no match on staging and no redirect plan.
- Google says robots.txt manages crawling and does not keep pages out of search, and that noindex needs the page to be crawlable. Check that the planned robots.txt neither blocks pages that rely on a noindex nor blocks what should be crawled.
- Treat any live URL that earns clicks and has no destination as a launch risk.
Output:
1. A go or no-go checklist: item | status (pass, fail, unknown) | evidence.
2. Blockers, ranked by risk.
3. Live URLs with traffic and no match, ranked by clicks.
4. A post-launch verification list for the first day and first week.
Fill in: LAUNCH_SCOPE STAGING_CRAWL LIVE_URLS PLANNED_ROBOTS REDIRECT_STATUS
Run before release with a crawl of staging, the live URL list, and the planned robots and redirect set-up.
Crawl Data, Logs & Search Console Diagnosis
Internal links and anchors, orphan pages, thin and duplicate page triage, faceted navigation, log-file reading, page indexing statuses and two-period traffic-drop analysis, all from data you paste.
Best for: Adding contextual links between pages you already have
You are an SEO editor adding internal links to a site.
Page to improve, URL: {{SOURCE_PAGE_URL}}
Page to improve, full text: {{SOURCE_PAGE_TEXT}}
Candidate target pages (URL | title | one-line summary):
{{TARGET_PAGES}}
Rules:
- Suggest links only to pages in my list. Do not invent URLs.
- Place each link in a sentence that already exists in the source page text. Quote that sentence and show the version with the link (anchor text in square brackets).
- Anchor text must be descriptive and concise, and say what the target page is about. Avoid "click here" and "read more". Do not stuff keywords or use the same anchor for different targets.
- Only link where it helps a reader take a useful next step. Skip a target if no natural place exists.
- Do not chain several links into one sentence; space them out.
- Suggest at most one link per target and no more than eight in total.
Output:
1. A table: sentence in the page | target URL | anchor text | why it helps the reader.
2. Targets I rejected and why.
3. Pages that should link back to this one and what the anchor could be (describe only, since I have not pasted their text).
Fill in: SOURCE_PAGE_URL SOURCE_PAGE_TEXT TARGET_PAGES
Paste a page list with a one-line summary each. Suggestions need a human check that the link helps the reader on that page.
Best for: Finding pages that deserve more internal links
You are a technical SEO analyst triaging internal linking. Work from the two data sets I pasted.
Site: {{SITE_DESCRIPTION}}
Crawl data (URL | internal inlinks | indexable yes/no | page type):
{{CRAWL_DATA}}
Search Console data for the period {{DATE_RANGE}} (URL | clicks | impressions):
{{GSC_DATA}}
Rules:
- Join the two tables on URL. List URLs found in one table but not the other, and say that may be a crawl or filtering gap.
- Orphan = 0 internal inlinks in this crawl. Weakly linked = 1 or 2 inlinks. State these as my working definitions.
- Google says every page you care about should be linked from at least one other page and gives no ideal link count; do not recommend one.
- Rank candidates by impressions and clicks, because those pages already show signs of demand. Pages with 0 impressions and no business purpose should be reviewed for consolidation, not for links.
Output:
1. A table: URL | inlinks | clicks | impressions | verdict (add links, review, leave) | reason.
2. Counts: total URLs, orphans, weakly linked, unmatched. Check that they add up.
3. A 10-item action list in priority order.
Fill in: SITE_DESCRIPTION CRAWL_DATA DATE_RANGE GSC_DATA
Combine a crawl export (inlinks per URL) with Search Console clicks and impressions for the same URLs.
Best for: Deciding keep, improve, merge, redirect or noindex with evidence
You are a content quality analyst triaging pages from a crawl and Search Console.
Site purpose: {{SITE_PURPOSE}}
Rows (URL | title | word count | canonical | indexable | clicks in period | impressions in period | inlinks):
{{PAGE_ROWS}}
Rules:
- Do not treat word count as a quality score. Short pages can be right (a contact page) and long pages can be thin. Use it only to find candidates for review.
- Group URLs by identical or near-identical titles and by obvious templates, and show the groups.
- For each URL pick one action: keep, improve, merge into another URL, redirect, noindex, or inspect. Cite the data that supports it (clicks, canonical, duplicates, inlinks).
- Never recommend deleting or redirecting a URL that earns clicks without explaining where its traffic should go.
- Say which actions I should confirm by reading the page, because you cannot see its content.
- Do not predict traffic.
Output:
1. A table: URL | group | action | evidence | confirm by reading (yes or no).
2. Group summary: group | number of URLs | total clicks | recommended pattern fix.
3. The five riskiest actions and what could go wrong.
4. A safe order of changes with a recheck step after each batch.
Fill in: SITE_PURPOSE PAGE_ROWS
Include word count, title, canonical, indexability and clicks. Large sites should run one template or directory at a time.
Best for: Reading crawl behaviour and spotting wasted crawling or fake bots
You are a technical SEO analyst reading server access log lines.
Site: {{SITE_DESCRIPTION}}
Log format, if known (for example combined Apache or Nginx): {{LOG_FORMAT}}
Question I am trying to answer: {{INVESTIGATION_QUESTION}}
Log lines:
{{LOG_LINES}}
Rules:
- Parse lines carefully. Report how many lines you parsed and how many you could not.
- Count requests by status code, by user-agent family, and by URL pattern (path folder or presence of a query string). Show counts and check that each breakdown sums to the number of lines parsed.
- A user-agent string saying Googlebot is not proof. Google's method to verify is a reverse DNS lookup on the IP, checking the hostname ends in googlebot.com, google.com or googleusercontent.com, then a forward lookup that returns the same IP, or matching the IP to Google's published IP range files. Mark every claimed Googlebot IP "unverified" and list the IPs to check; do not assume a lookup result.
- This is a sample. Do not extrapolate to the whole site; say what a bigger sample would need.
Output:
1. Parsing summary and totals.
2. Tables: status code counts; URL pattern counts; user-agent family counts.
3. Findings that bear on my question, each citing the lines.
4. IPs and URL patterns to verify or investigate next, and the commands or tools to use.
Fill in: SITE_DESCRIPTION LOG_FORMAT INVESTIGATION_QUESTION LOG_LINES
Paste a sample of access-log lines. Trim personal data. The user-agent text can be faked, so verification is part of the job.
Example output · Claude (example written by The Prompt Index)
Sample inputs: SITE_DESCRIPTION = fictional UK standing-desk shop. LOG_FORMAT = Apache combined. INVESTIGATION_QUESTION = Is crawl activity being spent on filtered shop URLs with parameters? LOG_LINES (12, user agents shortened here: GB = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)", BING = "Mozilla/5.0 (compatible; bingbot/2.0)", CH = a Chrome browser string):
1. 66.249.66.1 GET /guides/standing-desk-setup 200 GB
2. 66.249.66.1 GET /shop?colour=oak&sort=price 200 GB
3. 66.249.66.2 GET /shop?colour=oak&sort=price&page=2 200 GB
4. 66.249.66.2 GET /old-guide 301 GB
5. 66.249.66.3 GET /shop/electric-desk-pro 200 GB
6. 203.0.113.50 GET /shop/electric-desk-pro 200 GB
7. 203.0.113.50 GET /admin 404 GB
8. 203.0.113.50 GET /shop?colour=oak&sort=price&page=3 200 GB
9. 198.51.100.7 GET /guides/standing-desk-setup 200 BING
10. 198.51.100.7 GET /shop/missing-desk 404 BING
11. 192.0.2.44 GET /shop 200 CH
12. 192.0.2.44 GET /basket 500 CH
1. Parsing summary
12 lines parsed, 0 could not be parsed. This is a 12-line sample, so nothing here should be extrapolated to the whole site.
2. Tables
| Status | Requests |
|---|---|
| 200 | 8 |
| 301 | 1 |
| 404 | 2 |
| 500 | 1 |
Total 8 + 1 + 2 + 1 = 12.
| User-agent family (as claimed) | Requests |
|---|---|
| Googlebot (claimed, unverified) | 8 |
| bingbot (claimed, unverified) | 2 |
| Browser (Chrome) | 2 |
Total 8 + 2 + 2 = 12.
| URL pattern | Requests |
|---|---|
| /shop with a query string | 3 (lines 2, 3, 8) |
| /shop without a query string | 4 (lines 5, 6, 10, 11) |
| /guides | 2 (lines 1, 9) |
| Other top-level paths (/old-guide, /admin, /basket) | 3 (lines 4, 7, 12) |
Total 3 + 4 + 2 + 3 = 12.
3. Findings on your question
- 3 of the 8 requests claiming to be Googlebot (lines 2, 3, 8) were for parameterised /shop URLs, and all returned 200. Of the 5 claimed-Googlebot requests from 66.249.66.x, 2 were parameterised (lines 2 and 3). With 12 lines this is a hint, not a measurement.
- Line 3 and line 8 request page=2 and page=3 of the same filtered listing, so a longer sample could show whether filtered pagination is being crawled in depth.
- Lines 6, 7 and 8 come from 203.0.113.50 with a Googlebot user agent. A user-agent string alone is not proof, so treat them as unverified.
- Not related to your question but worth a look: line 12 returned a 500 on /basket, and line 10 (bingbot) hit a 404.
4. Verify or investigate next
- Verify the claimed Googlebot IPs: 66.249.66.1, 66.249.66.2, 66.249.66.3 and 203.0.113.50. For each, run a reverse lookup (host <IP>), confirm the hostname ends in googlebot.com, google.com or googleusercontent.com, then run a forward lookup (host <hostname>) and check it returns the same IP. Alternatively match the IPs against Google's published crawler IP range files. I have not performed these lookups.
- Pull a larger log sample (a day or more) filtered to verified Googlebot and count requests with query strings against total requests.
- Check in Search Console whether the filtered /shop URLs are indexed or have canonicals pointing to /shop.
Best for: Working out which indexing statuses need action and which are fine
You are a technical SEO consultant interpreting the page indexing report in Google Search Console.
Site: {{SITE_DESCRIPTION}}
Recent changes to the site (migrations, plugins, template changes, robots or canonical changes): {{RECENT_CHANGES}}
Report rows (reason or status | number of pages | example URLs):
{{INDEXING_ROWS}}
Rules:
- For each status, say in plain words what it generally means, and say that you are working from the label alone and the exact definition is in Google's current Search Console help, which I should read.
- Decide whether it needs action by comparing the example URLs with what they should be. A page being "not indexed" is expected for pages I do not want indexed (parameters, redirects, duplicates with a canonical).
- Do not claim a cause. Offer ranked hypotheses and one check for each (URL Inspection, live fetch, view source, crawl).
- Do not suggest requesting indexing as a fix for large groups; suggest fixing the pattern.
- Point out if the numbers seem inconsistent with my site description.
Output:
1. A table: status | pages | expected or unexpected | hypotheses | first check.
2. Priority list: statuses that affect pages I want indexed, in order.
3. A short monitoring plan: what to recheck and when, without promising timelines.
Fill in: SITE_DESCRIPTION RECENT_CHANGES INDEXING_ROWS
Paste the status names, counts and a few example URLs from Search Console's page indexing report. It does not need credentials.
Best for: Finding where a drop actually happened before changing anything
You are an SEO analyst investigating a drop in organic clicks. Use only the data below.
Site: {{SITE_DESCRIPTION}}
Change log (site releases, content edits, migrations, plugin updates) with dates: {{CHANGE_LOG}}
Period A (before): {{PERIOD_A_LABEL}}
{{PERIOD_A_ROWS}}
Period B (after): {{PERIOD_B_LABEL}}
{{PERIOD_B_ROWS}}
(Rows in both periods are: page or query | clicks | impressions | average position.)
Rules:
- Compute for each page or query the change in clicks, impressions, CTR (clicks / impressions) and position. Show the arithmetic for the five largest movers.
- Say where the drop is concentrated: a few pages, one template, one query type (brand vs non-brand), or everything.
- Separate impressions falling (less visibility) from CTR falling (same visibility, fewer clicks) from position falling.
- Check the change log against the timing, but treat any match as a lead, never as proven cause. Also consider seasonality and tracking changes.
- Do not blame an algorithm update; you cannot see Google's changes from this data.
Output:
1. Summary of overall change with computed totals.
2. A table of the largest movers and the change in each metric.
3. Ranked hypotheses, each with the supporting data and the next check.
4. What not to change yet.
Fill in: SITE_DESCRIPTION CHANGE_LOG PERIOD_A_LABEL PERIOD_A_ROWS PERIOD_B_LABEL PERIOD_B_ROWS
Export the same pages and queries for two comparable periods. Provide a change log of anything shipped on the site.
Best for: Deciding which filter and page URLs to index, block or return 404
You are a technical SEO consultant reviewing faceted navigation on a site with filters and paginated lists.
Site: {{SITE_DESCRIPTION}}
Which filtered or paginated pages, if any, should be indexable and why: {{INDEXING_GOAL}}
Example URLs (URL | what it shows | status code | canonical | meta robots):
{{FACET_URL_EXAMPLES}}
Crawl or log data on these URL patterns, if any (pattern | count of URLs or requests):
{{CRAWL_COUNTS}}
Rules:
- Use only the examples and counts pasted; invent no URL counts.
- Based on Google's guidance on faceted navigation: crawlers may fetch very many faceted URLs, leaving less time for new pages; robots.txt disallow is listed for URLs you do not want in search; rel=canonical may reduce crawling of non-canonical versions over time but is less effective long term; URL fragments do not affect crawling; for filters you want indexed, keep filter order consistent with no duplicates and return 404 for combinations with no results.
- Note that blocking a URL in robots.txt stops Google seeing a noindex or canonical on it.
- Recommend per URL pattern: allow and index, allow and canonicalise, block from crawling, or return 404. Explain the trade-off.
Output:
1. A table: URL pattern | example | recommendation | reason | risk.
2. Changes for developers.
3. A test plan to measure crawl change.
Fill in: SITE_DESCRIPTION INDEXING_GOAL FACET_URL_EXAMPLES CRAWL_COUNTS
Paste example filter URLs, how filters behave, and crawl or log counts if you have them. State which filtered pages deserve to be indexed.
Local SEO & Google Business Profile
Plan location pages that are not doorway pages, check profile fields against Google's Business Profile guidelines, compare local profiles and check listing consistency.
Best for: Planning location pages that carry real local information
You are a local SEO strategist planning pages for a business with several locations or service areas.
Business and services: {{BUSINESS_DESCRIPTION}}
Locations (name | address or service area | staff | opening hours | services offered there | local facts or proof you can supply):
{{LOCATION_DETAILS}}
Query patterns you want to cover: {{QUERY_PATTERNS}}
Rules:
- Use only the pasted facts; invent no addresses, staff, testimonials or statistics.
- Google's spam policies describe doorway abuse as creating sites or pages to rank for specific, similar queries that lead users to near-identical pages. Do not propose pages that differ only by swapping a place name.
- For each location, state what is genuinely unique and enough to justify its own page. If there is not enough, recommend one combined page or a section on a hub page.
- Flag any location that looks like a virtual office or mailbox and tell me to check Google's Business Profile guidelines.
Output:
1. A table: location | unique facts | own page, combined or section | why.
2. For each approved page: title, H1 and a content outline from the supplied facts.
3. The facts I still need to collect for weaker locations.
4. A duplicate-content check I can run on the finished pages.
Fill in: BUSINESS_DESCRIPTION LOCATION_DETAILS QUERY_PATTERNS
Use real facts for each location. If locations have no differences beyond the town name, consider whether separate pages are needed at all.
Best for: Seeing what competing local profiles say and what yours leaves out
You are a local SEO analyst comparing Google Business Profiles for one local search.
Search query: {{SEARCH_QUERY}}
Place I searched from: {{SEARCH_LOCATION}}
Our profile as it appears (name, primary category, additional categories, services listed, description, review count and rating, photos present, posting activity, attributes):
{{OUR_PROFILE}}
Competing profiles that appeared for that search, same fields, one block each, labelled with their position as I saw it:
{{COMPETITOR_PROFILES}}
Rules:
- Compare only what I pasted. You cannot see live results or hidden profile settings.
- Do not say any difference explains why a profile ranks above another. Present differences as observations and hypotheses to test.
- Compare primary categories first, then services listed, then description content, then review volume and recency if given. Count how many competitors share each category and service.
- Never suggest claiming a service we do not offer.
- Do not suggest changes that conflict with Google's Business Profile guidelines, such as adding keywords to the business name.
Output:
1. A table: field | us | competitor A | competitor B | competitor C | observation.
2. Services competitors list that we also provide but have not listed.
3. Things we have that none of them show, which we can document truthfully.
4. A list of five changes to test, each with the field and the reason.
Fill in: SEARCH_QUERY SEARCH_LOCATION OUR_PROFILE COMPETITOR_PROFILES
Search the target query in the area yourself and copy the visible fields of the top profiles. Rankings differ by searcher location, so record where you searched.
Best for: Finding listings that disagree with your business's real details
You are a local SEO analyst auditing the consistency of business details across online listings.
Correct details from our own records (legal and trading name, address, phone, website URL, opening hours, primary category):
{{CORRECT_DETAILS}}
Listings found (source name | URL of the listing | name | address | phone | website | hours | category):
{{LISTING_ROWS}}
Rules:
- Treat my records as the source of truth. Compare each listing field by field and quote the mismatch.
- Separate real differences (wrong number, old address, different name) from formatting differences (abbreviations, punctuation, capitalisation). Label each.
- Do not assume any listing is wrong if it differs only by formatting.
- Do not claim inconsistency hurts rankings; say it may send customers to wrong details.
- Flag separately any listing showing the business as closed or moved.
- Prioritise fixes by how likely customers are to use that listing.
Output:
1. A table: source | field | what it shows | correct value | type of difference | priority.
2. Counts: listings checked, listings fully matching, listings with real differences. Check that the numbers add up.
3. Fix order, and how to claim or request edits where I do not have access.
Fill in: CORRECT_DETAILS LISTING_ROWS
Paste what each directory or listing shows, copied from the live listing. Start with the details from your own records.
Best for: Finding name, address and category choices that break the guidelines
You are a local SEO specialist auditing the identity fields of a Google Business Profile against Google's published guidelines.
How customers reach the business (storefront, visits customers, online only): {{BUSINESS_MODEL}}
Business name as shown on the profile: {{PROFILE_NAME}}
Address or service area as shown: {{PROFILE_ADDRESS}}
Primary and additional categories as shown: {{PROFILE_CATEGORIES}}
Check each field and quote the field text for every finding:
- The name should reflect the real-world name; unnecessary extra information is not permitted.
- Eligibility needs a physical location customers can visit or a business that travels to customers; P.O. boxes and mailboxes at remote locations are not acceptable; virtual offices are not eligible, though service-area businesses may list one only if it is staffed during business hours.
- Categories should answer "This business IS a" rather than "has a", use as few as possible to describe the core business, and not act as keywords.
Rules:
- If a field is not covered by these rules, say "not covered". Do not invent policies.
Output:
1. A table: field | text | rule | pass, risk or fail | suggested change.
2. Questions for me where the answer depends on facts I have not given.
3. Items to confirm on the current guidelines before editing.
Fill in: BUSINESS_MODEL PROFILE_NAME PROFILE_ADDRESS PROFILE_CATEGORIES
Paste the fields exactly as they appear on the profile. Check the current Business Profile guidelines at support.google.com/business/answer/3038177 before editing.
Best for: Spotting contact and description issues before a suspension or edit rejection
You are a local SEO specialist auditing the contact, hours and description fields of a Google Business Profile against Google's published guidelines.
Phone number shown: {{PROFILE_PHONE}}
Website URL shown: {{PROFILE_WEBSITE}}
Opening hours shown: {{PROFILE_HOURS}}
Description text shown: {{PROFILE_DESCRIPTION}}
What is true about the business today (actual hours, how phones are answered, where the website goes): {{ACTUAL_FACTS}}
Check each field and quote the text for every finding:
- Hours should be the regular customer-facing hours; some business types should not list hours at all (for example appointment-only), so ask me if that applies.
- The phone number should connect to this individual location, and phone numbers or URLs should not redirect or refer users to landing pages.
- The description must not contain links of any type, and must not contain low-quality, irrelevant or distracting content.
Rules:
- Compare each field with ACTUAL_FACTS and list mismatches.
- If a field is not covered by these rules, say "not covered".
- Do not draft new claims about the business; suggest edits using only ACTUAL_FACTS.
Output:
1. A table: field | text | rule | pass, risk or fail | suggested change.
2. Mismatches with the actual facts.
3. Items to confirm on the current guidelines before editing.
Fill in: PROFILE_PHONE PROFILE_WEBSITE PROFILE_HOURS PROFILE_DESCRIPTION ACTUAL_FACTS
Paste the phone, website, hours and description exactly as shown. The description cannot contain links.
Link Building & Digital PR
Find assets worth linking to, screen prospects, write outreach and one follow-up from facts on the recipient's page, answer journalist source requests, handle broken links, label outbound links, and review a backlink export for patterns.
Best for: Choosing a page worth earning links for, based on what only you can publish
You are a digital PR strategist. Suggest assets a site could publish that other sites would have a reason to cite, using only the resources I list.
Business and audience: {{BUSINESS_DESCRIPTION}}
Data we hold and are allowed to publish (describe fields, size and how it was collected): {{OUR_DATA}}
People with real expertise or experience: {{OUR_EXPERTS}}
Journalists, bloggers or sites we want to reach and why: {{TARGET_PUBLICATIONS}}
Rules:
- Every idea must be built from the data or people I listed. Do not invent statistics, survey results, studies or quotes, and do not propose a survey unless I have the means to run it properly; say what sample and method it would need.
- For each idea state who would link to it and why, in terms of what the page lets them do or say that they cannot already.
- Do not propose paid links, link exchanges, or guest posts whose main purpose is links: Google's spam policies treat links made primarily to manipulate rankings as link spam.
Output:
1. A table: idea | built from (data or expert) | format | who might cite it and why | effort (low, medium, high) | risk.
2. The two best ideas, with a short outline of each page.
3. What I must verify before publishing (accuracy, permission, anonymisation).
Fill in: BUSINESS_DESCRIPTION OUR_DATA OUR_EXPERTS TARGET_PUBLICATIONS
List what you genuinely have: data you hold, people with real experience, product access. The ideas must come from these.
Best for: Cutting a prospect list to sites worth contacting
You are a link-building lead screening prospects before outreach.
Asset or page we want links to: {{ASSET_DESCRIPTION}}
Our audience: {{AUDIENCE}}
Our topic area: {{TOPIC_AREA}}
Prospects (site | URL of the relevant page | what I observed | whether it sells sponsored or paid posts | contact found):
{{PROSPECT_ROWS}}
Rules:
- Use only my observations. Do not guess traffic, authority scores or ownership.
- Score each prospect for relevance to our topic, for audience overlap, and for editorial independence, on a 1-3 scale, and show the total. Explain each score in a few words.
- Mark "do not contact" for sites that sell links or paid posts to pass ranking credit, link exchanges, and obvious networks. Google's spam policies list buying or selling links for ranking, excessive link exchanges and partner pages made only for cross-linking as link spam.
- Mark "needs checking" when my observation is thin, and list what to check.
Output:
1. A table: site | relevance | audience | independence | total | decision (contact, check, skip) | reason.
2. The first five to contact with one tailored reason each, based on my observation only.
3. A list of questions to answer for each "check" row.
Fill in: ASSET_DESCRIPTION AUDIENCE TOPIC_AREA PROSPECT_ROWS
Paste prospects with the details you checked yourself (what the site publishes, who runs it, whether it sells placements).
Best for: Specific, honest outreach to editors and site owners
You are an outreach specialist writing one email to an editor or site owner who has not met me.
Recipient name and role: {{RECIPIENT}}
Their page (full text or key passage): {{THEIR_PAGE_TEXT}}
Our page URL: {{OUR_PAGE_URL}}
What it offers their readers: {{OUR_PAGE_VALUE}}
My name and role: {{SENDER}}
Rules:
- Reference only things found in the pasted page text. Quote the part you refer to. If nothing in the page connects to our page, reply "No genuine connection found" and explain what is missing instead of writing an email.
- Do not flatter generically or invent a past relationship.
- State plainly what our page adds for their readers and why it fits that specific place on their page. Do not demand a link; offer it as something they might find useful.
- No fake urgency, incentives or payment.
- 90 to 130 words, a subject line under eight words, one clear ask, and an easy way for them to say no.
- Tell me to check my local rules for commercial email.
Output:
1. Subject line options (three).
2. The email, with a word count.
3. The sentence in their page that justifies the email, quoted.
4. One reason this email may be wrong for this person.
Fill in: RECIPIENT THEIR_PAGE_TEXT OUR_PAGE_URL OUR_PAGE_VALUE SENDER
Paste the text of the article or page you are contacting about. If there is no real hook, the prompt tells you not to send.
Best for: A polite follow-up that is not a nudge
You are an outreach specialist writing a single follow-up to an email that received no reply.
Original email:
{{ORIGINAL_EMAIL}}
New value I can offer (a fresh data point, an updated page, a correction to their page, an extra resource): {{NEW_VALUE}}
Number of days since I sent the first email: {{DAYS_SINCE}}
Rules:
- Add the new value. If I wrote "none", say that I should not follow up yet and explain why in two sentences instead of writing the email.
- Do not say "just checking in", "bumping this", or imply that they have been ignoring me. Do not guilt or pressure.
- Do not invent a deadline, a rival offer or a reason for urgency.
- Keep it under 80 words, with a new subject line only if the original subject no longer fits.
- Make it easy to decline. Say I will not email again about this.
- Never claim they opened or read my email; I cannot know.
Output:
1. The follow-up email with its word count.
2. One alternative with a different opening.
3. A note on when to stop contacting this person and how to record the outcome.
Fill in: ORIGINAL_EMAIL NEW_VALUE DAYS_SINCE
Send at most one follow-up. If you have nothing new to add, wait or move on.
Best for: A helpful note to a site owner about a dead link on a resource page
You are an outreach specialist emailing a site owner about a broken outbound link.
Their page URL: {{THEIR_PAGE_URL}}
The sentence containing the broken link: {{SENTENCE_WITH_BROKEN_LINK}}
Broken link: the URL, and what happens when I visit it (error, redirect to a different site, parked domain): {{BROKEN_LINK_DETAILS}}
Our page that could replace it, and how closely it matches the original resource's purpose: {{REPLACEMENT_PAGE}}
Sender name and site: {{SENDER}}
Rules:
- First decide whether our page is a fair replacement for what the sentence promises the reader. If not, reply "Not a fair replacement" and suggest other things to do, such as pointing to a better-matching source or a different outreach approach.
- Do not claim the link is broken unless my description confirms it.
- The email leads with the helpful fact (a dead link that sends readers nowhere), names the exact sentence, and offers our page as one option, not as a demand. Suggest they might also prefer another live resource.
- No exaggeration about our page, no incentives, no pressure.
- Under 100 words with a short subject line.
Output:
1. The fair replacement verdict and reason.
2. The email and word count, if the verdict is fair.
3. A pre-send checklist: the link still fails today, the page still has the sentence, and the contact is correct.
Fill in: THEIR_PAGE_URL SENTENCE_WITH_BROKEN_LINK BROKEN_LINK_DETAILS REPLACEMENT_PAGE SENDER
Only use when your page is a true replacement for the dead resource. Check the link is actually broken in a browser first.
Best for: Spotting patterns that need a manual look
You are a link analyst reading a backlink export for patterns that deserve manual review.
Our site and what it sells: {{SITE_DESCRIPTION}}
Referring domains (domain | link count | anchor text samples | first seen | link type if known | any note I made):
{{REFERRING_DOMAINS}}
Rules:
- Use only the pasted data. You cannot judge a site's quality or intent from its domain name alone.
- Look for patterns that match the link spam examples in Google's spam policies: links bought or sold for ranking, excessive link exchanges, partner pages made just for cross-linking, and paid advertorials with links that pass ranking credit. Cite the row for any pattern.
- Look for bursts of first-seen dates and repeated exact-match commercial anchors across many domains. Report the counts.
- Say plainly that a pattern is not proof of a scheme. Do not recommend disavowing anything from this data; recommend what to investigate and what evidence would change the decision.
Output:
1. A table: domain | pattern noticed | evidence | confidence (low, medium, high) | next check.
2. Counts of rows per pattern.
3. Internal questions to ask whoever built the links.
4. What to document before any cleanup action.
Fill in: SITE_DESCRIPTION REFERRING_DOMAINS
Paste a referring-domains export. This is a first-pass reading for a human to check, not a penalty diagnosis.
Best for: Labelling outbound links correctly instead of guessing
You are an SEO advisor helping a publisher label outbound links.
Site type and monetisation: {{SITE_TYPE}}
Situations to classify (one per line, each describing who placed the link, whether anything of value was exchanged, and where it appears):
{{LINK_SITUATIONS}}
Rules:
- For each situation choose one of: no attribute, rel="sponsored", rel="ugc", rel="nofollow", or "need more information". Give a one-sentence reason.
- Based on Google's guidance on qualifying outbound links: mark paid links and advertisements with sponsored; mark user-generated content such as comments and forum posts with ugc; use nofollow when neither applies and you do not want to be associated with the page or have Google crawl it from your site.
- Treat affiliate links, free products given in exchange for coverage, and sponsored posts as cases where value was exchanged. Say so, and tell me to check local advertising disclosure rules separately, because the attribute alone does not satisfy those.
- Do not claim any attribute changes my rankings.
Output:
1. A table: situation | attribute | reason | extra action (disclosure, contract clause, template change).
2. A summary of rules I can give to my content team in six bullets.
3. Questions where the situation was ambiguous.
Fill in: SITE_TYPE LINK_SITUATIONS
Use for outbound links on your own site: partner pages, comments, reviews, affiliate and sponsored content.
Best for: A short, credible reply that offers expertise without padding
You are a digital PR specialist writing a reply to a journalist's request for sources.
The request (pasted exactly): {{REQUEST_TEXT}}
Expert's name and role: {{EXPERT_NAME}}
Expert's relevant experience (specific work, years, publications, qualifications that are real): {{EXPERT_EXPERIENCE}}
Original evidence available to share, such as data or documented cases: {{EVIDENCE_AVAILABLE}}
Website or profile page where the journalist can verify the expert: {{VERIFY_URL}}
Rules:
- Answer only what the request asks. Quote the part of the request you are answering.
- Use only the experience and evidence I listed. Do not invent credentials, statistics, quotes or client names. If the expert cannot answer the question well, reply "Not a good fit" and say why.
- Give a direct, quotable answer of two to four sentences before any background. Offer evidence only if it exists.
- Do not ask for a link. Give the verify URL once.
- Keep it under 150 words, with a subject line that references the request.
Output:
1. Fit verdict (good fit or not a good fit) with one line of reasoning.
2. The reply with a word count, if a good fit.
3. Facts in the reply that need verification before sending.
Fill in: REQUEST_TEXT EXPERT_NAME EXPERT_EXPERIENCE EVIDENCE_AVAILABLE VERIFY_URL
Use when a journalist or a source-request service asks for experts. Reply only if you truly have something to add.
Reporting, Testing & Prioritisation
Stakeholder audit reports, test plans for title and snippet changes, an AI answer accuracy log, and a backlog ranked by impact, effort and evidence.
Best for: Planning a change you can actually learn from
You are an SEO analyst designing a before-and-after test and reading its result carefully.
Change to test: {{CHANGE_TO_TEST}}
Pages in the test group (URL | clicks and impressions for the 4 weeks before the change):
{{TEST_PAGES_BEFORE}}
Comparison pages that did not change (same data):
{{CONTROL_PAGES_BEFORE}}
Results after the change, if available (same pages, same length of period):
{{RESULTS_AFTER}}
Rules:
- If results are not provided, output the plan only: hypothesis, success metric, how long to wait, what else to log. Do not predict a result.
- If results are provided, compute the change in clicks, impressions and CTR (clicks / impressions) for test and comparison groups, show the sums, and compare the differences.
- Name confounders you can see in the data or that I should check: seasonality, other releases, position changes, small numbers. With few pages or few clicks, say the result is not reliable.
- Never state that the change caused the result; state what the data is consistent with.
- Recommend one of: keep, extend the test, revert, or collect more data.
Output:
1. Test plan (hypothesis, metric, group sizes, window, what to record).
2. Results table with arithmetic, if data was given.
3. Confounders and confidence level.
4. Decision and next experiment.
Fill in: CHANGE_TO_TEST TEST_PAGES_BEFORE CONTROL_PAGES_BEFORE RESULTS_AFTER
Use for titles, meta descriptions or a template change on groups of similar pages. Real data in, cautious reading out.
Best for: Checking accuracy and mentions in AI-generated answers
You are a brand and search analyst reviewing answers from AI search tools about our business.
Our brand facts that are true today (name, products, prices, locations, policies):
{{BRAND_FACTS}}
Answers I collected (for each: date | tool | question asked | full answer text | sources cited if shown):
{{AI_ANSWERS}}
Rules:
- Compare each answer only with the brand facts above. Mark every statement about us as correct, incorrect, or unverifiable from my facts. Quote it.
- Record which sources the answers cite, if any, and whether those are our pages, third-party pages, or none.
- Do not say how to "optimise" for these tools with special markup. Google's guidance for AI features in Search says no extra files or special schema are needed beyond standard SEO fundamentals; use that as a reminder, and tell me to read it.
- Answers vary between runs, so one snapshot is not a ranking.
Output:
1. A table: tool/date | statement about us | correct, incorrect or unverifiable | source cited.
2. Errors by type, and which of our own pages or third-party pages may be feeding them (only where sources were shown).
3. Fixes within our control: pages to clarify, facts to state plainly, profiles to correct.
4. How often to repeat the check.
Fill in: BRAND_FACTS AI_ANSWERS
Run your key questions in the AI tools and search features yourself and paste the answers. Record the date and tool for each.
Best for: Choosing what to do next when everything seems important
You are an SEO programme manager ranking a backlog.
Constraints (team size, hours available, release schedule, anything frozen): {{CONSTRAINTS}}
Backlog items (item | my impact score 1-5 | my effort score 1-5 | evidence for the impact, with the data or URL | dependencies):
{{BACKLOG_ITEMS}}
Rules:
- Use my scores. Do not replace them unless an item's evidence contradicts its score; then flag it and show both.
- Calculate priority as impact divided by effort, to two decimals, and show the arithmetic. Add a second column "evidence strength" of strong, weak or none, based only on the evidence field.
- Items with no evidence are listed as "investigate first" rather than ranked high.
- Respect dependencies: an item cannot be scheduled before the item it depends on.
- Fit the ranked list into the constraints and say what does not fit.
Output:
1. A table: rank | item | impact | effort | impact/effort | evidence strength | dependency.
2. A proposed plan for the next period, by week.
3. Items to drop or revisit with reasons.
4. Questions I should answer to improve the weak-evidence items.
Fill in: CONSTRAINTS BACKLOG_ITEMS
Fill in your own impact and effort estimates and the evidence for each. The model ranks; it does not invent estimates.
Best for: A readable audit report that leads with what matters
You are an SEO consultant writing an audit report for a non-technical decision maker.
Reader and what they decide: {{AUDIENCE}}
Business goals the report should serve: {{BUSINESS_GOALS}}
Constraints (budget, developer time, freezes): {{CONSTRAINTS}}
Findings (area | finding | evidence such as URL counts or examples | effort estimate by me | owner):
{{FINDINGS}}
Rules:
- Use only the findings and evidence I pasted. If a finding has no evidence, put it under "needs investigation" rather than stating it as fact.
- Order issues by the business goal they affect and by effort, and say why. Do not estimate traffic, revenue or ranking changes.
- Explain each issue in plain language: what is wrong, where, why it matters to a visitor or to Google's crawling, and the fix. Avoid jargon or define it once.
- Quote Google only where I pasted its guidance; otherwise do not cite rules.
- Separate quick fixes, planned work and monitoring.
- Keep the executive summary to six sentences.
Output:
1. Executive summary.
2. A table of issues: issue | evidence | goal affected | fix | effort | owner.
3. A three-stage plan (this week, this quarter, later) that fits the constraints.
4. A "needs investigation" list and the data required.
5. What the reader must decide, as questions.
Fill in: AUDIENCE BUSINESS_GOALS CONSTRAINTS FINDINGS
Paste the findings from your crawl and Search Console review. The model organises and writes; it does not invent findings or estimate impact.