# seo-mcp — full catalogue > SEO tips, indexed from the people practising it. ## [Fix soft 404 pages properly](https://seo-mcp.io/t/fix-soft-404-pages-properly) A soft 404 returns HTTP 200 while showing missing-content copy. Google keeps it indexed and wastes crawl budget on empty templates. Find these URLs in the Page indexing report, then make missing content return a real 404 or 410 and keep 200 only for pages with genuine value. Prerequisites: - Site verified in Search Console - Access to the server or framework error handling 1. Sample soft 404s from Search Console: Open the Page indexing report, filter by 'Soft 404' and export a sample. Group URLs by template: product, post, profile or search results. (Check: The exported list contains at least one URL per template that renders a missing-content state.) 2. Return 404 or 410 from the router: When the data lookup fails, set the response status to 404 or 410 before rendering. In frameworks this is usually an explicit not-found helper, not a redirect. (Check: curl -sI your production domain/missing-page returns HTTP/1.1 404 or 410, not 200.) 3. Keep meaningful empty states at 200 *(general best practice)*: Search result pages with no matches, empty cart states and filtered categories with zero products should stay 200 when they explain the state and offer navigation. (Check: An empty search state returns 200 and contains a link back to the category root.) --- ## [Return correct status codes for removed pages](https://seo-mcp.io/t/return-correct-status-codes-for-removed-pages) Status codes are the first thing a crawler reads. Use 404 for URLs that never existed or may return, 410 for content removed for good, and 301 only when a real replacement exists. Check the status at the edge, because CDNs and rewrites routinely turn a correct framework 404 into a 200. Prerequisites: - A list of removed or retired URLs 1. Classify each removed URL *(general best practice)*: For every retired URL decide one of three outcomes: 301 to a genuine replacement, 410 for permanent removal, 404 for unknown or temporary absence. (Check: Every URL in the removal list has exactly one assigned outcome in the migration sheet.) 2. Implement status at the routing layer: Set the status in the server response, not in a client-side redirect. Remove catch-all rewrites that send unknown paths to the homepage. (Check: curl -sI your production domain/retired-page returns 410 with no Location header.) 3. Sweep the edge for rewrites *(general best practice)*: Check CDN and host rules for SPA fallbacks or 'always 200' behavior. Compare origin and edge responses for two known-missing URLs. (Check: Edge and origin return the same status code for the sampled missing URLs.) --- ## [Write a crawlable robots.txt](https://seo-mcp.io/t/write-a-crawlable-robots-txt) robots.txt controls crawling, not indexing. Serve one file per host at the root with a 200 status and a sitemap reference, allow CSS and JavaScript so rendering matches users, and block only infinite or private URL spaces. A single Disallow: / line can remove the entire site from search. Prerequisites: - Control over the domain root 1. Serve one valid file at the root: Return robots.txt from https://your-host/robots.txt with status 200 and content-type text/plain. Do not redirect it and do not serve a cached HTML error page. (Check: curl -sI your production domain/robots.txt returns 200 and content-type text/plain.) 2. Allow rendering resources and reference the sitemap: Do not disallow CSS, JavaScript or image files needed to render pages. Add a Sitemap line with an absolute HTTPS URL near the top of the file. (Check: robots.txt contains a Sitemap: line whose URL returns 200.) 3. Block only infinite or private spaces *(general best practice)*: Disallow crawl paths that generate unlimited URLs, such as internal search or sort parameters. Never ship Disallow: / outside a staging environment. (Check: grep -c '^Disallow: /$' robots.txt returns 0 in production.) --- ## [Add sitemap.xml with accurate lastmod](https://seo-mcp.io/t/add-sitemap-xml-with-accurate-lastmod) An XML sitemap lists canonical, indexable URLs so crawlers discover them without following every link. Build it from the content store, use absolute URLs that match the page canonical, and set lastmod only when content meaningfully changed. Split large sites into child sitemaps under an index. Prerequisites: - A content source with canonical URLs and updated timestamps 1. Generate from canonical content records: Emit one entry per published, indexable URL. Exclude drafts, noindexed pages, redirects, tag archives and parameter variants. Use absolute HTTPS URLs. (Check: Every loc in the sitemap returns 200 and no loc appears twice.) 2. Set lastmod honestly: Write the timestamp of the last content change, not the deploy time. Bulk template changes should not touch every lastmod value. (Check: Sample ten URLs: each lastmod matches the visible last-updated date within one day.) 3. Split and reference the file: Create a sitemap index when any child would exceed 50,000 URLs or 50 MB. Add the index URL to robots.txt and submit it in Search Console. (Check: The sitemap index returns 200, lists every child, and appears in the Search Console Sitemaps report.) --- ## [Fix redirect chains and loops](https://seo-mcp.io/t/fix-redirect-chains-and-loops) A redirect chain adds latency and leaks crawl signals. Point each legacy URL directly at the final destination, use 301 or 308 for permanent moves, and keep the map in source control. Audit with curl -IL and update internal links so chains stop growing. Prerequisites: - Access to redirect configuration or middleware 1. Map the current chains *(general best practice)*: Run curl -IL on a sample of legacy URLs and record each Location header. A chain is present when more than one 3xx appears before the 200. (Check: The audit output contains the full hop list for every sampled legacy URL.) 2. Rewrite rules to point at the final target: Replace intermediate hops with a direct rule to the final URL. Use 301 or 308 for permanent moves. Exclude destination paths from broad pattern rules to prevent loops. (Check: curl -IL your production domain/legacy-url shows exactly one 301 or 308 followed by 200.) 3. Update internal links to the destination *(general best practice)*: Find internal links that still point at redirected URLs and update the href to the final target. This prevents the chain from reappearing after the next edit. (Check: A site crawl reports zero internal links whose target returns a 3xx.) --- ## [Canonicalize duplicate URLs](https://seo-mcp.io/t/canonicalize-duplicate-urls) Duplicate URLs split signals across protocol, host, slash and parameter variants. Pick one canonical form, emit one absolute self-referencing canonical per page, and align internal links, sitemap entries, hreflang and og:url with it. Use redirects when the duplicate should not exist at all. Prerequisites: - A crawl of the site to enumerate URL variants 1. Choose the canonical URL policy: Decide protocol, host, trailing slash and parameter handling once, then apply it to routing, canonicals and links. Lowercase paths and strip tracking parameters. (Check: A redirect map exists for every variant that will not be canonical, such as http to https and apex to www.) 2. Emit one absolute self-referencing canonical: Add a single link rel=canonical in the head of each indexable page, pointing at its own canonical URL. Remove plugin or component duplicates that emit a second value. (Check: curl -s your production domain/page | grep -c 'rel="canonical"' returns exactly 1.) 3. Align every other signal: Update sitemap loc values, internal links, og:url and hreflang entries to the same canonical URL. A canonical that contradicts the sitemap sends mixed signals. (Check: For ten sampled pages, canonical, sitemap loc and og:url are identical strings.) --- ## [Handle faceted navigation with canonicals](https://seo-mcp.io/t/handle-faceted-navigation-with-canonicals) Facets multiply URLs into thousands of near-duplicates. Decide which combinations deserve indexing, give those unique titles and copy with self-canonicals, and canonicalize the remainder to the closest indexable parent. Block infinite parameter spaces and monitor crawl stats for facet-heavy URLs. Prerequisites: - A crawl of filtered URLs - Access to filter link rendering 1. Inventory facet combinations *(general best practice)*: List every facet and its parameters, then crawl the site to see how many unique URLs the navigation creates. Group them by template. (Check: The crawl lists at least one URL per facet combination and the total count per template.) 2. Classify indexable combinations: Keep combinations with search demand and unique inventory. Give each an indexable landing page with its own title and copy, and canonicalize it to itself. (Check: Each approved facet URL returns 200 with a self-referencing canonical and a unique title.) 3. Canonicalize and block the rest: Point remaining combinations to the closest indexable parent with a single canonical, and disallow infinite parameter spaces in robots.txt. Remove links to empty results. (Check: Sampled non-indexable facet URLs canonicalize to the parent and return 200; robots.txt disallows the infinite parameter pattern.) --- ## [Fix crawl traps in filters and calendars](https://seo-mcp.io/t/fix-crawl-traps-in-filters-and-calendars) Crawl traps are infinite URL spaces: calendars, sort combinations, session IDs and pagination that never ends. They starve real pages of discovery. Find them in Crawl stats, fix the link graph first, return 404 for out-of-range parameters, and block only the truly infinite spaces. Prerequisites: - Crawl stats access - Server logs or a crawler 1. Find trap patterns in Crawl stats: Group crawl requests by URL pattern and response. A trap shows thousands of requests with few unique pages and mostly 200 or soft 404 responses. (Check: Crawl stats shows at least one pattern with more than 90% of requests returning the same thin template.) 2. Remove the links that create the space *(general best practice)*: Stop linking to empty filter results, future calendar dates and out-of-range pagination. Render those interactions without crawlable href values. (Check: The rendered HTML for an empty filter result contains no anchor pointing to further empty combinations.) 3. Return 404 and block only truly infinite spaces: Return 404 for out-of-range parameters, and add robots.txt rules for parameter patterns that can never produce unique content. Keep indexable pages crawlable. (Check: curl -sI your production domain/search?page=999 returns 404, and robots.txt disallows the parameter pattern.) --- ## [Fix internal links to 404 pages](https://seo-mcp.io/t/fix-internal-links-to-404-pages) Internal links to 404 pages waste crawl budget and strand visitors. Crawl the site, list every target that returns 404 or 410, and trace the linking pages. Then either update the link to a live URL or add a redirect when a real replacement exists. Re-crawl to confirm zero broken internal links. Prerequisites: - A crawler that reports response codes - Access to templates and CMS content 1. Crawl and group broken targets *(general best practice)*: Run a crawl that reports internal links with 4xx targets. Sort by the number of linking pages and by the traffic the source pages receive. (Check: The crawl export lists each 4xx target URL with its count of internal referrers.) 2. Update links at the source *(general best practice)*: Change hrefs in templates, navigation and CMS fields to the correct live URL. Use a redirect only when the original content moved and the new URL is clearly equivalent. (Check: The source template no longer contains the broken path, confirmed by grep in the repository.) 3. Re-crawl and automate the check *(general best practice)*: Re-run the crawl after deploying and add a broken-link step to CI. Keep a baseline so new 4xx links fail the check. (Check: The post-deploy crawl reports zero internal links to 4xx URLs.) --- ## [Make JavaScript content crawlable](https://seo-mcp.io/t/make-javascript-content-crawlable) Google renders JavaScript, but rendering costs time and AI retrieval systems often read raw HTML. Server-render primary content, keep titles and links in the initial response, and avoid gating content behind interactions. Verify by curling the URL and by loading it with JavaScript disabled. Prerequisites: - Access to the application rendering model 1. Check what the first response contains: Run curl on a content URL and search for the main heading, body text and primary links. An empty shell with only script tags confirms client-only rendering. (Check: curl -s your production domain/page contains the page H1 text without executing JavaScript.) 2. Move content to the server: Render content routes with SSG or SSR. Keep metadata in the server response. Hydrate only interactive parts, and pass server data as props. (Check: The rendered response contains the full article body and navigation anchors.) 3. Verify rendering with URL Inspection: Inspect the URL and open the rendered HTML panel. Confirm the content is present and no resources are blocked. (Check: URL Inspection's rendered HTML contains the same H1 and body text as the browser view.) --- ## [Add html lang attribute](https://seo-mcp.io/t/add-html-lang-attribute) The lang attribute on the html element tells browsers and assistive technology which language the page uses. Set it per locale, keep it accurate when content mixes languages, and make it match your hreflang values. A missing or wrong value breaks pronunciation, translation prompts and locale signals. Prerequisites: - Access to the root layout or template 1. Set lang in the root layout: Add lang to the html element with the locale of the page, not of the browser. Use the same tag format as your hreflang values. (Check: curl -s your production domain/ | grep -o ']*lang="[^"]*"' returns a valid BCP 47 tag.) 2. Handle mixed-language passages *(general best practice)*: Wrap quotes or excerpts in another language with their own lang attribute. Do not change the document language for a single paragraph. (Check: A page with a foreign quote contains a nested element with a different lang value.) 3. Align with hreflang and visible language: Check that the lang value, the hreflang entry for the page and the visible content language agree on every locale template. (Check: For each locale, the html lang, hreflang value and page copy all use the same language code.) --- ## [Fix mixed content on HTTPS pages](https://seo-mcp.io/t/fix-mixed-content-on-https-pages) Mixed content is any http:// resource loaded by an https:// page. Browsers block active mixed content such as scripts and styles, and warn or auto-upgrade passive images. Find it in the console and in crawl output, then serve every subresource over HTTPS, including third-party embeds. Prerequisites: - HTTPS enabled on the site 1. Collect blocked URLs from the console: Load each key template with DevTools open and copy every Mixed Content message. Also grep the rendered HTML for src="http:// and href="http://. (Check: The list of insecure subresource URLs is recorded with the page where each appears.) 2. Switch resources to HTTPS: Update templates, CMS settings and third-party snippets to https:// URLs. Replace providers that cannot serve TLS, or proxy them through your own HTTPS origin. (Check: The rendered HTML contains no http:// subresource URLs on sampled templates.) 3. Add a regression guard *(general best practice)*: Deploy a Content-Security-Policy in report-only mode with upgrade-insecure-requests, and review reports for new insecure resources after each release. (Check: CSP reports show no blocked mixed-content requests after the next deploy.) --- ## [Serve security headers](https://seo-mcp.io/t/serve-security-headers) Security headers reduce injection, clickjacking and downgrade risk. Send HSTS with a long max-age, a Content-Security-Policy in report-only mode first, X-Content-Type-Options nosniff, a Referrer-Policy and frame-ancestors. Verify with curl headers on the production host before you enforce the policy. Prerequisites: - HTTPS on all hosts - Access to edge or server configuration 1. Record current headers: Run curl -sI on the homepage, a content page and a 404. Record which security headers are present and their values. (Check: The audit lists header presence per response, including the 404 page.) 2. Deploy headers at the edge: Add HSTS, nosniff, Referrer-Policy and a report-only CSP covering frame-ancestors and upgrade-insecure-requests. Apply them to all responses. (Check: curl -sI shows strict-transport-security, x-content-type-options and content-security-policy-report-only.) 3. Enforce after the reports are clean *(general best practice)*: Review CSP reports, fix legitimate violations, then switch from report-only to enforcing. Raise HSTS max-age once confirmed stable. (Check: The enforced CSP blocks no functional script, and HSTS max-age is at least one year.) --- ## [Add a meta viewport tag](https://seo-mcp.io/t/add-a-meta-viewport-tag) The viewport meta tag tells mobile browsers to use the device width. Without it, pages render at a virtual desktop width and text becomes unreadable. Add width=device-width, initial-scale=1, do not disable zoom, and verify the tag is in the server response. Prerequisites: - Access to the root layout or head template 1. Add the tag to the root layout: Insert a meta name=viewport tag with width=device-width, initial-scale=1 in the head. Remove any maximum-scale or user-scalable restrictions. (Check: The layout source contains the viewport meta tag and no user-scalable=no.) 2. Confirm it ships in the response: Fetch production HTML and search the head. Frameworks that inject head tags client-side will fail this check. (Check: curl -s your production domain/ | grep -c 'name="viewport"' returns 1.) 3. Check the mobile rendering *(general best practice)*: Open the page at a 390-pixel viewport and confirm text is readable without zooming and no horizontal scroll appears. (Check: document.documentElement.scrollWidth is less than or equal to 390 at a 390-pixel viewport.) --- ## [Write unique title tags](https://seo-mcp.io/t/write-unique-title-tags) The title element is the main input for the search result link, and Google rewrites vague or duplicated titles. Write one unique title per page, aim for 50 to 60 characters, front-load the distinguishing phrase and keep the brand short at the end. Audit duplicates before adding keywords. Prerequisites: - A crawl or sitemap list of indexable URLs 1. Export and deduplicate titles *(general best practice)*: Crawl the site and export URL, title and title length. Flag duplicates, missing titles and titles over 60 characters. (Check: The export contains one row per indexable URL with a duplicate flag column.) 2. Rewrite the flagged titles: Give each page a specific title that states the topic and the distinguishing detail. Move the brand to the end, and remove repeated boilerplate. (Check: No two indexable URLs share a title and each is between 20 and 60 characters.) 3. Watch for rewrites: After two weeks, compare the title shown in search results with the source title for the rewritten pages. (Check: The Title links report or a site: query shows the source title, not a generated rewrite.) --- ## [Write meta descriptions that earn clicks](https://seo-mcp.io/t/write-meta-descriptions-that-earn-clicks) Meta descriptions do not rank pages but influence click-through. Write 120 to 160 characters that state what the page delivers, use the searcher's phrasing and include a concrete detail. Keep them unique, avoid quotes that truncate, and rewrite the pages with high impressions and low CTR first. Prerequisites: - Search Console Performance data - CMS or template control of meta descriptions 1. Find high-impression low-CTR pages: In the Performance report, filter pages with impressions above your median and click-through below the site average. Export the top 20. (Check: The export lists at least 20 URLs with impressions, CTR and current description.) 2. Rewrite with a specific promise *(general best practice)*: Replace generic copy with what the page delivers, who it is for and one concrete detail. Keep the length between 120 and 160 characters. (Check: Each rewritten description is unique and within the length range.) 3. Measure the change *(general best practice)*: Compare CTR for the rewritten URLs over four weeks against the previous period at similar positions. (Check: Median CTR for rewritten URLs improves while average position stays within one position.) --- ## [Use exactly one H1 per page](https://seo-mcp.io/t/use-exactly-one-h1-per-page) Each page needs one H1 that names its topic. Multiple H1s usually come from logos or reused components that each include a heading. Audit rendered HTML, keep the H1 visible and near the main content, and let H2 and H3 carry the subsections. One H1 is a structure fix, not a ranking trick. Prerequisites: - A crawl of rendered HTML 1. Count H1s in rendered HTML *(general best practice)*: Crawl the site and count h1 elements per URL. Flag pages with zero or more than one, and identify the component that emits the extra heading. (Check: The crawl report lists H1 count per URL and the offending template for each anomaly.) 2. Make the page title the only H1 *(general best practice)*: Change reused components to accept a heading level, and change logo wrappers to a div. Keep the H1 visible and place it before the main content sections. (Check: The rendered HTML contains exactly one h1 element containing the page topic.) 3. Check the outline *(general best practice)*: Review the heading outline with an accessibility tool. Sections should start at H2, with H3 only inside an H2 section. (Check: The outline has one H1 and no skipped levels.) --- ## [Structure headings as H1, H2 and H3](https://seo-mcp.io/t/structure-headings-as-h1-h2-and-h3) Headings describe document structure for readers, assistive technology and extraction tools. Use one H1, H2 for main sections and H3 for subsections without skipping levels. Style with classes rather than heading tags, and make each heading a specific statement instead of a generic label. Prerequisites: - Access to content templates and the CMS editor 1. Audit the outline *(general best practice)*: Extract headings in document order for five key pages. Check for one H1, sequential levels and headings that describe the section rather than repeat the title. (Check: Each audited page has one H1 and no skipped heading levels.) 2. Rewrite generic headings *(general best practice)*: Replace labels such as Overview or More info with statements that name the section's subject. Keep them under about 60 characters. (Check: Each rewritten heading names the section subject without the words overview or more info.) 3. Replace style-based heading usage *(general best practice)*: Convert decorative headings in cards and footers to styled paragraphs, and move font-size rules from h1-h6 selectors to utility classes. (Check: No heading element appears inside a card or footer component.) --- ## [Fix orphan pages with internal links](https://seo-mcp.io/t/fix-orphan-pages-with-internal-links) Orphan pages have no internal links, so crawlers find them late or never. Compare a crawl's URL set with the sitemap and analytics landing pages. Link orphans from related content, category pages or a hub, and keep the sitemap as a discovery aid rather than the only path. Prerequisites: - A full site crawl - Analytics landing page export 1. Diff crawl against sitemap *(general best practice)*: Crawl the site from the homepage and export all discovered URLs. Compare with sitemap URLs and analytics landing pages to find pages with no internal referrer. (Check: The diff lists URLs present in the sitemap but absent from the crawl, with their analytics sessions.) 2. Link from relevant pages *(general best practice)*: Add contextual links from related articles, category pages or a hub. Use descriptive anchors that match the orphan's topic. (Check: Each targeted orphan has at least one internal link from a page in the same topic cluster.) 3. Confirm discovery: Re-crawl and check that the orphan is now reachable from the homepage within three clicks. (Check: The re-crawl includes the orphan with a click depth of three or less.) --- ## [Add OG and Twitter cards](https://seo-mcp.io/t/add-og-and-twitter-cards) Open Graph and Twitter card tags control how links render in feeds, chats and some assistants. Set og:title, og:description, og:url, og:type and an absolute og:image, plus twitter:card and matching fields. Generate them per page and make og:url equal the canonical. Prerequisites: - Access to the head template - A social preview image per page or template 1. Add the core Open Graph fields: Emit og:title, og:description, og:url, og:type and og:image as absolute URLs. Remove duplicate tags from other plugins or components. (Check: The rendered head contains exactly one of each og tag and og:url equals the canonical.) 2. Add Twitter card fields: Add twitter:card=summary_large_image plus twitter:title, twitter:description and twitter:image. Keep values consistent with the Open Graph fields. (Check: The head contains the twitter:card tag and an absolute twitter:image URL.) 3. Validate a preview *(general best practice)*: Run a link preview debugger for one article, one product and the homepage. Check the image dimensions and that the crop keeps essential text visible. (Check: The preview shows the intended title, description and image for all three URL types.) --- ## [Add alt text to images](https://seo-mcp.io/t/add-alt-text-to-images) Alt text describes an image for people who cannot see it and for crawlers that cannot read pixels. Write what the image shows in context, keep it under about 125 characters, and use an empty alt for decorative images. Make alt text a required field on upload. Prerequisites: - A crawl of rendered images - Access to the CMS image fields 1. List images without alt text *(general best practice)*: Crawl the site and export every img element with its src, alt value and page. Separate missing alt from empty alt, because decorative images should be empty. (Check: The export distinguishes images with no alt attribute from those with alt="".) 2. Write contextual descriptions: Describe each informative image in one sentence, including the detail that matters on that page. Keep decorative images empty and avoid duplicating adjacent captions. (Check: Sampled informative images have unique alt text that is not a filename or keyword list.) 3. Require alt text on upload *(general best practice)*: Make the CMS field required, or validate in the build that informative images have alt text. Fail the build on missing alt for content images. (Check: Uploading an image without alt text is blocked or fails the build.) --- ## [Add Organization schema](https://seo-mcp.io/t/add-organization-schema) Organization markup identifies the publisher: name, url, logo and sameAs profiles. Place one JSON-LD block in the sitewide layout, use absolute URLs, and keep names consistent with the brand elsewhere. Validate with the Rich Results Test and do not add ratings or addresses that belong to other types. Prerequisites: - Access to the sitewide layout - Brand assets and verified profile URLs 1. Write the entity block: Emit JSON-LD with @type Organization, name, url, logo and sameAs. Use the production brand name and absolute image URLs. (Check: The block parses as JSON and contains name, url, logo and at least one sameAs URL.) 2. Place it once in the layout: Render the block in the root layout so every page inherits the same values. Remove Organization blocks duplicated by plugins or page-level components. (Check: A DOM query finds exactly one Organization JSON-LD block per page.) 3. Validate and monitor: Run the Rich Results Test on the homepage and one article. Fix warnings about missing recommended fields, and re-check after brand changes. (Check: The Rich Results Test reports the Organization entity with no errors.) --- ## [Add Article schema for posts](https://seo-mcp.io/t/add-article-schema-for-posts) Article markup describes editorial content with headline, image, datePublished, dateModified and author. Use BlogPosting for posts and Article as the generic type. Dates must be ISO 8601 with timezone, and the author should link to a real bio page. Never mark up listing pages as Article. Prerequisites: - A post template - Author pages and publish dates in the CMS 1. Map CMS fields to Article properties: Use the post title for headline, the featured image for image, and ISO timestamps for datePublished and dateModified. Link the author to their bio page. (Check: The JSON-LD contains headline, image, datePublished, dateModified and author.url.) 2. Emit the block per post: Render one Article or BlogPosting block from the post template with the canonical URL in mainEntityOfPage. Do not emit it on listing pages. (Check: A post page contains one Article block; the blog index contains none.) 3. Validate and monitor: Run the Rich Results Test on two posts and check the Article enhancement report for errors after template changes. (Check: Both posts validate with no errors and the enhancement report shows no new issues.) --- ## [Add Product schema with offers](https://seo-mcp.io/t/add-product-schema-with-offers) Product markup with an offers object enables price and availability in merchant listings. Include name, image, description, sku or gtin, brand and offers with price, priceCurrency, availability and url. Keep values identical to the visible page and give each variant its own offers. Prerequisites: - A product template - A catalog feed with price and inventory 1. Map catalog fields to Product: Pull name, description, image, sku, gtin, brand and price from the catalog. Do not hand-write values that the page already renders. (Check: Every sampled product has name, image, sku or gtin, brand and an offers object.) 2. Emit offers with live values: Add price, priceCurrency, availability and url to offers, generated from inventory at request or build time. Use absolute URLs. (Check: The JSON-LD price equals the visible price on the page for ten sampled products.) 3. Validate and monitor enhancements: Run the Rich Results Test on three products and review the Merchant listings report for missing or invalid identifiers. (Check: The Rich Results Test reports Product with offers and no errors for sampled URLs.) --- ## [Add LocalBusiness structured data](https://seo-mcp.io/t/add-localbusiness-structured-data) LocalBusiness markup describes a physical or service-area business: name, address, telephone, hours and coordinates. Use a specific subtype, keep the address identical to the Google Business Profile, and use areaServed for service-area businesses. One page and one block per location. Prerequisites: - A verified Google Business Profile - One page per location 1. Choose the specific type: Pick the schema.org subtype that matches the business category, such as Restaurant or LocalBusiness when no subtype fits. Use the same category wording as the profile. (Check: The @type value is a schema.org LocalBusiness subtype.) 2. Copy the verified profile data: Use the business name, street address, phone and hours exactly as they appear in the Google Business Profile. Add geo coordinates only when known. (Check: Name, street address and phone in the markup match the profile character for character.) 3. Validate and reconcile: Run the Rich Results Test and compare the rendered page with the markup. Fix mismatches before publishing hours changes. (Check: Rich Results Test reports LocalBusiness with no errors and the page shows the same address.) --- ## [Remove deprecated schema](https://seo-mcp.io/t/remove-deprecated-schema) Rich result support changes. FAQPage is limited to authoritative government and health sites, HowTo rich results were retired, and data-vocabulary is obsolete. Remove markup for features you no longer qualify for, keep useful visible content, and check enhancement reports for items that stopped being valid. Prerequisites: - An inventory of emitted JSON-LD types - Search Console enhancement reports 1. Inventory emitted types *(general best practice)*: Search templates for application/ld+json and list each @type with the template that emits it. Include plugin output. (Check: The inventory lists every @type found in rendered pages with its template or plugin source.) 2. Remove ineligible markup: Delete FAQPage and HowTo blocks where the feature is unavailable, and replace data-vocabulary types with schema.org equivalents. (Check: Sampled pages no longer contain FAQPage, HowTo or data-vocabulary.org references.) 3. Re-validate and monitor: Run the Rich Results Test on affected templates and check enhancement reports for new errors after removal. (Check: Affected templates validate without errors and enhancement reports show no invalid items.) --- ## [Implement hreflang for every locale](https://seo-mcp.io/t/implement-hreflang-for-every-locale) hreflang tells Google which language and region variant to serve. Every variant must list all variants plus itself, using valid language or language-region codes and absolute URLs. Choose one delivery method, keep each variant self-canonical, and validate reciprocity after every locale change. Prerequisites: - A locale-aware URL structure - A list of live locale variants per page 1. Choose one delivery method: Decide between head tags, HTTP headers or sitemap annotations for the whole set. Do not mix methods for the same page cluster unless you can keep them identical. (Check: A written decision records the method and where it is generated.) 2. Emit reciprocal annotations: Each page outputs one link per locale variant including itself, with absolute URLs and valid codes. The set must be identical across all variants of the page. (Check: For a sampled page, the annotation sets on every variant are identical apart from order.) 3. Validate targets and reciprocity: Check that every hreflang target returns 200, is indexable, and is self-canonical. Fix codes that mix case or use invalid region values. (Check: A validation crawl reports zero missing return links and zero redirected hreflang targets.) --- ## [Allow AI crawlers in robots](https://seo-mcp.io/t/allow-ai-crawlers-in-robots) AI assistants fetch pages with their own user agents: GPTBot and OAI-SearchBot from OpenAI, ClaudeBot from Anthropic, PerplexityBot, and Google-Extended for Gemini. Decide per bot between training and retrieval, write explicit groups, and test with curl using each agent string. Prerequisites: - Control of robots.txt - A decision on training versus retrieval 1. Check the inherited policy: Read the User-agent: * group. If it contains Disallow: /, every AI crawler is blocked regardless of named groups you add later. (Check: The star group contains no site-wide disallow rule.) 2. Write explicit groups per bot *(general best practice)*: Add separate groups for GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot and Google-Extended with Allow rules for content and rendering assets. (Check: robots.txt contains a named group for each bot with no site-wide disallow.) 3. Test each agent string *(general best practice)*: Request a key page with curl using each user agent and confirm a 200 response with full HTML. (Check: curl -A "OAI-SearchBot" your production domain/ returns 200 and the page HTML.) --- ## [Keep key content in the raw HTML](https://seo-mcp.io/t/keep-key-content-in-the-raw-html) Crawlers and AI retrieval systems may read raw HTML before executing JavaScript. Server-render the main copy, prices, answers and links, and keep metadata in the initial head. Verify with curl and with JavaScript disabled, and hydrate widgets on top of real markup. Prerequisites: - Access to the rendering model - A representative URL per template 1. Curl a representative page: Fetch the URL without executing JavaScript and check for the H1, first paragraphs, prices and primary links in the response body. (Check: The raw response contains the H1 and the first two paragraphs of content.) 2. Move content rendering to the server: Use SSG or SSR for content routes and keep interactive UI in leaf components. Do not gate essential text behind click-only interactions. (Check: The raw HTML contains all essential text and links for the template.) 3. Confirm with no-JavaScript browsing *(general best practice)*: Disable JavaScript and load the page. The user should still read the main content and navigate through links. (Check: With JavaScript disabled, the page shows the main content and at least one working navigation link.) --- ## [Add about and contact trust pages](https://seo-mcp.io/t/add-about-and-contact-trust-pages) About and contact pages are evidence that a real organization stands behind the content. State who runs the site, where it is based, what it does and how it earns money, and give a reachable contact method. Link both from every page footer. Prerequisites: - Business details - Access to the sitewide footer and layout 1. Write the about page: State who runs the site, where the team is based, what the business sells and how it makes money. Name the people where possible. (Check: The about page names the organization, a location and the business model.) 2. Add a working contact method *(general best practice)*: Provide a monitored form or email address, plus a phone and address for local businesses. Test the form and publish response expectations. (Check: A test message sent through the contact form reaches the team inbox.) 3. Link and mark up consistently *(general best practice)*: Link both pages from the footer on every template and mirror the details in Organization markup. (Check: Every sampled page footer contains links to both pages, and the Organization markup matches the about page.) --- ## [Set up a Google Business Profile](https://seo-mcp.io/t/set-up-a-google-business-profile) Google Business Profile is the primary source for local pack and Maps data. Claim and verify the listing, choose the most specific primary category, and keep name, address, hours, phone and website accurate. Add real photos, answer questions and respond to reviews without incentives. Prerequisites: - A real business location or service area - A Google account for the owner 1. Claim and verify the listing: Search for the business on Google Maps, claim the profile and complete verification. Do not create a duplicate listing if one already exists. (Check: The profile dashboard shows the listing as verified and owned by the business.) 2. Set the specific category and details: Choose the most specific primary category, add real secondary categories, and fill address or service area, hours, phone and website. (Check: The profile shows one primary category, at least one secondary category and complete hours.) 3. Publish photos and monitor edits: Upload recent exterior, interior and team photos. Review suggested edits and questions weekly, and respond to new reviews. (Check: The profile has at least five recent photos and no unanswered questions older than seven days.) --- ## [Keep NAP citations consistent](https://seo-mcp.io/t/keep-nap-citations-consistent) Name, address and phone must match exactly wherever they appear: footer, contact page, Google Business Profile, directories and listings. Choose one format, apply it everywhere, record it in a shared document, and fix the highest-authority citations first. Prerequisites: - Canonical business details - A list of active citations 1. Fix the canonical values *(general best practice)*: Write the exact name, street address, suite format and phone number, including punctuation. Store it where writers and developers can find it. (Check: A single reference document states each canonical value and its formatting rules.) 2. Audit the top citations *(general best practice)*: Compare the site, profile and 20 highest-authority directories against the canonical values. Record each mismatch. (Check: The audit lists each platform, its current values and the mismatch found.) 3. Correct and confirm propagation: Update the mismatches, starting with the profile and major directories. Recheck after two weeks to confirm the changes appear publicly. (Check: The profile and at least ten audited citations display the canonical name, address and phone.) --- ## [Handle out-of-stock product pages](https://seo-mcp.io/t/handle-out-of-stock-product-pages) An out-of-stock product page should stay live if the product will return. Keep the URL, show availability clearly, offer an alert and link to alternatives, and update markup to OutOfStock or BackOrder. Remove discontinued items with a 410 and redirect only to a real successor. Prerequisites: - Inventory status in the product template - Access to redirect and status handling 1. Show availability and keep the URL: Render a clear out-of-stock message with an email alert and links to in-stock alternatives. Do not delete or noindex the page for a temporary stockout. (Check: An out-of-stock product returns 200 with an availability message and an alert form.) 2. Align the markup: Set offers.availability to OutOfStock or BackOrder and keep price present when it is still known. Remove InStock from unavailable items. (Check: The JSON-LD availability matches the visible status for sampled products.) 3. Retire discontinued items cleanly: For permanent removals without a successor, drop the URL from the sitemap and return 410. When a successor exists, 301 to it. (Check: Removed products return 410 after the grace period, and successor redirects resolve in one hop.) --- ## [Canonicalize filtered category URLs](https://seo-mcp.io/t/canonicalize-filtered-category-urls) Filtered category URLs usually should not compete with the clean category page. Keep the base URL canonical and self-referencing, and canonicalize filter combinations to it unless a combination has its own demand and unique inventory. Never canonicalize to a blocked or missing URL. Prerequisites: - A list of category filters - Control over canonical generation 1. Classify each facet *(general best practice)*: List filters and decide whether each combination is a duplicate or a potential landing page based on search demand and unique inventory. (Check: Every facet has a documented decision and a canonical target.) 2. Emit the right canonical: Duplicate combinations canonicalize to the clean category URL. Approved landing pages self-canonicalize and get unique copy. (Check: A filtered URL returns a canonical equal to the category URL, unless it is an approved landing page.) 3. Prevent conflicts: Ensure no canonical points to a 3xx, 404 or robots-blocked URL, and do not add noindex to canonicalized pages. (Check: A crawl confirms every canonical target returns 200 and no canonical page carries noindex.) --- ## [Fix duplicate product variant URLs](https://seo-mcp.io/t/fix-duplicate-product-variant-urls) Variants often create near-duplicate URLs for the same item. Choose one page with variant selection and a single canonical, or separate URLs when demand and unique content justify them. Never canonicalize a variant to a different product, and keep the base URL stable across site and feed. Prerequisites: - A catalog with variant relationships - Access to product routing 1. Inventory variant URLs *(general best practice)*: List every product and its variant URLs. Identify which variants have unique content, demand or inventory differences that justify a page. (Check: The inventory shows each variant URL, its traffic and whether it has unique content.) 2. Consolidate or self-canonicalize: For consolidated products, canonicalize variants to the base URL and keep selection in the UI. For separate pages, self-canonicalize and write distinct titles and copy. (Check: No variant canonicalizes to a different product, and each retained variant page self-canonicalizes.) 3. Align feeds and markup: Use the same base URL in the sitemap, Merchant Center feed and ads. Add ProductGroup with hasVariant for consolidated products. (Check: Feed, sitemap and canonical agree for ten sampled products.) --- ## [Mark up product availability](https://seo-mcp.io/t/mark-up-product-availability) Availability in Product markup must reflect real inventory. Use schema.org values such as InStock, OutOfStock, PreOrder, BackOrder and SoldOut, and keep the visible page identical. Generate markup from the commerce system, not from a static template, and revalidate after integrations change. Prerequisites: - Live inventory data at render time - Product template access 1. Map inventory states to schema values: Define which inventory state maps to InStock, OutOfStock, BackOrder, PreOrder or SoldOut. Document the mapping next to the product template. (Check: The mapping covers every inventory state the commerce system can return.) 2. Generate markup at render time: Emit offers.availability from the same inventory value used for the buy box. Do not cache markup across inventory changes. (Check: The JSON-LD availability matches the buy box state for ten sampled products.) 3. Monitor and revalidate: Check the Merchant listings report weekly for availability or price errors, and revalidate after changing the inventory integration. (Check: The report shows no availability or price errors for current items.) --- ## [Add canonical URLs with the Next.js Metadata API](https://seo-mcp.io/t/add-canonical-urls-with-the-next-js-metadata-api) Next.js App Router resolves metadata per route, so each page can declare its own canonical URL instead of inheriting one global value. Set alternates.canonical in the page metadata export or generateMetadata, keep it absolute and self-referencing, and make sure template redirects and trailing-slash handling agree with the URL you declare. Prerequisites: - Next.js App Router project deployed behind a stable canonical host - A single site URL constant available to metadata exports 1. Set the canonical URL policy: Choose one absolute form per page: HTTPS, lowercase host and a fixed trailing-slash rule. Store the production origin in a constant such as siteUrl so metadata, links and redirects all read the same value. (Check: The siteUrl constant resolves to the production origin, and the http, www and apex variants all redirect to it.) 2. Keep app/layout.tsx free of a canonical: Export a metadata object from app/layout.tsx for shared fields only. Do not put a route-specific alternates.canonical there, because every route that forgets to override it inherits the homepage URL. (Check: grep -n 'alternates' app/layout.tsx shows no route-specific canonical value.) 3. Add alternates.canonical per static page: In each page.tsx export metadata with alternates: { canonical: siteUrl + '/pricing' }. Keep the path lowercase and identical to the deployed route, then rebuild so the tag is rendered in the initial HTML. (Check: curl -s your production domain/pricing | grep -c 'rel="canonical"' returns 1 and the href equals the pricing URL.) 4. Use generateMetadata for dynamic routes: In app/blog/[slug]/page.tsx await params, load the post and return { alternates: { canonical: siteUrl + '/blog/' + slug } } from generateMetadata so each record gets its own URL instead of the index canonical. (Check: curl -s your production domain/blog/ | grep -o 'rel="canonical"[^>]*' prints the exact post URL.) 5. Remove duplicate sources and confirm: Delete hardcoded rel=canonical tags in components, CMS widgets and SEO plugins. After deploy, fetch one page per route type, then request validation in the Search Console URL Inspection tool. (Check: curl -s your production domain/ | grep -c 'rel="canonical"' returns 1 for each sampled route.) --- ## [Ship app/sitemap.ts and app/robots.ts](https://seo-mcp.io/t/ship-app-sitemap-ts-and-app-robots-ts) Next.js App Router turns app/sitemap.ts and app/robots.ts into /sitemap.xml and /robots.txt at build time. Return only canonical, indexable URLs from sitemap.ts with honest lastModified values, and set the rules plus the sitemap location from robots.ts. Both files must be reachable without authentication and must not be shadowed by static files in public/. Prerequisites: - Next.js App Router project with a published-content data source - A single production site URL constant 1. Create app/sitemap.ts: Export a default function returning MetadataRoute.Sitemap. Map published records to { url, lastModified }, using absolute URLs from siteUrl and the record updated timestamp rather than the build time. (Check: curl -s your production domain/sitemap.xml returns 200, is valid XML, and lists only canonical published URLs.) 2. Split large catalogs with generateSitemaps: When the set exceeds 50,000 URLs or 50 MB, export generateSitemaps() returning ids and emit one file per id. Next.js then serves /sitemap/.xml and an index at /sitemap.xml. (Check: curl -s your production domain/sitemap.xml returns a sitemap index and every child loc returns 200.) 3. Add app/robots.ts: Return rules with userAgent '*', allow '/' and disallow only paths with no search value. Set sitemap to siteUrl + '/sitemap.xml' and host to the production origin so one file documents the whole crawl policy. (Check: curl -s your production domain/robots.txt returns 200, contains a Sitemap line and disallows no indexable path.) 4. Remove shadowing static files: Delete public/robots.txt and public/sitemap.xml plus any proxy or edge rewrite for those paths. A static file or rewrite can serve instead of the metadata route and silently drop your changes. (Check: curl -sI your production domain/robots.txt returns 200 with text/plain, and the repo has no public/robots.txt.) 5. Submit and monitor: Submit the sitemap in Search Console and compare discovered URLs with indexed ones. Confirm robots.txt does not block CSS, JavaScript or any path that must rank. (Check: The Search Console Sitemaps report lists the file as Success with a discovered URL count above zero.) --- ## [Add BlogPosting JSON-LD in a server component](https://seo-mcp.io/t/add-blogposting-json-ld-in-a-server-component) Article markup helps Google understand headline, author, publish date and image, and feeds both rich results and AI answers. In a Next.js App Router project, render a JSON-LD script inside the blog page server component from the same fields the page displays. Keep the markup valid and identical to the visible content. Prerequisites: - A blog route that loads post data on the server - Canonical post URL and absolute image URL available in the post record 1. Load the post in the server component: In app/blog/[slug]/page.tsx await params, load the post and keep the record in scope for both the JSX and the JSON-LD object, so markup and visible content share one source. (Check: curl -s your production domain/blog/ contains the headline text without executing JavaScript.) 2. Build the BlogPosting object: Set @context, @type BlogPosting, headline, description, datePublished, dateModified, author with name and url, image as absolute URLs, mainEntityOfPage and publisher. (Check: The Rich Results Test reports BlogPosting with no errors for headline, datePublished, author and image.) 3. Render the JSON-LD script tag: Return a script element with type application/ld+json and dangerouslySetInnerHTML set to JSON.stringify(postSchema). Never interpolate raw CMS strings into the script body. (Check: curl -s your production domain/blog/ | grep -c 'application/ld+json' returns 1 and the block parses with JSON.parse.) 4. Match markup to visible content: Headline, author and dates in the JSON-LD must equal the rendered H1, byline and time element. Update or drop fields when the post changes so stale dates do not persist. (Check: For three posts the JSON headline and datePublished match the visible H1 and time datetime values.) 5. Keep one representation: Remove microdata or duplicate JSON-LD for the same post, including blocks injected by SEO packages or template scripts, so one BlogPosting entity reaches the parser. (Check: The page source has one BlogPosting block and no itemprop articleBody duplication.) --- ## [Set canonicals and sitemap with Astro integrations](https://seo-mcp.io/t/set-canonicals-and-sitemap-with-astro-integrations) Astro needs a production site value before canonicals and sitemaps can be correct. Set site in astro.config.mjs, install the @astrojs/sitemap integration, and let it emit sitemap-index.xml with child files. Then render an absolute canonical in the layout from Astro.url and Astro.site so every page references itself. Prerequisites: - An Astro project with a production domain - Ability to run a production build locally or in CI 1. Set the production site: In astro.config.mjs set site: 'your production domain' using the production origin with no trailing slash. This value feeds canonicals, RSS links and sitemap entries. (Check: grep -n 'site:' astro.config.mjs shows the production origin and astro build finishes without a site warning.) 2. Install the sitemap integration: Run npx astro add sitemap, which installs @astrojs/sitemap and adds it to integrations. Build and confirm sitemap-index.xml and its children land in dist/. (Check: dist/sitemap-index.xml exists after astro build and contains only absolute https URLs.) 3. Render a canonical in the layout: In src/layouts/Base.astro compute const canonical = new URL(Astro.url.pathname, Astro.site) and add link rel=canonical href={canonical} in the head so each route declares itself. (Check: curl -s your production domain/ | grep -c 'rel="canonical"' returns 1 with an absolute href.) 4. Filter drafts and previews: Use the filter option of the sitemap integration to drop draft, preview and thin archive routes, while keeping paginated pages that are meant to be indexable. (Check: The built sitemap contains no preview or draft URLs and every loc returns 200.) 5. Deploy and submit: Deploy the build, request sitemap-index.xml in production and add it in Search Console. Confirm robots.txt links to the same index rather than an old sitemap file. (Check: curl -s your production domain/sitemap-index.xml returns 200 and Search Console reports the sitemap as Success.) --- ## [Set meta and canonicals with useSeoMeta](https://seo-mcp.io/t/set-meta-and-canonicals-with-useseometa) Nuxt 3 resolves head tags per route through useSeoMeta and useHead. Set title, description, og and canonical in the page that owns the route, using an absolute URL built from runtimeConfig.public.siteUrl. Set the same origin in nuxt.config.ts so the sitemap module and prerender steps agree with it. Prerequisites: - Nuxt 3 project using SSR or prerendering - A production site URL available in runtime config 1. Configure the site URL once: Add runtimeConfig.public.siteUrl to nuxt.config.ts, fed by an environment variable such as NUXT_PUBLIC_SITE_URL, so server and client resolve the same absolute origin. (Check: The deployed page exposes the production origin in its canonical href and never localhost.) 2. Call useSeoMeta in the page: Inside script setup compute const url = new URL(useRoute().path, config.public.siteUrl).href, then call useSeoMeta({ title, description, canonical: url, ogUrl: url }) for that route. (Check: curl -s your production domain/pricing | grep -c 'rel="canonical"' returns 1 and the href is the pricing URL.) 3. Remove global canonical tags: Delete rel=canonical from app.vue, layouts and plugins that run on every route. A global tag pins every page to one URL and defeats per-route canonicals. (Check: Two different routes return two different canonical hrefs.) 4. Use a sitemap module with the same origin: Add @nuxtjs/sitemap with siteUrl taken from the same config and exclude noindexed, admin and draft routes through its exclude option so both signals agree. (Check: curl -s your production domain/sitemap.xml returns 200 and lists only indexable routes.) 5. Check the server-rendered HTML: Fetch a page without JavaScript and confirm the head already contains title, description and canonical. Then request validation for a changed page in Search Console. (Check: curl -s your production domain/ contains the canonical in the raw HTML, not only after hydration.) --- ## [Add prerendering and a sitemap endpoint](https://seo-mcp.io/t/add-prerendering-and-a-sitemap-endpoint) SvelteKit renders pages on the server by default, so crawlers already receive HTML, but every request still needs a render. Enable prerendering for content routes with export const prerender = true and generate a sitemap from src/routes/sitemap.xml/+server.ts so the file exists at build time. Prerequisites: - SvelteKit project with a Node or static adapter - Production origin available to the build 1. Enable prerendering: Add export const prerender = true to the root layout server file, or set it per content route. For dynamic routes export entries() returning every slug so the build knows what to render. (Check: The build log lists content routes as prerendered and writes HTML into .svelte-kit/output/prerendered.) 2. Add the sitemap endpoint: Create src/routes/sitemap.xml/+server.ts with export const prerender = true and a GET function returning new Response(xml, { headers: { 'content-type': 'application/xml' } }). (Check: After the build, .svelte-kit/output/prerendered/sitemap.xml exists and parses as XML.) 3. Build absolute URLs: Read the origin from $env/static/public, for example PUBLIC_SITE_URL, and join it with each canonical path. Escape ampersands in loc values and use ISO dates for lastmod. (Check: Every loc in the output starts with https and matches a prerendered route.) 4. Reference it from robots.txt: Add static/robots.txt containing Sitemap: your production domain/sitemap.xml alongside the allow and disallow rules, so crawlers discover the file without a submission. (Check: curl -s your production domain/robots.txt returns 200 and contains the sitemap line.) 5. Verify in production: Fetch the sitemap and one listed page, confirm the page canonical matches the loc, then submit the sitemap in Search Console and watch the discovered count. (Check: curl -s your production domain/sitemap.xml returns 200 and ten sampled loc URLs each return 200.) --- ## [Fix collection canonicals and product schema offers](https://seo-mcp.io/t/fix-collection-canonicals-and-product-schema-offers) Shopify renders collection pages at multiple filter and pagination URLs. Keep one canonical per collection, canonicalize filtered views to the base when they are not meant to rank, and emit Product markup whose offers match the real price, currency and availability shown in the buy box. Prerequisites: - Shopify theme with editable Liquid files - Product and variant inventory data available in the theme context 1. Audit the current canonical output: Open theme.liquid and the collection template, then fetch one collection with curl. Count rel=canonical tags and check whether the href is absolute and points at the requested collection. (Check: curl -s your production domain/collections/ | grep -c 'rel="canonical"' returns exactly 1.) 2. Set one canonical per collection: Keep the theme canonical_url for the base collection and remove app or snippet tags that emit a second value. Point filtered and sorted variants at the base collection unless the view is intentionally indexable. (Check: The filtered collection URL lists the base collection as canonical and returns 200.) 3. Emit Product offers in JSON-LD: In sections/product-template.liquid or snippets/product-schema.liquid output offers with price, priceCurrency, availability from product.available and an absolute url for the product. (Check: The Product JSON-LD includes offers.price, offers.priceCurrency and offers.availability.) 4. Match availability to inventory: Map product.available to InStock and OutOfStock, including variant-level availability when the buy box shows a single variant. Update the snippet so every product template inherits it. (Check: For one in-stock and one sold-out product, JSON availability matches the page button state.) 5. Confirm after deploy: Fetch the collection and product on the live theme, parse the JSON block and compare price and availability with the page. Then check the Product snippets report in Search Console. (Check: curl -s your production domain/products/ | grep -c 'application/ld+json' is at least 1 and the block parses.) --- ## [Write unique titles and descriptions in Next.js](https://seo-mcp.io/t/write-unique-titles-and-descriptions-in-next-js) Next.js resolves metadata from the page up to the layout, so a title set once in the root layout repeats on every route. Export a title and description per page, or generate them from record data in generateMetadata. Use title.template for the site suffix, keep descriptions unique, and verify the rendered HTML rather than the component source. Prerequisites: - Next.js project with the App Router or a Pages Router equivalent - A site name and suffix chosen for the title template 1. Set the title template and defaults: In app/layout.tsx export metadata with title.template set to '%s — ' and title.default for the homepage. Do not export route-specific titles from the layout. (Check: grep -n 'template' app/layout.tsx shows the suffix, and no route-specific title sits in the layout.) 2. Export per-page metadata: In each page.tsx export a metadata object with a unique title and a 120-160 character description that matches the visible content of that page. (Check: curl -s your production domain/ | grep -o '[^<]*' prints a page-specific title.) 3. Generate metadata for dynamic routes: In app/blog/[slug]/page.tsx await params, load the record, and return title and description from generateMetadata so each record gets its own values. (Check: curl -s your production domain/blog/<slug> | grep -o '<title>[^<]*' differs between two records.) 4. Check for duplicates after deploy: Crawl the sitemap and compare extracted titles and descriptions. Rewrite any page that still shows the layout default or duplicates another route. (Check: A crawl of 20 sitemap URLs returns 20 distinct titles and at least 18 distinct descriptions.) --- ## [Serve responsive images with next/image](https://seo-mcp.io/t/serve-responsive-images-with-next-image) next/image emits responsive srcset values, picks modern formats and prevents layout shift when width and height are known. Replace raw img tags on content pages, pass sizes for each layout width, mark the LCP image priority, and keep alt text meaningful. Check the rendered HTML for srcset and intrinsic dimensions rather than trusting the component defaults. Prerequisites: - Next.js project and access to the image templates - Known layout widths for the content column and cards 1. Inventory the raw images: Find every img tag in pages and components and note the rendered slot width. Start with the hero image and any image above the fold. (Check: grep -rn '<img' app/ components/ lists the tags with their file paths before any change.) 2. Replace tags with next/image: Import Image from next/image, pass width and height or fill with a positioned parent, and move alt text unchanged. Add sizes that match the CSS breakpoints. (Check: The page renders an img with a srcset attribute containing at least two candidate widths.) 3. Prioritise the LCP image: Add priority to the single largest above-the-fold image and remove it from every other image so the preload does not compete with critical CSS. (Check: The rendered HTML contains one image preload link and the hero image tag carries fetchpriority=high.) 4. Confirm dimensions and formats: Check that intrinsic width and height attributes are present and that the optimizer serves WebP or AVIF to a supporting browser, then measure LCP again. (Check: PageSpeed Insights shows the hero image served in a modern format with no layout shift.) --- ## [Load fonts with next/font to avoid layout shift](https://seo-mcp.io/t/load-fonts-with-next-font-to-avoid-layout-shift) next/font downloads and self-hosts Google or local fonts at build time, generates size-adjust fallbacks and removes the render-blocking stylesheet request. Import the font in the layout, pass its className to the html element, and reference the CSS variable in styles. Verify with a throttled trace that text does not shift and that no font request leaves your origin. Prerequisites: - Next.js project with a root layout - The font family, weights and subsets the design uses 1. Import the font in the layout: Import the font from next/font/google or next/font/local in app/layout.tsx, pass subsets and weights, and assign the returned className to the html element. (Check: The rendered html element carries the generated font class and no link tag points at fonts.googleapis.com.) 2. Reference it through a CSS variable: Set variable to a name such as --font-sans and use that variable in the global stylesheet so components inherit the same family without importing it again. (Check: grep -n 'font-family' app/globals.css shows the variable, and the built CSS contains no external font URL.) 3. Measure the swap: Run a throttled mobile trace with the network cache disabled and record layout shift around the first text paint. Compare it with the previous build. (Check: Lighthouse reports CLS below 0.1 on the typography-heavy template.) 4. Trim weights and subsets: Load only the weights and subsets the design uses, then re-check the font files served. Remove unused families before deploying. (Check: The network panel shows two font files at most for the primary family.) --- ## [Move redirects into next.config redirects()](https://seo-mcp.io/t/move-redirects-into-next-config-redirects) next.config redirects run before rendering and return 308 for permanent rules, so old URLs keep their signals without shipping JavaScript. Move server-side redirect maps into redirects(), mark permanent changes permanent, scope rules with has and missing, and keep temporary campaigns separate. Verify with curl that each old path returns one hop and the expected status. Prerequisites: - Next.js project with a deployed next.config file - A list of old paths and their canonical destinations 1. Collect the current redirect map: List every old URL that still receives traffic or links, with its destination, from the CMS, middleware, server config and analytics landing pages. (Check: The list has one destination per source path and marks which moves are permanent.) 2. Declare rules in next.config: Add an async redirects() export returning source, destination and permanent for each mapping. Use :path parameters for pattern rules and has or missing for scoped cases. (Check: next.config contains the redirects export and the build completes without a redirect error.) 3. Remove overlapping handlers: Delete duplicate rules from middleware or hosting config so one path is handled once. Keep client-side navigation redirects out of the crawler path. (Check: Only one layer defines each source path in the repository.) 4. Test status and hop count: After deploy, request each old path with curl -sI and follow the chain. Confirm a single hop to a 200 destination with the expected 308 or 307 status. (Check: curl -sI your production domain/<old-path> shows one location header and the destination returns 200.) --- ## [Return true 404s with notFound()](https://seo-mcp.io/t/return-true-404s-with-notfound) A route that renders an empty template with status 200 is a soft 404: crawlers index it and users see nothing. Call notFound() when a record is missing or the slug is invalid, add app/not-found.tsx for the layout, and confirm the response status over HTTP. Keep redirects for moved content and reserve notFound() for genuinely absent pages. Prerequisites: - Next.js project with dynamic routes that can receive unknown ids - A not-found page that matches the site layout 1. Find the soft-404 routes: Look for dynamic routes that render a shell when the record query returns nothing, and check the HTTP status of a deliberately invalid slug. (Check: curl -sI your production domain/<dynamic-route>/does-not-exist returns 200 before the fix.) 2. Call notFound() on missing data: Import notFound from next/navigation and call it when the record is absent or invalid, before rendering any content. (Check: The same invalid slug now returns 404 after rebuilding.) 3. Add or fix app/not-found.tsx: Create a not-found page with a short explanation, a link home and navigation, and no indexable content that competes with real pages. (Check: The 404 response renders the not-found layout with a link home.) 4. Keep redirects for moved content: Move slugs that changed to redirect rules and leave notFound() for genuinely absent records. Re-check Search Console for soft 404 reports after deploy. (Check: A moved slug redirects to its new URL, while an unknown slug returns 404.) --- ## [Make contact details clickable and consistent](https://seo-mcp.io/t/make-contact-details-clickable-and-consistent) Customers and crawlers both use the contact page to decide whether a business is real and reachable. Put the phone number in a tel: link, show the full address and staffed hours, and keep the same name, address and phone in the footer, contact page and LocalBusiness markup. Test the phone link on mobile and check that the map pin resolves to the real entrance. Prerequisites: - Confirmed business name, address, phone and staffed hours - Access to the footer, contact page and structured data 1. Confirm the canonical NAP: Write the exact name, street address, postcode, phone and staffed hours as they appear on the storefront and the Google Business Profile. (Check: The recorded values match the Google Business Profile fields character for character.) 2. Make the phone clickable: Wrap every phone number in an anchor with href='tel:+<countrycode><number>' and keep the visible number readable. Do not put the number in an image. (Check: Tapping the number on a phone opens the dialer with the full international number.) 3. Unify every surface: Use the same NAP block in the footer, on the contact page and in the LocalBusiness or Organization markup. Remove older numbers and addresses from templates. (Check: grep for the phone number across templates returns the same string, and the JSON-LD telephone matches it.) 4. Check the map pin and hours: Open the map link on a phone, confirm the pin lands on the entrance, and compare the hours with the profile and the contact page. (Check: The map pin address matches the recorded street address and the hours agree on the site and profile.) --- ## [Verify indexing with URL Inspection](https://seo-mcp.io/t/verify-indexing-with-url-inspection) URL Inspection shows the indexed version Google holds for one URL: crawl time, selected canonical, status code and blocked resources. Run it before rewriting content or changing redirects. It separates indexing failures from ranking problems and confirms whether Google sees the same page your browser renders. Prerequisites: - The site property is verified in Google Search Console 1. Inspect the exact URL: Open URL Inspection in Search Console, paste the full URL including query string or trailing slash, and press Enter. Read the status: 'URL is on Google' means indexed; 'URL is not on Google' explains why. (Check: Search Console shows a crawl date within the last 30 days for the inspected URL.) 2. Compare declared and selected canonicals: Open the crawled-page panel and check HTTP status, the user-declared canonical and the Google-selected canonical. If they differ, fix the signal Google ignored before touching content. (Check: Google-selected canonical equals the user-declared canonical in URL Inspection.) 3. Extract blocking resources: In the rendered HTML panel, look for 'Could not load' entries. Any blocked CSS or JavaScript that changes layout or content must be allowed for Googlebot. (Check: URL Inspection lists zero blocked resources for the inspected URL.) --- ## [Manage crawl budget on large sites](https://seo-mcp.io/t/manage-crawl-budget-on-large-sites) Crawl budget matters most for large or fast-changing sites. Segment server logs by Googlebot, measure requests per template, and remove the causes of waste: parameter URLs, soft 404s and duplicate paths. Improving response speed and internal linking also raises how much Google can crawl. Prerequisites: - Server log access - Search Console Crawl stats 1. Segment logs by template *(general best practice)*: Parse Googlebot requests and group them by path pattern and status. Compute the share of requests landing on thin, duplicate or error pages. (Check: The report shows request counts per template and the percentage spent on non-indexable URLs.) 2. Fix the top waste source: Address the template producing the most wasted requests: remove broken links, return correct status codes, or canonicalize duplicate paths. Change code, not only robots.txt. (Check: The top waste pattern's request count falls in the next monthly log sample.) 3. Improve capacity signals: Reduce server response time, remove redirect chains from internal links, and link important new pages from high-authority templates. (Check: Median Googlebot response time is under 500 ms in the log sample.) --- ## [Monitor index coverage in Search Console](https://seo-mcp.io/t/monitor-index-coverage-in-search-console) The Page indexing report groups URLs by status and reason. Review it weekly, sample each reason, and separate intentional exclusions from regressions. Track counts over time instead of reacting to a single spike, and use URL Inspection to confirm individual cases before changing code. Prerequisites: - Verified Search Console property 1. Export the Page indexing report: Open Indexing, then Pages. Export each status and reason, and note the template each URL belongs to. (Check: The export contains a reason column and at least one sample URL per template.) 2. Classify exclusions as intended or not *(general best practice)*: Mark reasons that match your URL policy as intended. Flag reasons on templates that should be indexed, such as product or article pages. (Check: Every exclusion reason has an intended/regression label and an owner.) 3. Confirm one case before changing code: Run URL Inspection on a flagged URL to see the selected canonical and any blocker. Fix the template rather than individual URLs. (Check: The inspected URL shows the same reason as the report and the cause is documented.) --- ## [Refresh stale content on a schedule](https://seo-mcp.io/t/refresh-stale-content-on-a-schedule) Content decays as facts change and competitors update. Review pages that lost clicks or impressions over three months, refresh facts, examples, screenshots and internal links, and change dateModified only for substantive updates. Track the page for four to six weeks after the update. Prerequisites: - Search Console performance data - An editorial owner for each section 1. Build the refresh list *(general best practice)*: Compare clicks and impressions for the last three months against the previous three. Rank pages by lost clicks and business value. (Check: The list contains at least ten pages with a documented decline and an owner.) 2. Update substance, not just dates: Fix outdated facts, replace dead examples, add missing subtopics and update internal links. Do not change the URL. (Check: Each refreshed page has at least two substantive content changes recorded in the changelog.) 3. Measure the outcome *(general best practice)*: Track clicks and impressions for six weeks after publication and compare with the pre-refresh trend. (Check: Refreshed pages show clicks at or above the pre-decline baseline after six weeks.) --- ## [Track AI referrals in analytics](https://seo-mcp.io/t/track-ai-referrals-in-analytics) AI assistants send traffic through referrers that analytics tools group inconsistently. Build a channel group for chatgpt.com, perplexity.ai, claude.ai, copilot.microsoft.com and gemini.google.com, and review landing pages monthly. Many apps strip referrers, so treat the data as directional. Prerequisites: - GA4 access - Server log access 1. Build the channel group *(general best practice)*: In GA4, create a channel group with rules matching the known AI assistant domains. Include subdomains and regional variants. (Check: The channel group exists and a test session with referrer chatgpt.com lands in it.) 2. Segment by landing page *(general best practice)*: Break the AI channel down by landing page and by event completion. Identify pages that receive assistance-driven visits but no conversion path. (Check: A report lists at least five landing pages with AI-attributed sessions and key events.) 3. Fill gaps with server logs *(general best practice)*: Check logs for assistant user agents and referral parameters that analytics misses, and reconcile the counts monthly. (Check: Log-derived AI visits and analytics AI sessions are compared in one monthly document.) --- ## [Keep schema consistent with page content](https://seo-mcp.io/t/keep-schema-consistent-with-page-content) Structured data must describe what the page shows. Generate JSON-LD from the same data that renders the page, remove properties you cannot keep accurate, and revalidate after redesigns. Stale markup after a migration is the most common source of errors. Prerequisites: - An inventory of emitted schema types - Access to templates and the CMS 1. Compare markup with the visible page: For each template, extract the JSON-LD and compare critical values (price, rating, availability, dates) with what the page displays. (Check: A comparison table lists each critical property and whether it matches the visible page.) 2. Remove or generate from source: Delete hand-written values and generate the block from the same object used for rendering. Remove properties with no real data. (Check: The markup values are produced by the same function or query that renders the page.) 3. Guard against drift *(general best practice)*: Add a check that fails when a template emits no JSON-LD or emits duplicate blocks, and revalidate after each release. (Check: The build fails when a page type loses its JSON-LD block or duplicates a property.) --- ## [Build programmatic pages with unique value](https://seo-mcp.io/t/build-programmatic-pages-with-unique-value) Programmatic pages work when each URL has unique data, unique demand and a useful answer. Build from a dataset, validate a sample before scaling, exclude empty combinations, and add value beyond the template such as calculations, local inventory or comparisons. Measure quality per template. Prerequisites: - A structured dataset with demand validation - A generation pipeline 1. Validate demand for the combinations *(general best practice)*: Group the dataset by entity and check query demand for a sample of combinations. Drop combinations with no demand or no data. (Check: Each generated combination has a demand signal and at least one unique data field.) 2. Add value beyond the template: Include data that changes per page: prices, local availability, comparisons, calculations or original images. Remove boilerplate that repeats across every page. (Check: Two sampled pages differ in at least half of their body content.) 3. Measure and prune *(general best practice)*: Track indexation, impressions and conversions by template. Turn off templates that generate pages without demand or engagement. (Check: A monthly report shows per-template indexation and impressions, with prune decisions recorded.) --- ## [Create topic clusters around pillars](https://seo-mcp.io/t/create-topic-clusters-around-pillars) A topic cluster is a pillar page plus supporting articles for narrower questions, linked to the pillar and to each other where relevant. Build the cluster from real questions and existing queries, keep each supporting page self-sufficient, and publish in an order that supports the pillar at launch. Prerequisites: - Query research for the topic - An editorial plan and author assignments 1. Map questions to supporting pages *(general best practice)*: List the questions around the pillar topic and check which already have pages. Assign new pages only where you can add evidence or a distinct angle. (Check: The map lists each intended supporting page with its target question and owner.) 2. Build the pillar and link both ways: Create a pillar that covers the topic at a high level and links to every supporting page. Each supporting page links back to the pillar with a descriptive anchor. (Check: The pillar links to all supporting pages, and every supporting page links to the pillar.) 3. Ship in sequence and update *(general best practice)*: Publish supporting pages before or alongside the pillar, then update the pillar as new pages appear. Review the cluster quarterly for gaps. (Check: Every published supporting page is linked from the pillar within one week.) --- ## [Prioritize fixes by impact and effort](https://seo-mcp.io/t/prioritize-fixes-by-impact-and-effort) Score each fix by expected impact on traffic or revenue, engineering effort, risk and reversibility. Start with issues that block indexing or break templates, then high-impression pages with fixable problems. Batch related changes, assign one owner per item, and re-measure after four weeks. Prerequisites: - An audit export - Traffic and revenue data by page 1. Score each item *(general best practice)*: For every audit item record impact, effort in hours, risk and reversibility. Use a simple 1 to 5 scale and make the scoring rules explicit. (Check: Every item has four scores and an owner.) 2. Sequence by blockers then value: Ship indexing and template-breaking fixes first, then high-impression pages. Group related changes into one deploy. (Check: The plan lists one deploy per batch with the items included.) 3. Verify and log *(general best practice)*: After each batch, verify the intended effect with the agreed check and record the result in a decision log. (Check: Each completed item has a verification result and a date in the log.) --- ## [Detect keyword cannibalization in Search Console](https://seo-mcp.io/t/detect-keyword-cannibalization-in-search-console) Detect cannibalization before fixing it. Export the Performance report by page and query, group queries where several URLs receive impressions, and confirm by watching which URL ranks over time. Distinguish true cannibalization from legitimate intent splits before acting. Prerequisites: - Search Console Performance access with page and query dimensions 1. Export page and query dimensions: In the Performance report, set the page dimension and query dimension, then export. Group by query and count distinct URLs with impressions. (Check: The export contains at least one query with three or more distinct ranking URLs.) 2. Confirm with ranking history *(general best practice)*: For the top candidates, check the ranking URL across four weekly exports. Alternating URLs confirm cannibalization rather than an intent split. (Check: A query is marked as confirmed cannibalization when its top URL changes at least twice in four weeks.) 3. Document winners and automate *(general best practice)*: Record the intended winner per query cluster and schedule the export monthly. Add new conflicts to the fix backlog. (Check: A monthly report exists with confirmed clusters and assigned winners.) --- ## [Submit your sitemap in Search Console](https://seo-mcp.io/t/submit-your-sitemap-in-search-console) A sitemap is a hint, not a guarantee, but submitting it in Search Console shortens discovery for new URLs and reports parse errors. Submit under the property that owns the URLs, keep entries canonical and indexable, and resubmit only when the file or its lastmod values actually change. Prerequisites: - A generated XML sitemap - Verified Search Console property 1. Open the Sitemaps report: In Search Console choose Indexing, then Sitemaps. Confirm the property scope matches the host in the sitemap URLs. (Check: The report accepts a URL on the same host as the property and shows a status row for it.) 2. Submit the sitemap index: Enter the full HTTPS URL of the sitemap or sitemap index and submit. Prefer the index when you split by content type or locale. (Check: The Sitemaps report lists the submitted URL with status Success.) 3. Read discovered URLs and errors: Compare discovered URLs against the indexable set. Investigate warnings for redirects, 404s or blocked URLs and remove those entries at the source. (Check: Discovered URL count is within 5% of the indexable page count and the error count is zero.) --- ## [Use descriptive URL slugs](https://seo-mcp.io/t/use-descriptive-url-slugs) Descriptive slugs help users and give crawlers a topical hint. Keep them short, lowercase, hyphenated and stable. When a slug must change, redirect the old path with a single 301 and update internal links. Avoid dates, session IDs and uppercase characters that create duplicate URLs. Prerequisites: - Control over routing or CMS permalink settings 1. Audit existing slugs *(general best practice)*: Crawl the site and flag slugs with uppercase letters, underscores, IDs, dates or more than four path segments. Rank by traffic and inbound links. (Check: The audit lists every non-conforming slug with its traffic and inbound link count.) 2. Change only high-value slugs *(general best practice)*: Rewrite slugs that are unreadable or misleading. Keep stable slugs that already rank; the benefit of a cosmetic change is smaller than the redirect risk. (Check: Every changed slug has a matching 301 entry and updated internal links in the same commit.) 3. Verify the redirect and index state: Confirm the old path returns one 301 to the new path and that the new URL is canonical and listed in the sitemap. (Check: curl -sI your production domain/old-slug returns 301 with Location equal to the new slug.) --- ## [Add pagination handling for archives](https://seo-mcp.io/t/add-pagination-handling-for-archives) Paginated archives need crawlable anchor links, a self-referencing canonical on each page and a clear stop at the last page. rel=next and rel=prev are no longer used for indexing. Ensure new items get internal links and that page two is not blocked or redirected to page one. Prerequisites: - A paginated listing template 1. Check pagination links are crawlable *(general best practice)*: Inspect the rendered HTML for the next-page control. It must be an anchor with an href; JavaScript-only controls hide deeper pages from crawlers. (Check: The raw HTML of page one contains an anchor whose href points to page two.) 2. Self-canonicalize each page: Each page in the sequence declares its own URL as canonical. Remove rules that point page two and beyond at page one. (Check: curl -s your production domain/blog?page=2 contains a canonical equal to the page-two URL.) 3. Bound the sequence: Stop pagination after the last real page and return 404 for page numbers beyond it. Keep the URL pattern consistent. (Check: A page number beyond the last returns 404, and the last page has no next link.) --- ## [Improve LCP to under 2.5 seconds](https://seo-mcp.io/t/improve-lcp-to-under-2-5-seconds) Largest Contentful Paint is the time until the biggest visible element renders. Google's good threshold is 2.5 seconds at the 75th percentile of field data. Measure with CrUX or PageSpeed Insights, identify the element, then fix server response, resource load delay, load duration and render delay. Prerequisites: - Access to field data (CrUX or Search Console) - Ability to change markup and asset delivery 1. Identify the LCP element and its timing: Open the Performance panel, load the page on a throttled mobile profile and read the LCP marker. Record time to first byte, resource load delay and render delay separately. (Check: The LCP element is named in the trace and its four phase durations are recorded.) 2. Remove the dominant delay: Preload hero images with fetchpriority=high, remove loading=lazy from above-the-fold media, and serve the HTML from an edge cache. Avoid client-only rendering for the hero. (Check: The LCP image request starts before the first render-blocking resource finishes loading.) 3. Confirm with field data: After deploying, check the Core Web Vitals report or CrUX for the template. Field data lags, so compare four-week windows. (Check: Field p75 LCP for the URL group is 2.5 seconds or less.) --- ## [Reduce INP to under 200 milliseconds](https://seo-mcp.io/t/reduce-inp-to-under-200-milliseconds) Interaction to Next Paint measures how quickly the page responds to input, reported at p75. A good value is under 200 ms. Find the slowest interactions in the Performance panel, then split long tasks, defer third-party scripts, reduce hydration cost and trim DOM size. Prerequisites: - Field data access - Access to JavaScript bundles and third-party tags 1. Find the worst interactions: In the Performance panel, record a session with clicks and typing, then open the Interactions track. Sort by duration and note input, processing and presentation delay. (Check: The three slowest interactions are listed with their phase breakdown.) 2. Break up long tasks and defer scripts: Move non-urgent work out of event handlers, yield to the main thread between chunks, and load analytics and chat widgets only after interaction or idle time. (Check: The trace shows no task over 50 ms during the previously slow interaction.) 3. Confirm in the field: Deploy and compare the p75 INP for the template over four-week windows in the Core Web Vitals report. (Check: Field p75 INP is 200 milliseconds or less.) --- ## [Keep CLS under 0.1 on every page](https://seo-mcp.io/t/keep-cls-under-0-1-on-every-page) Cumulative Layout Shift scores unexpected movement of visible content. Good means 0.1 or less at p75. The main causes are images without dimensions, injected ads or banners, and web fonts changing metrics. Reserve space, preload fonts and never insert content above existing content. Prerequisites: - Field data access - Access to layout and font loading 1. Locate the shifting nodes: Record a throttled load in the Performance panel and read the Layout Shifts track. Each entry names the node and the impacted region. (Check: The trace lists the shifting elements and their contribution to total CLS.) 2. Reserve space and stabilise fonts: Add width and height or aspect-ratio to media, reserve container heights for embeds, and preload the above-the-fold font with a metric-compatible fallback. (Check: The trace shows zero layout shifts from images or fonts during load.) 3. Confirm field improvement: Compare the Core Web Vitals report for the template across four-week windows after the fix ships. (Check: Field p75 CLS is 0.1 or less.) --- ## [Serve responsive images with srcset](https://seo-mcp.io/t/serve-responsive-images-with-srcset) srcset with width descriptors and a sizes attribute lets the browser choose an appropriate file per viewport and pixel density. Without sizes, phones download desktop-size images. Provide at least three widths, keep dimensions to reserve layout space, and check the chosen file in the Network panel. Prerequisites: - A build step or CDN that can generate multiple widths 1. Generate width variants *(general best practice)*: Produce at least three widths per content image, such as 480, 960 and 1440 pixels, at the same aspect ratio. Do not upscale beyond the source. (Check: For a sampled image, the CDN or build output lists three files with the expected widths.) 2. Add srcset and an honest sizes value: Set srcset with width descriptors and sizes that match the CSS layout, for example (max-width: 640px) 100vw, 720px. Keep width and height attributes. (Check: The rendered img element contains srcset, sizes, width and height.) 3. Confirm the selected file *(general best practice)*: Load the page at a 390-pixel viewport with a simulated 3x DPR and check the Network panel for the image request actually used. (Check: The selected file is the smallest candidate that covers the rendered width times DPR.) --- ## [Lazy-load below-the-fold images](https://seo-mcp.io/t/lazy-load-below-the-fold-images) Native loading=lazy defers offscreen images and iframes until they approach the viewport. Apply it only below the fold, keep width and height so space is reserved, and never lazy-load the LCP image. Verify in the Network panel that above-the-fold media loads immediately. Prerequisites: - Access to image templates 1. Mark above-the-fold media *(general best practice)*: Identify images visible at the top of each template. These must load eagerly; everything below the first viewport can be deferred. (Check: Each template has a written list of eager images, including the hero.) 2. Add loading=lazy below the fold: Set loading=lazy on offscreen images and iframes, and keep width and height attributes. Remove JavaScript lazy-load libraries where native support is enough. (Check: The rendered HTML has loading=lazy on below-fold images and no lazy attribute on the hero.) 3. Check load order *(general best practice)*: Load the page in the Network panel, confirm hero requests start immediately, then scroll and confirm deferred requests begin. (Check: Hero image request starts before scroll; deferred images do not request until approaching the viewport.) --- ## [Use modern image formats](https://seo-mcp.io/t/use-modern-image-formats) AVIF and WebP reduce image weight at equivalent quality, which speeds up LCP and lowers transfer cost. Serve them through picture with a fallback, convert at build time or at the edge, resize to the largest displayed dimension, and check the Content-Type and caching per format. Prerequisites: - An image pipeline or CDN that supports format conversion 1. Convert a sample and compare bytes *(general best practice)*: Convert ten representative images to AVIF and WebP at the rendered size and compare file sizes and visual quality at 2x zoom. (Check: Each converted file is smaller than the original at the same displayed dimensions.) 2. Serve with picture and fallback: Emit source elements for AVIF and WebP plus an img fallback. Keep width and height attributes and the srcset variants. (Check: The rendered picture element contains both format sources and an img fallback.) 3. Verify delivery and caching *(general best practice)*: Check the Network panel for the selected format, the Content-Type header and a cache hit on the second load. (Check: The response uses image/avif or image/webp and returns a cache HIT on reload.) --- ## [Build internal links with descriptive anchors](https://seo-mcp.io/t/build-internal-links-with-descriptive-anchors) Internal links pass context and help crawlers discover pages. Use anchor text that names the destination, link from body copy where the link is useful, and keep important pages within three clicks of the homepage. Do not nofollow internal links, and fix links that point at redirects. Prerequisites: - A crawl of internal links and anchor text 1. Audit anchor text for key targets *(general best practice)*: Crawl the site and export inbound internal links per URL with their anchor text. Flag click here, read more, bare URLs and empty anchors. (Check: The export lists at least five inbound anchors for each priority URL, with generic anchors marked.) 2. Rewrite generic anchors in body copy *(general best practice)*: Change the anchor to describe the destination, and keep the surrounding sentence readable. Add links only where they help the reader. (Check: Each priority URL has at least three inbound links with distinct descriptive anchors.) 3. Remove nofollow and redirect links: Strip rel=nofollow from internal links and update hrefs that point at redirected URLs to the final target. (Check: No internal link carries rel=nofollow and the crawl reports zero internal links to 3xx URLs.) --- ## [Add BreadcrumbList structured data](https://seo-mcp.io/t/add-breadcrumblist-structured-data) BreadcrumbList markup mirrors the visible breadcrumb and gives Google the page hierarchy. Each ListItem needs position, name and item URL, ordered from home to the current page. Generate the markup from the same route data that renders the trail so the two cannot drift. Prerequisites: - A visible breadcrumb component - Route hierarchy data 1. Map the trail from route data: Build a list of crumbs from the same source that renders the breadcrumb UI: parent labels and absolute URLs, ending with the current page. (Check: The generated crumb array matches the visible breadcrumb labels and order.) 2. Emit ListItem entries in order: Add a BreadcrumbList itemListElement array with position starting at 1, name and item for each crumb. Keep JSON valid and URLs absolute. (Check: The JSON-LD parses and positions are sequential with no gaps.) 3. Validate and check display: Run the Rich Results Test on a deep page and confirm the breadcrumb is eligible. Recheck after navigation changes. (Check: The Rich Results Test reports BreadcrumbList with no errors for a level-three page.) --- ## [Add review snippet structured data](https://seo-mcp.io/t/add-review-snippet-structured-data) Review snippets require a Review or AggregateRating attached to a specific item such as Product, Recipe or LocalBusiness. Provide ratingValue and reviewCount or ratingCount, keep the visible rating identical, and never mark up self-serving reviews on your own Organization. Prerequisites: - A review collection system - Access to product or location templates 1. Confirm eligibility: Check that the page describes a specific item and that reviews come from real customers. Remove self-serving Organization reviews from scope. (Check: Every page in scope has at least one verified customer review and describes a single item.) 2. Emit AggregateRating from review data: Compute ratingValue and reviewCount from stored reviews. Include bestRating and worstRating when the scale differs from 1 to 5. (Check: The markup values equal the visible rating and count rendered on the page.) 3. Validate and audit: Run the Rich Results Test on three pages and review the review snippet enhancement report for invalid items. (Check: Rich Results Test reports valid review snippets and the enhancement report has no errors.) --- ## [Add author bios with credentials](https://seo-mcp.io/t/add-author-bios-with-credentials) An author bio with verifiable credentials connects content to a real person. Show name, role, relevant experience and links to professional profiles, and link the byline to a dedicated author page. Use Person markup, keep bios current, and never invent expertise or personas. Prerequisites: - Author records in the CMS - Access to article templates 1. Create author records *(general best practice)*: For each byline, store name, role, experience and two verifiable credentials. Add links to professional profiles that actually mention the person. (Check: Every author record has a role, two credentials and at least one working external profile link.) 2. Render the bio and author page *(general best practice)*: Show a short bio on the article and link the byline to an author page listing their articles. Add Person JSON-LD with sameAs. (Check: The byline links to a 200 author page that lists at least three articles by that author.) 3. Align content with the author: Assign articles to authors with relevant expertise and remove generic personas. Add a disclosure line where AI assisted the draft. (Check: No article is attributed to a persona without a working profile or credential.) --- ## [Consolidate thin and duplicate pages](https://seo-mcp.io/t/consolidate-thin-and-duplicate-pages) Thin pages targeting the same topic compete with each other. Group URLs by shared queries and near-duplicate titles, choose the strongest by impressions and links, merge unique material, and 301 the losers. Keep pages that serve genuinely different intent. Prerequisites: - A crawl plus Search Console query data - A redirect map 1. Cluster pages by query overlap *(general best practice)*: Group URLs that share the same primary queries and similar titles. Exclude pairs with clearly different intent. (Check: Each cluster lists its URLs, shared queries and the intent of each page.) 2. Merge into the strongest URL: Move unique sections into the survivor, keep a single H1 and a coherent outline, then 301 the other URLs to it and update internal links. (Check: Each removed URL returns one 301 to the survivor and no sitemap entry remains.) 3. Monitor query coverage *(general best practice)*: Track the survivor's queries and rankings for four weeks and compare with the union of the merged pages. (Check: The survivor ranks for at least 70% of the queries the merged pages previously received impressions for.) --- ## [Match content to search intent](https://seo-mcp.io/t/match-content-to-search-intent) Search intent decides the page format. Informational queries need a direct answer and clear sections, commercial queries need comparisons and pricing, transactional queries need product details above the fold. Classify top queries from the SERP, then restructure rather than rewriting when the topic is right. Prerequisites: - Search Console query data - Access to page templates 1. Classify the top queries *(general best practice)*: For each priority page, list its top queries and look at the SERP. Record the dominant result type and the format users expect. (Check: Each page has a documented intent label and the dominant SERP result type.) 2. Compare the page format *(general best practice)*: Check whether the page delivers that format: direct answer, comparison table, product details. Note the gap between the page and the SERP. (Check: Each gap is recorded as a concrete structural change, not a generic rewrite note.) 3. Restructure and measure: Move the expected format to the top of the page, keep the URL, and compare clicks and impressions after four weeks. (Check: CTR for the restructured page improves at a similar average position.) --- ## [Add original data or first-hand expertise](https://seo-mcp.io/t/add-original-data-or-first-hand-expertise) Original data and first-hand experience are the hardest parts of E-E-A-T to fake. Publish test results, benchmarks, screenshots or interviews, state sample size and date range, and cite primary sources. Update the data when it changes and keep past versions verifiable. Prerequisites: - Access to real data or first-hand experience - An editorial review process 1. Choose a question you can answer with data *(general best practice)*: Pick a question customers ask that requires access you have: account benchmarks, product tests, support ticket patterns. Define the method before collecting. (Check: A written method exists with sample size, date range and inclusion criteria.) 2. Publish the evidence: Present results in tables or charts with units, note limitations, and link primary sources. Attribute the work to a named author with credentials. (Check: The page states sample size, date range, method and author, and every statistic has a source or a method note.) 3. Keep it current and archive it *(general best practice)*: Update the dataset when conditions change and keep an archive of previous versions with dates so readers can verify claims over time. (Check: The page links to at least one dated previous version and shows the current data date.) --- ## [Use a separate URL for each language](https://seo-mcp.io/t/use-a-separate-url-for-each-language) Give every language version its own stable URL. Use a subdirectory or subdomain consistently, do not auto-redirect the first request by browser language, and offer a visible language switcher. Keep one canonical per language and annotate the set with hreflang. Prerequisites: - A localization strategy - Routing control for locale prefixes 1. Choose the locale URL pattern: Pick subdirectories or subdomains and document the pattern. Apply it to every route, including the homepage, so all locales are addressable. (Check: Each locale has a unique URL and the homepage exists for every locale.) 2. Remove forced browser-language redirects: Serve the requested URL and offer a suggestion banner plus a persistent switcher. Do not use Accept-Language to redirect the first request. (Check: curl with Accept-Language: fr against the English URL returns 200 English content, not a redirect.) 3. Canonicalize and annotate: Each locale page self-canonicalizes and lists all locales with hreflang. Add every locale URL to the sitemap once. (Check: A sampled locale page returns its own URL as canonical and the full hreflang set.) --- ## [Add an x-default hreflang entry](https://seo-mcp.io/t/add-an-x-default-hreflang-entry) x-default marks the page served when no language or region matches, usually a selector or the global version. Add it to the hreflang set, ensure it returns 200 and is indexable, and never point it at a geolocation redirect. Validate reciprocity with the rest of the set. Prerequisites: - An existing hreflang set - A language selector or global page 1. Choose the fallback page: Pick a page that serves unmatched users: a language selector or the global version. Confirm it returns 200 and is indexable. (Check: The chosen x-default URL returns 200 and does not carry noindex.) 2. Add the annotation everywhere: Add hreflang=x-default to every variant's set, and include the x-default page in its own set. Keep absolute URLs. (Check: Every variant's annotation set contains exactly one x-default entry with the same target.) 3. Validate reciprocity: Run a reciprocity check across the full set and confirm the x-default target links back to all variants. (Check: Validation reports zero missing return links for the x-default target.) --- ## [Publish an llms.txt file](https://seo-mcp.io/t/publish-an-llms-txt-file) llms.txt is a proposed convention: a Markdown file at the site root that maps the most useful pages for AI systems. It is not a Google standard and adoption is unproven, so publish it as a low-cost experiment, keep it current, and measure referrals instead of assuming impact. Prerequisites: - A list of canonical, indexable key pages 1. Select the pages worth mapping *(general best practice)*: Choose canonical documentation, product and reference pages that answer common questions. Exclude gated, duplicate and low-value URLs. (Check: The page list contains only URLs that return 200, are indexable and are canonical.) 2. Write the file *(general best practice)*: Create /llms.txt in Markdown with an H1 title, a summary paragraph and sections of links with one-line descriptions. Keep it plain text. (Check: curl your production domain/llms.txt returns 200 with text/plain or text/markdown and contains the title and at least one link.) 3. Keep it current and measure *(general best practice)*: Regenerate it when key pages change, and track AI referrers separately to judge whether the file has any effect. (Check: The file lists no URL that returns 4xx or 3xx, and AI referral traffic is tracked in a dedicated channel group.) --- ## [Make pages citable by AI answers](https://seo-mcp.io/t/make-pages-citable-by-ai-answers) AI answers quote passages, not pages. Put a direct answer in the first sentence of each section, then evidence, then caveats. Use question-shaped headings, name sources, include dates and units, and keep paragraphs self-contained so an extracted passage still makes sense. Prerequisites: - Existing content with clear sections - Access to the content templates 1. Find quotable questions *(general best practice)*: List the questions the page answers and the queries it receives. Group them by section and check that each section has a one-sentence answer. (Check: Every priority section begins with a sentence that answers its heading question.) 2. Add evidence and provenance: Follow the answer with units, dates, sample sizes and named sources. Keep the paragraph independent of surrounding pronouns. (Check: Sampled passages name a source or method and include a date where the claim is time-sensitive.) 3. Test extraction *(general best practice)*: Copy a section in isolation and check that it still makes sense. Confirm the page shows an author and last-updated date. (Check: Three sampled passages are understandable without surrounding context and the page shows author and update date.) --- ## [Write clear entity names consistently](https://seo-mcp.io/t/write-clear-entity-names-consistently) Search engines and AI systems resolve entities by name. Use one consistent form for the brand, products and people across titles, structured data, the about page and social profiles. Add sameAs links, use legalName when it differs, and avoid decorative renaming in copy. Prerequisites: - A canonical brand name decision - Access to site content and profiles 1. Record the canonical names *(general best practice)*: Write the brand, legal name, product names and author names in one naming guide, including capitalization and punctuation. Note rejected variants. (Check: The guide lists each entity with one canonical form and the variants to avoid.) 2. Apply across site and markup: Update titles, about page, bylines, Organization markup and product pages to the canonical form. Add sameAs links to verified profiles. (Check: A search of the site for rejected variants returns zero matches in titles and headings.) 3. Align external profiles *(general best practice)*: Update social, directory and marketplace profiles to the same name, and link them from the site with sameAs. (Check: Every sameAs URL shows the same entity name as the site.) --- ## [Earn local citations and links](https://seo-mcp.io/t/earn-local-citations-and-links) Local citations are mentions of the business name, address and phone on other sites, with or without a link. Prioritize maps, review sites, industry directories, chambers and local news, complete each profile fully, and avoid paid link networks that create inconsistent duplicates. Prerequisites: - Canonical NAP values - A list of relevant local platforms 1. Select relevant platforms *(general best practice)*: List local and industry platforms with real customers: maps, review sites, trade associations, chambers and local media. Exclude link networks. (Check: The list contains at least ten platforms with a stated audience and contact or submission path.) 2. Complete each profile: Fill every field using the canonical NAP, category and description. Add photos and a link to the most relevant landing page, not always the homepage. (Check: Each submitted profile shows the canonical NAP and a working link.) 3. Measure referrals *(general best practice)*: Tag landing pages only where the platform allows it, and review referral sessions and calls monthly. Drop platforms that send nothing after two quarters. (Check: A monthly report lists referral sessions and calls per citation source.) --- ## [Add a page for each local service](https://seo-mcp.io/t/add-a-page-for-each-local-service) Create a page for each service in each location you genuinely serve. Each needs unique content: the service, local proof such as projects or reviews, pricing guidance, service area and a contact path. Do not spin the same paragraph with a city name swapped. Prerequisites: - A list of services actually offered - Local proof such as projects or reviews 1. Define the service and location matrix *(general best practice)*: List services and the locations where you can deliver them with real proof. Exclude combinations without evidence or capacity. (Check: Each approved combination has at least one proof item (project, review or case).) 2. Write unique page content: Cover the service, local proof, pricing guidance, service area and contact path in original copy. Do not reuse a paragraph across pages. (Check: Two sampled pages share no paragraph longer than one sentence.) 3. Link and measure *(general best practice)*: Link pages from the services hub and related location pages, and track calls and form fills per page. (Check: Each page receives at least one internal link from the hub and shows conversion events in analytics.) --- ## [Write unique copy for category pages](https://seo-mcp.io/t/write-unique-copy-for-category-pages) Category pages need more than products to rank for commercial queries. Add an intro that states what the category contains and who it is for, buying guidance and answers to common questions. Avoid the same boilerplate across categories, and keep the first paragraph visible. Prerequisites: - Category template access - Assortment and use-case knowledge 1. Write a specific introduction: State what the category includes, who it serves and how the assortment is chosen. Name real brands or use cases instead of generic filler. (Check: Each category intro mentions at least two specific products, brands or use cases.) 2. Add guidance and answers *(general best practice)*: Add a short buying guide and an FAQ section based on real customer questions. Link to relevant guides and subcategories. (Check: The page contains at least three question headings answered in the body.) 3. Keep it visible and current *(general best practice)*: Do not collapse the first paragraph behind a toggle, and update copy when the assortment changes. Check Search Console category queries quarterly. (Check: The intro paragraph is present in raw HTML and references only products still sold.) --- ## [Fix keyword cannibalization](https://seo-mcp.io/t/fix-keyword-cannibalization) Cannibalization happens when several URLs compete for one query, so Google alternates and neither accumulates authority. Find queries with multiple ranking pages, choose a winner by intent and performance, then merge, differentiate or redirect the others and update internal links. Prerequisites: - Search Console query and page data - A redirect map 1. Find competing URLs *(general best practice)*: Export queries with page dimensions and group by query. Flag queries where two or more URLs receive meaningful impressions or alternate as the ranking URL. (Check: The export lists at least ten queries with multiple competing URLs.) 2. Choose the winner per query *(general best practice)*: Pick the URL with the best intent match, links and performance. Decide to merge, differentiate or redirect the others. (Check: Every flagged query has a documented winner and an action for each competitor.) 3. Execute and recheck: Merge content or add 301s, update internal anchors to the winner, and review the query mix after four weeks. (Check: The winner remains the ranking URL across three of four weekly checks after four weeks.) --- ## [Set up Search Console and GA4](https://seo-mcp.io/t/set-up-search-console-and-ga4) Search Console reports what Google sees; GA4 reports what happens after the click. Verify a domain property, submit sitemaps, link the GA4 property, configure consent mode and key events, and review both monthly for snippet and intent problems. Prerequisites: - DNS access for domain verification - GA4 property access 1. Verify the domain property: Add a domain property in Search Console and verify with a DNS TXT record so all hosts and protocols are covered. Submit the sitemap. (Check: The domain property shows verified status and lists the sitemap as Success.) 2. Link GA4 and define key events: Link the GA4 property to Search Console, define key events for sign-up, purchase and contact, and configure consent mode where required. (Check: GA4 shows Search Console data, at least three key events are firing, and consent mode is active.) 3. Set a monthly review *(general best practice)*: Review queries, index status and conversions together. Document which report answers which question and who acts on it. (Check: A monthly review document exists with the questions, reports and owners.) --- ## [Generate social images with opengraph-image.tsx](https://seo-mcp.io/t/generate-social-images-with-opengraph-image-tsx) The App Router reads opengraph-image files as social cards for each route. Export a small ImageResponse component that renders the title and brand, set size and contentType, and add route-level files where the default card is wrong. Confirm the rendered tags point at the generated image and that the image returns 200 with the expected dimensions. Prerequisites: - Next.js App Router project - Brand colours and a font that can be embedded at build time 1. Add the site-level card: Create app/opengraph-image.tsx exporting size { width: 1200, height: 630 }, contentType 'image/png' and a default function that renders the site name and tagline with ImageResponse. (Check: The homepage HTML contains an og:image URL pointing at the generated route.) 2. Add route-level cards where they help: For blog posts, place an opengraph-image.tsx in the route folder and render the post title and author. Keep the component under the edge-safe dependencies the build already uses. (Check: Two different posts render different og:image URLs in their HTML.) 3. Fetch the generated image: Request the og:image URL directly and check the status, content type and dimensions. A failed build-time render usually returns 404. (Check: curl -sI <og:image-url> returns 200 and content-type image/png.) 4. Validate the share preview: Paste a page URL into a social card validator after deploy and confirm the image, title and description render together. (Check: The validator shows the generated image, not a placeholder or a 1200x630 default from another page.) --- ## [Submit your product feed to Google Merchant Center](https://seo-mcp.io/t/submit-your-product-feed-to-google-merchant-center) Merchant Center is the feed layer behind free product listings, Shopping ads and many AI shopping answers. Create an account, verify the domain, submit a feed with stable ids, GTINs and accurate price and availability, then fix disapprovals in the Diagnostics tab. Keep the site and feed in sync, because mismatched prices and stock are the most common suspension cause. Prerequisites: - A verified store domain and business details - A product catalogue export with ids, prices and availability 1. Create and verify the account: Open Merchant Center, add the business details, claim the store domain and complete verification with the method the domain supports. (Check: Merchant Center shows the website as claimed and verified.) 2. Connect the feed: Connect the store platform, plugin or scheduled file upload so products arrive with id, title, description, link, image_link, price, availability, brand and GTIN or MPN. (Check: The Products tab lists the catalogue with no missing identifiers on the first page.) 3. Fix disapprovals: Work through Diagnostics item by item: correct identifiers, align prices and availability, and remove products that are not for sale. (Check: The Diagnostics tab shows zero disapproved items for the sampled category.) 4. Schedule the sync: Set the feed to refresh at least daily and after price or stock changes. Record who checks Diagnostics each week. (Check: The feed settings show a daily schedule and the last fetch is within 24 hours.) --- ## [Collect product reviews on Google or Trustpilot](https://seo-mcp.io/t/collect-product-reviews-on-google-or-trustpilot) Product reviews add first-hand evidence that product pages rarely contain and that review systems reward. Ask every buyer after delivery through the order confirmation or a follow-up email, make the request one click, and never filter out unhappy customers. Answer negative reviews in public, keep review markup on the page, and track rating counts per product rather than one sitewide number. Prerequisites: - Order confirmation or post-delivery email flow - A review destination on the store, Google or Trustpilot 1. Choose the review destination *(general best practice)*: Decide whether reviews live on the product page, on Google Business Profile, on Trustpilot or on two of them, and keep the primary destination consistent. (Check: One primary review destination is recorded and linked from the product page.) 2. Ask every buyer once *(general best practice)*: Add a review request to the post-delivery email with a direct link and one reminder at most. Do not condition the request on a positive experience. (Check: A test order receives the request email with a working one-click link.) 3. Answer in public *(general best practice)*: Reply to negative reviews with the specific fix and an offline contact route. Keep replies short and never argue about the customer's experience. (Check: Every review below three stars has a public reply within one week.) 4. Keep markup honest: Show review text on the product page and add review or aggregateRating markup only for reviews visible on that page. Remove markup for ratings imported from another platform. (Check: The product page's structured data contains only ratings whose review text is visible on the page.) --- ## [List products on the marketplaces your buyers already search](https://seo-mcp.io/t/list-products-on-the-marketplaces-your-buyers-already-search) Marketplaces such as Amazon, eBay and Etsy capture product searches that never reach an independent store. Pick one marketplace where your category sells, list the same SKUs with consistent titles, attributes and images, and link the listing to the brand. Keep price and stock synchronized with the store so the listing does not oversell, and measure whether the listing cannibalizes direct sales. Prerequisites: - A product catalogue with stable SKUs and images - An account on the chosen marketplace 1. Pick one marketplace *(general best practice)*: Compare the marketplaces where your category sells by fee, audience and fulfilment requirements. Choose one for a measured trial instead of listing everywhere at once. (Check: A written choice names the marketplace, the fee per order and the target category.) 2. List matching SKUs *(general best practice)*: Publish the SKUs that already sell on the store with consistent titles, attributes, images and variants. Put the brand in the listing title where the marketplace allows it. (Check: At least ten SKUs are live with titles that match the store's product names.) 3. Synchronize price and stock *(general best practice)*: Connect the marketplace to the store inventory or set a daily sync. Pause a listing automatically when stock reaches zero. (Check: A stock change in the store pauses or updates the listing within 24 hours.) 4. Measure cannibalization *(general best practice)*: Track marketplace sessions, conversion and returns separately, then compare store revenue in the same category before and after the listing. (Check: A monthly report shows marketplace revenue and the store trend for the same SKUs.) --- ## [Earn links from suppliers and brand partners](https://seo-mcp.io/t/earn-links-from-suppliers-and-brand-partners) Suppliers and brands publish stockist, distributor and partner directories to help buyers find retailers. Ask each supplier for a listing on that page with your store name and URL, and offer a logo, one-line description and the categories you carry. Keep the store's own partners page current, because reciprocal pages make the request routine and give the link a real editorial home. Prerequisites: - A current list of brands and suppliers the store sells - A store logo and a one-line description 1. Build the supplier list *(general best practice)*: List every brand or supplier with a stockist, where-to-buy or distributor page and the contact or form that maintains it. (Check: The list names at least ten suppliers with a page URL and a contact route.) 2. Publish a partners page *(general best practice)*: Create or update a partners page that lists the brands you carry and links to their official sites. This is the page you reference in every request. (Check: The partners page returns 200 and links to each brand's official domain.) 3. Send targeted requests *(general best practice)*: Email or submit the form with the store name, URL, city, logo and one line about the assortment. Keep the message short and say the partners page already links to them. (Check: Each sent request is recorded with the date and the recipient.) 4. Verify the placement *(general best practice)*: Check the live stockist page for the store name and a followable link, and follow up once after two weeks if it is missing. (Check: The stockist page contains the store name and a link to the store domain.) --- ## [Get listed on shopping comparison sites](https://seo-mcp.io/t/get-listed-on-shopping-comparison-sites) Shopping comparison sites rank products by price, delivery and specifications, and they answer queries that product pages rarely win. Pick the comparison sites that serve your country, submit a feed or affiliate feed, and make sure prices, shipping and stock match the store. Track referrals and conversion, then drop sites that send traffic without orders. Prerequisites: - A product feed with identifiers, price, shipping and availability - Measurement for referral traffic 1. Pick the sites that serve your market *(general best practice)*: List the comparison sites that index products in your country and category, note how each accepts a feed and what it charges. (Check: The list names at least three sites with their feed format and commercial model.) 2. Submit the feed *(general best practice)*: Send the catalogue with stable ids, GTINs where available, price, shipping and stock. Reuse the Merchant Center feed when the site accepts it. (Check: The site's dashboard shows the catalogue accepted with no missing identifiers.) 3. Keep price and stock current *(general best practice)*: Schedule a refresh at the same frequency as the store changes, and pause unavailable products instead of showing them with stock. (Check: A price change in the store appears on the comparison site within 24 hours.) 4. Measure and prune *(general best practice)*: Tag referral links, then compare sessions, conversion and revenue per site for a month. Remove the sites that send traffic without orders. (Check: A monthly report shows conversion and revenue per comparison site.) --- ## [Create one page per service and service area](https://seo-mcp.io/t/create-one-page-per-service-and-service-area) Local search rewards pages that match the service and the place in the query. Create a page for each service you actually deliver, then add city or neighbourhood variants only where you have real proof such as jobs, photos or staff. Give each page a unique H1, description, price or booking action and internal links to related services, and avoid cloning the same text across locations. Prerequisites: - A list of services the business actually delivers - Proof for each service area, such as jobs, staff or photos 1. List services and areas *(general best practice)*: Write the services sold and the areas served. Mark which areas have real proof and which are aspirational, because only the first group gets pages. (Check: Every listed area has at least one piece of evidence attached to it.) 2. Build the service page template *(general best practice)*: Each service page gets an H1 with the service, the problem it solves, the process, pricing or quote, service areas and one call or booking action. (Check: The page renders a unique H1, a quote or call action above the fold and internal links to related services.) 3. Add area variants only with proof *(general best practice)*: For each service-and-area pair with evidence, write unique local content: the crew, completed work, travel notes or local photos. Link back to the parent service page. (Check: Two area pages for the same service do not share an identical opening paragraph.) 4. Check the crawl *(general best practice)*: Crawl the sitemap and confirm every service page returns 200, has a unique title and description, and links to the contact page. (Check: A sitemap crawl reports unique titles for all service pages and no 404 links.) --- ## [Add FAQ answers to service pages](https://seo-mcp.io/t/add-faq-answers-to-service-pages) Service pages that answer real pre-purchase questions match longer queries and give AI assistants quotable text. Collect the questions from sales calls, chat logs and People also ask, answer each in two or three plain sentences, and keep the answers visible on the page. Mark them up with FAQPage only when the same text is visible, and link each answer to the service or booking action. Prerequisites: - A service page with working quote or booking action - A source of real customer questions 1. Collect the real questions *(general best practice)*: Mine call notes, chat logs and People also ask for the questions customers ask before booking. Group them by service and drop anything the business does not actually answer. (Check: Each service has at least five questions copied from a real source.) 2. Write direct answers *(general best practice)*: Answer each question in two or three plain sentences with the specific range, time or process. Put the answer in visible text on the service page, not only in markup. (Check: The rendered page shows each question and answer in the HTML source.) 3. Link answers to the action *(general best practice)*: Add a quote or call link next to the answers and keep the booking action visible without scrolling. (Check: Each FAQ block contains at least one link to the quote or contact page.) 4. Add honest markup: Add FAQPage structured data only for the visible questions and answers on that page. Validate the JSON-LD after deploy. (Check: The Rich Results Test accepts the FAQPage markup and the questions match the visible text.) --- ## [Add local photos with descriptive alt text](https://seo-mcp.io/t/add-local-photos-with-descriptive-alt-text) Search engines and customers both use photos to confirm that a local business actually works in the area. Add photos of completed jobs, the team and the premises to the matching service or area page, compress them, and write alt text that names the service and place without keyword stuffing. Keep the newest photos on the page and remove stock images that could belong to any business. Prerequisites: - Access to real job or premises photos - The service or area pages where the photos belong 1. Collect real local photos *(general best practice)*: Gather completed jobs, the team and the premises from the last year. Reject stock images and photos without permission; note the service and place for each. (Check: Every selected photo has a service and a location recorded next to it.) 2. Place photos on matching pages *(general best practice)*: Add each photo to the service or area page it proves. Put the strongest job photo near the top and keep the rest in the body, not in a separate gallery. (Check: Each service page shows at least one photo that depicts that service.) 3. Write descriptive alt text: Describe the service and place in one sentence, for example 'Completed bathroom renovation in Riverside'. Do not repeat the same keyword across every image. (Check: The rendered img tags carry alt text that names the service or place, and no two images share identical alt text.) 4. Compress and check the crawl: Serve compressed modern formats with width and height set, then crawl the pages to confirm alt attributes and no layout shift. (Check: Lighthouse reports no missing alt attributes and CLS below 0.1 on the service template.) --- ## [Set up Bing Webmaster Tools and IndexNow](https://seo-mcp.io/t/set-up-bing-webmaster-tools-and-indexnow) Bing Webmaster Tools covers Bing and Copilot surfaces that Search Console reports do not. Verify the site, submit the sitemap and enable IndexNow so new URLs are pushed instead of waiting for a crawl. Keep the IndexNow key file at the site root, ping each changed URL after deploy and review crawl errors monthly. Prerequisites: - Site access to place a key file at the web root - A generated XML sitemap 1. Verify the site in Bing Webmaster Tools: Add the site in Bing Webmaster Tools and verify with the Search Console import, a DNS record, an XML file or a meta tag. Use the host that serves canonical URLs. (Check: The dashboard shows the site as verified.) 2. Submit the sitemap: Open Sitemaps in Bing Webmaster Tools and submit the full HTTPS URL of the sitemap or sitemap index. Confirm the host matches the verified site. (Check: The sitemap appears with a success status and a discovered URL count.) 3. Host the IndexNow key file: Generate a key, save it as `<key>.txt` containing only the key, and upload it to the site root so it resolves at `https://host/<key>.txt`. (Check: Fetching the key URL returns 200 with the exact key text.) 4. Ping changed URLs: Send `https://api.indexnow.org/indexnow?url=<encoded-url>&key=<key>&keyLocation=<encoded-key-url>` for each new or updated canonical URL, or POST a JSON batch of up to 10,000 URLs. (Check: The endpoint returns 200 or 202 and the IndexNow report lists the submitted URL.) --- ## [Run internal-link outreach](https://seo-mcp.io/t/run-internal-link-outreach) Existing pages already pass authority. Find pages that link to outdated, thin or competing resources and ask their owners to point the link at your stronger page. Mine unlinked brand mentions as a second source. Send a short personalised email that names the page and the replacement, then follow up once and track replies. Prerequisites: - A list of pages worth linking to - Backlink data or the Search Console links report 1. Choose the replacement pages *(general best practice)*: List the pages that should receive links: current guides, comparison pages and money pages with clear canonical URLs. Note the older URLs each one replaces. (Check: Each target page returns 200 and has a self-referencing canonical.) 2. Find pages linking to weaker URLs *(general best practice)*: Use a backlink tool or the Search Console links report to list external pages linking to outdated, thin or competing URLs, and keep only followable editorial links. (Check: The list has at least 20 linking pages with the exact source and target URL.) 3. Mine unlinked brand mentions *(general best practice)*: Search for the brand and product names, then record pages that mention the brand without linking. Treat these as warm prospects. (Check: The mention list records the page URL, the sentence and whether it already links.) 4. Send and follow up once *(general best practice)*: Email the page owner with the source URL, the replacement URL and one sentence on why it is better. Follow up once after seven days and log the reply. (Check: Every contact has a sent date, a follow-up date and an outcome in the tracker.) --- ## [Earn editorial links with digital PR](https://seo-mcp.io/t/earn-editorial-links-with-digital-pr) Digital PR earns links by giving journalists something new to report. Build one data asset from proprietary numbers or a survey, find the reporters who already cover the topic, and pitch the most surprising finding in the first sentence. Track every placement, link type and mention so you can repeat the format that worked. Prerequisites: - A dataset or survey with a defensible method - A published report page to link to 1. Choose a newsworthy question *(general best practice)*: Interview sales or support for questions customers argue about, then pick one the data can answer and a reporter would cover. (Check: The question fits in one sentence and has a named audience.) 2. Build and publish the asset *(general best practice)*: Collect the data, write the method section, and publish a report page with charts, a summary of findings and a downloadable table. (Check: The report page returns 200 and states the sample, the dates and the method.) 3. Build the journalist list *(general best practice)*: Collect bylines from the last year on the topic, recording outlet, beat and most relevant article. Keep the list short and relevant. (Check: The list has at least 25 named reporters with a live article URL each.) 4. Pitch and track placements *(general best practice)*: Email one finding with the number in the subject and first sentence, link the report and offer the data. Log every send, reply and placement. (Check: The tracker records each placement URL, its link type and any mention without a link.) --- ## [Rewrite product pages and internal links with Claude MCP](https://seo-mcp.io/t/rewrite-product-pages-and-internal-links-with-claude-mcp) Connect Claude to a Shopify or WordPress store through an MCP server, use an AI SEO audit to identify the pages to change, then have Claude rewrite supplier product descriptions and add the recommended internal links directly on the site. The source says this replaces weeks of manual work, letting a large catalogue and orphaned pages be updated in hours. Prerequisites: - A Shopify or WordPress store - An MCP server connected to Claude with write access to product and content data - An exported list of product pages and internal links to change 1. Connect Claude to the store through MCP: Set up a Shopify or WordPress MCP server with access to products and pages, then connect it to Claude. Grant only the permissions needed to read and edit product content. (Check: Ask Claude to list products and confirm it returns titles from the connected store.) 2. Pull the change list from the audit: Run an AI SEO audit of the connected store and export the product pages and internal links it recommends changing. Keep the target URL and suggested source page for each link. (Check: The export contains at least one product page and one internal link recommendation with a source and target URL.) 3. Rewrite supplier product descriptions: For each flagged product, have Claude replace the supplier text with a detailed description that uses the product's real attributes and keeps specifications accurate. (Check: Open the product URL in the storefront and confirm the description differs from the supplier text and includes the product specifications.) 4. Add the recommended internal links: Have Claude insert links from the recommended source pages to the low-traffic target pages. Use descriptive anchor text that matches the target page. (Check: View the source page HTML and confirm the new anchor is present and the target href returns HTTP 200.) --- ## [Find keyword families competitors rank for but you don't](https://seo-mcp.io/t/find-keyword-families-competitors-rank-for-but-you-dont) Compare your site with three main competitors in Search Console to list the keyword families they rank top 10 for and you do not. Record volume, the page type Google ranks and the winning competitor page, sort by commercial intent, then decide which families an existing page can cover and which need a new collection. Prerequisites: - Google Search Console access for the site - A shortlist of 3 main competitors 1. Connect Search Console to the comparison: Select the Search Console property for the site you are auditing so the keyword comparison runs on your own query data rather than on estimates. (Check: The analysis shows query rows for your property, for example a 28-day query table with impressions and clicks.) 2. Name the three main competitors: List the three competitor domains whose visibility you want to compare against, using the sites that already appear beside you in the SERPs for your core terms. (Check: Three competitor domains are listed and each returns ranking keywords in the comparison output.) 3. List the keyword families you are absent from: Run the comparison so it returns every keyword family the competitors rank in the top 10 for and your site does not rank for at all. (Check: Each returned family has at least one competitor URL in positions 1-10 and no URL from your domain in the results.) 4. Add volume, page type and the winning competitor page: For every family record the monthly search volume, the page type Google currently ranks (collection, product or guide) and the competitor URL that wins it. (Check: Every row in the list has a volume figure, a page type label and one competitor URL.) 5. Sort the families by commercial intent: Reorder the list so families whose ranking pages are collections and products come first and guide-style families last. (Check: The top of the sorted list contains only families where Google ranks a collection or product page.) 6. Map each family to an existing page or a new collection: For each family decide whether an existing page or collection can cover it, and mark the rest as needing a new collection; a gap that an existing page half-covers usually means a title and content fix, not a new URL. (Check: Each family in the sorted list has either an existing URL or a planned new collection URL assigned to it, with no two families pointing at the same page type and term.) 7. Track the new or fixed pages after publishing *(general best practice)*: Publish the pages in priority order, then monitor indexation and impressions for the new URLs so families that fail to gain visibility are caught early. (Check: Search Console Pages reports the new URL as Indexed and the Performance report shows impressions for the target family.) --- ## [Audit and fix duplicate product and collection pages first](https://seo-mcp.io/t/audit-and-fix-duplicate-product-and-collection-pages-first) Audit the existing store pages before adding new content: consolidate thin or overlapping collection pages, rewrite product descriptions copied from suppliers, and link pages that nothing points to. Repairing pages that already exist is faster than earning rankings for new ones and removes duplicate URLs that compete with each other. Prerequisites: - Access to the store's CMS or theme templates - A crawl of the live site or export of URLs from the sitemap 1. Inventory the store's existing URLs *(general best practice)*: Collect every indexable URL from the XML sitemap and a full crawl so collection, product and orphan pages are all in one list. (Check: The URL list count matches the sitemap entry count plus pages discovered only by crawling.) 2. Find thin and overlapping collection pages: Group collections that serve the same product set or query and flag pages with almost no unique text or products. Plan merges or redirects so one collection owns each topic. (Check: Each flagged collection appears in a merge/redirect list with the surviving target URL named next to it.) 3. Rewrite supplier product descriptions: Replace copied supplier descriptions with unique copy that describes the item with store-specific detail instead of synonyms of the original text. (Check: No product page contains text identical to the supplier feed; a quoted-phrase search of the old description returns no match on the site.) 4. List and link orphan pages: Compare crawled URLs against internal link targets to find pages with no internal links, then add contextual links from related products, collections or the category menu. (Check: A re-crawl shows each formerly orphan URL with at least one internal link pointing to it.) 5. Request re-indexing and monitor coverage *(general best practice)*: Submit the changed collection and product URLs for indexing and watch the Search Console Pages report for the merged URLs moving to the redirect target. (Check: Search Console lists the changed URLs as indexed and the merged collection URLs as Page with redirect.) --- ## [Brand your named frameworks for AI attribution](https://seo-mcp.io/t/brand-your-named-frameworks-for-ai-attribution) When you publish an original framework, give it a branded name such as "The <Brand> content scoring matrix" instead of a generic label, then use that identical phrase on every page and channel. A consistent distinctive name makes the concept traceable to your site and easier for models and search engines to attribute to you. Prerequisites: - At least one original framework or named method already published on the site - Editorial control over the pages and channels where it appears 1. Pick the framework to rename *(general best practice)*: Choose one original method you already publish under a generic label and note every URL, heading and asset where that label appears. (Check: A list of URLs exists that each contain the generic label in the title, H1 or body copy.) 2. Coin the branded name: Prefix the concept with your brand, keeping it short and typeable, for example "The Acme Content Scoring Matrix". Use one spelling and capitalisation. (Check: The chosen string returns zero exact-match results when searched in quotes before you publish it.) 3. Replace the generic label on existing pages *(general best practice)*: Update titles, H1s, body copy and image alt text on every page from the list so only the branded name is used going forward. (Check: A site search for the old generic label returns no remaining pages, and the new name appears in the page source of each updated URL.) 4. Repeat the exact phrase on every channel you publish on: Use the identical branded string in blog posts, docs, video titles, newsletters and social posts rather than paraphrasing it. (Check: A site: query plus the branded phrase in quotes lists your pages, and the same phrase appears verbatim on your external profiles.) 5. Check the attribution after a few weeks *(general best practice)*: Search the branded phrase in Google and ask an AI assistant about the topic to see whether your site is named alongside the concept. (Check: The exact-phrase search returns your site on page one and the assistant answer names your brand with the framework.) --- ## [Get steady Google reviews and reply within two days](https://seo-mcp.io/t/get-steady-google-reviews-and-reply-within-two-days) Ask customers for a review at checkout while the visit is fresh, text the direct Google review link the same day, and invite them to mention the treatment in their own words. Reply to every review within one to two days. A steady flow of recent, specific reviews keeps the local profile active and relevant. Prerequisites: - A verified Google Business Profile - Access to customer contact details for same-day follow-up - Front-desk staff able to ask customers at checkout 1. Ask at checkout: Brief front-desk staff to ask satisfied customers at checkout, while they are still in the building, to leave a Google review. (Check: A written checkout script includes the review request and front-desk staff confirm they use it.) 2. Text the direct review link the same day: Send the customer the link that opens the Google review box on the day of the visit, not days later. (Check: A test message to a staff phone opens the Google review form for the correct business location.) 3. Invite treatment details without writing the review: Suggest that the customer mention the treatment they had in their own words, but do not write or dictate the review text. (Check: The request script contains a suggestion to name the treatment and no pre-written review copy is sent to customers.) 4. Reply to every review within 48 hours: Answer each new review from the Google Business Profile review inbox within one to two days. (Check: No unanswered review in the profile is older than 48 hours.) 5. Keep public replies free of health details *(general best practice)*: Do not confirm treatments, diagnoses or appointment details in a public reply; invite the reviewer to continue the conversation privately. (Check: Recent owner replies contain no treatment names, diagnoses or appointment details.) --- ## [Add review-sourced customer results to pages for AI quotes](https://seo-mcp.io/t/add-review-sourced-customer-results-to-pages-for-ai-quotes) Pull the last 12 months of reviews from G2 or Capterra, extract every concrete customer result with an LLM, then add two or three verified quotes with the reviewer's role and company size to the pages that match their industry and segment. Specific, attributable results give answer engines something exact to quote. Prerequisites: - A product listed on G2 or Capterra with reviews from the last 12 months - Existing testimonials or case-study quotes - Access to the pages where the quotes will be added - Access to an LLM such as Claude 1. Collect the review text: Open the product page on G2 or Capterra, go through the reviews from the last 12 months, and copy the full text of each one. Add any testimonials or case-study quotes you already hold. (Check: A single document holds one pasted review per entry, each traceable to its G2 or Capterra review URL.) 2. Extract the concrete results with an LLM: Paste the collected text into Claude and ask it to pull out every specific result a customer mentions, with the exact quote, the reviewer's role and their company size, grouped by industry. (Check: The output lists items such as a before/after metric with the exact quoted sentence, a role and a company size, each under an industry heading.) 3. Map each result to the page it belongs on: Assign each extracted result to the page that matches the reviewer's industry and company size, for example a result from a 50-person SaaS company goes on the page for SaaS teams rather than the homepage. (Check: Each target page has at least one assigned quote, and no quote is assigned to a page whose audience differs from the reviewer's segment.) 4. Publish two or three quotes per page: Add two or three of the assigned quotes to each matching page, placed directly under the section that answers the question, with the reviewer's role and company size shown next to the quote. (Check: The rendered page shows the quote text followed by the role and company size, e.g. a finance lead at a 50-person SaaS company.) 5. Fact-check every quote before it goes live: Compare each published quote character by character against the original review and restore the original wording if the LLM rounded, merged or reworded anything. (Check: Each quote on the page matches the source review text exactly, with no changed or combined numbers.) --- ## [Audit the six sources AI assistants read for local queries](https://seo-mcp.io/t/audit-the-six-sources-ai-assistants-read-for-local-queries) The post argues AI assistants answer local recommendation questions by running search-style queries and reading a fixed set of sources. Audit and align those sources: Google Business Profile fields, customer reviews, service and city pages, third-party listings, profile posts, and consistent name, address and phone data. The benefit is a better chance of being included when an assistant recommends a local business. Prerequisites: - Google Business Profile manager access - Access to the website's service and city page templates 1. Audit the Google Business Profile fields named in the post: Open the profile and check the primary category, hours, photos, description and Q&A. Update missing or outdated fields so each matches the business's current service. (Check: The Info tab shows a primary category matching the core service, current hours, at least one photo, a description and answers in the Q&A section.) 2. Review service and city pages on the website: Open the site's service pages and city pages. For each service-city combination the business targets, confirm a page exists and names the service and city; make customer reviews visible on those pages. (Check: A sitemap or site crawl lists one URL per targeted service-city pair that includes both terms in the page copy.) 3. Audit third-party listings and mentions: Search for the business name plus city, and for best [service] in [city]. Check directories, Yelp-type platforms, Reddit threads and local news pages; claim or correct listings that show wrong details. (Check: Each found listing shows the current business name, address and phone; missing or incorrect listings are noted for correction.) 4. Standardize name, address, phone and hours: Choose one exact format for the business name, address, phone and hours, then apply it to the Google Business Profile, the website's contact or footer area, and the main directory listings. (Check: The same string appears on the Google Business Profile, the site footer or contact page, and the top three directory listings.) 5. Post job photos and updates to the Google Business Profile: Publish posts and photos of real completed jobs to the profile on a regular schedule. (Check: The profile's Updates and Photos sections show a post or photo from the current month.) 6. Ask customers for specific reviews: After a job, ask the customer for a Google review and invite them to mention the service performed and the city. Do not script the review; ask for the detail. (Check: The newest reviews include the service or city term in the reviewer's own words.) 7. Check what the assistant reads about the business: Run a representative long local question in ChatGPT, Gemini or Google AI Mode. Read the answer for the business name, service and city, and note which of the six sources is missing or says something different. (Check: The answer either names the business with correct service and city details, or the missing or contradictory source is identified for correction.) --- ## [Filter keywords for AI Overviews before you target them](https://seo-mcp.io/t/filter-keywords-for-ai-overviews-before-you-target-them) Before committing content to a keyword, Google it and read the AI answer as a searcher would. If the answer fully resolves the query, target being named in the cited pages instead of the click; if it does not, rank normally. Record which pages the answer cites, which brands they name, and turn the gaps into an outreach list. Prerequisites: - A keyword shortlist that already passed business potential, intent and difficulty checks - Google access in a market where AI Overviews are shown - Search Console access to the property for the brand-mention query 1. Read the AI answer for each shortlisted keyword: Search the keyword in Google and read any AI Overview as a customer would, not as an SEO. Decide whether the answer fully resolves the query before any click is needed. (Check: For your target keyword the SERP shows an AI Overview panel (or none) and your sheet records the decision satisfied or not satisfied.) 2. Split the list into mention targets and classic targets: If the searcher is satisfied without clicking, mark the keyword as a mention target. If not, keep it as a classic ranking target. Tool queries such as calculator, checker, generator, template and planner stay classic targets because the searcher must use something the answer cannot provide. (Check: Every keyword in the sheet carries either the mention or the classic label.) 3. Collect the pages the answer cites: For each mention keyword, note the pages linked from the AI answer, starting with listicles, which the source says make up a large share of cited pages. (Check: The sheet lists at least one cited URL per mention keyword, each tagged as listicle, comparison or review.) 4. Pull the top-ten pages for commercial queries: Connect the Search Console property to an AI SEO tool and ask which pages rank in the top ten for best-of, alternative and versus queries in your category. (Check: The tool response returns top-ten URLs for each of the three query patterns.) 5. Record format and named brands per page: For each ranking page note whether it is a listicle, a comparison or a review, which brands it names, and whether your site is among them. (Check: Each row in the sheet has a format value, a brand list and a yes/no for your own site.) 6. Turn the gaps into an outreach list: Every page that names three competitors and does not name you becomes a line on the outreach list, which feeds the follow-up outreach and pitching work. (Check: The outreach sheet contains one row per qualifying page with the URL and the brands it currently names.) --- ## [Rewrite top-of-page answers so AI assistants can quote them](https://seo-mcp.io/t/rewrite-top-of-page-answers-so-ai-assistants-can-quote-them) Paste the visible text of pricing, integrations and top use-case pages into Claude with a prompt that demands one exact quoted sentence. Pages where Claude cannot quote a single answer, or has to stitch one together from several paragraphs, get rewritten so a two-to-three sentence answer sits directly under the heading. Prerequisites: - Access to edit the body content of pricing, integrations and use-case pages - Access to an LLM chat interface such as Claude 1. List the pages buyers read before booking: Write down the pricing page, the integrations page and the top use-case pages, and next to each one the single buyer question that page is supposed to answer. (Check: A list exists pairing each page URL with exactly one buyer question.) 2. Run the quote test in Claude: Copy the visible body text of one page (not just the URL) into Claude and send the prompt below, substituting the buyer question from the list. (Check: Claude's reply either contains a verbatim sentence from the page or states that the answer is missing.) 3. Mark each page pass or fail: Fail any page where Claude cannot quote one clear sentence, or where it has to stitch the answer together from several paragraphs. (Check: Every page in the list is marked pass or fail, and each fail names the paragraph Claude had to combine.) 4. Rewrite the opening as a direct answer: Replace the company preamble at the top of the failed page with two or three sentences that answer the buyer question, including the concrete details (what connects, what syncs, which plans, setup time). Keep links out of the answer block and move the rest of the copy underneath it. (Check: The rendered page shows a two-to-three sentence answer as the first block after the heading, above any company description, with no anchor tags in that block.) 5. Re-run the quote test on the edited page *(general best practice)*: Paste the updated page text into a fresh Claude chat with the same prompt and confirm it returns a single quoted sentence rather than a reconstruction. (Check: Claude replies with one verbatim sentence copied from the new opening block.) --- ## [Audit and fix what AI engines say about your brand](https://seo-mcp.io/t/audit-and-fix-what-ai-engines-say-about-your-brand) Query each AI assistant about what the brand does, who it serves, its pricing and integrations, then diff every answer against a current fact sheet. Correct each wrong claim at its origin: update or redirect stale pages on your own site, fix G2, Capterra and directory profiles, and ask publishers to amend third-party articles. Prerequisites: - Access to the AI assistants you want to audit - A current fact sheet covering what the brand does, its audience, pricing and integrations - Login access to your G2, Capterra and other directory profiles 1. Query each AI engine about the brand: Run the same four-part prompt in every engine you want to audit and save each answer verbatim with the engine name and date. (Check: One saved answer per engine that covers what the brand does, who it is for, cost and integrations.) 2. Diff the answers against your fact sheet: Paste the saved answers into Claude together with a short fact sheet of what is true today, and ask for every wrong or out-of-date claim plus the source each engine cited. (Check: Output lists each wrong claim next to the URL the engine cited for it.) 3. Bucket each wrong claim by who owns the cited source: For every flagged claim, open the cited URL and mark it as either your own domain or a third party. This decides which fix path you take. (Check: Each wrong claim has one cited URL and a bucket label (own site or third party).) 4. Fix claims sourced from your own site: Where the engine cited your own domain, update the page or redirect it to the current one. Typical culprits are old pricing pages, stale blog posts and pages for features you have dropped. (Check: The cited URL returns 200 with corrected copy, or a 301 to the current page.) 5. Correct third-party listings: Where the claim sits on a profile you control, update your G2, Capterra and directory listings so pricing, features and integrations match the fact sheet. (Check: Each directory profile shows the current pricing and feature set.) 6. Ask publishers to correct their articles: For articles you do not control, contact the author or editor with the specific wrong claim, the correct fact and a link to your fact sheet. (Check: The article shows the corrected claim, or you have a written reply confirming the fix.) 7. Re-run the engine queries to confirm *(general best practice)*: Repeat the original prompt in each engine after the fixes are live and compare the new answers with the first run. (Check: The previously wrong claim no longer appears in the engine's answer.) --- ## [Build an AI entity-association benchmark for your brand](https://seo-mcp.io/t/build-an-ai-entity-association-benchmark-for-your-brand) List every entity an AI model could name for your business — the brand, products, named features, invented metrics and the people — then write the descriptors you want attached to each, such as cheap, for agencies or AI-powered. That list becomes the benchmark for checking how AI assistants describe you. Prerequisites: - A list of the brand, product, feature, metric and people names used publicly 1. List every nameable entity: Write down the brand and every product name, named feature, invented metric and public person such as founders or the face of the YouTube channel. (Check: The list has an entry for the brand, each public product or feature, each invented metric and each named person the site promotes.) 2. Write the target descriptors: Next to each entity, write the short words you want an AI model to associate with it, for example cheap, for agencies or AI-powered. Keep each descriptor specific and checkable. (Check: Every entity has one to three short descriptors written beside it.) 3. Capture a dated baseline *(general best practice)*: General best practice: ask an AI assistant open questions about each entity, save the answers verbatim with the date and the assistant used, and note which entities and descriptors actually appear. (Check: The saved baseline has one dated answer per entity and at least one listed descriptor is recorded as present or absent.) 4. Mark gaps against the target *(general best practice)*: Compare each baseline answer with the target descriptors and label every entity as aligned, missing or wrong. General best practice: use the gaps to brief page copy, profiles or public descriptions that state the wanted associations. (Check: The benchmark has a status column with at least one aligned, missing or wrong entry for every entity.) --- ## [Map which source types each AI engine cites for buyers](https://seo-mcp.io/t/map-which-source-types-each-ai-engine-cites-for-buyers) Write ten buyer-intent questions, run each through ChatGPT, Claude, Perplexity and Gemini with web search on, and record the URLs each engine cites. Then group those URLs by source type to see which engines favour Reddit, review sites, listicles or your own pages, so content effort goes where citations already come from. Prerequisites: - Access to ChatGPT, Claude, Perplexity and Gemini with web search enabled - A list of your brand name and two or three competitors 1. Write ten buyer questions: Draft ten questions a buyer would ask before choosing a product like yours, using the tweet's three phrasings: "what's the best [category] for [type of company]", "[your brand] vs [competitor]", and "is [your brand] worth it for a team of [size]". (Check: Ten questions are written down, each matching one of the three phrasings and naming your category, brand or a competitor.) 2. Collect cited sources in ChatGPT: Run each question in ChatGPT with web search enabled. Open the Sources button under the answer, or the three-dot menu and View sources if the button is absent, and copy every cited URL. (Check: For each question the Sources panel lists at least one URL copied into your notes.) 3. Repeat the run on Claude, Perplexity and Gemini: Ask the same ten questions in each remaining engine with web search on and copy the cited URLs, keeping them separated by engine. (Check: The log has a row for every question-engine pair (40 rows) with at least one cited URL.) 4. Record the citations in a log *(general best practice)*: Store the results in one table with columns for engine, question, cited URL and source type so later classification and re-runs are comparable. (Check: The log opens with the header row engine, question, cited_url, source_type, run_date.) 5. Classify citations by engine and source type: Paste all cited URLs into Claude with the instruction to sort by engine and then by type (own site, competitor site, review site, Reddit, listicle, news or blog), and to state which types each engine cites most. (Check: The output names each engine separately and lists its most-cited source types.) 6. Pick the source types to invest in: Use the per-engine ranking to choose the one or two source types you will pursue for the engines that matter most, for example Reddit threads if Perplexity dominates that list or review-site presence if Gemini does. (Check: A written shortlist names the chosen source types and the engine each is meant to influence.) --- ## [Rewrite biased listicles so your product earns its rank](https://seo-mcp.io/t/rewrite-biased-listicles-so-your-product-earns-its-rank) Audit listicles and comparison pages where the site ranks its own product first, then reorder entries by the criteria printed on the page and move the product to the position it honestly earns. The result is a ranking a reader can defend, without changing the page's structure or losing its internal links. Prerequisites: - Edit access to the site's listicle and comparison page content - A list of pages where the site ranks its own product first 1. Inventory the pages that rank the site first: Query the CMS or use a site: search to list every listicle and comparison page, then flag the ones where your own product or service sits in position 1. (Check: The inventory lists at least one URL, and each listed URL shows your product in position 1 of the ordered list.) 2. Write down the criteria each page claims to use: Open every flagged page and note the criteria it says it uses to order the entries (price, features, use case, review score). (Check: Each flagged URL has a written criteria list, or is marked as having none.) 3. Reorder the entries by those criteria: Sort the entries so the ranking follows the stated criteria and move your product to the position it would honestly earn. Keep the page structure, headings, tables and existing links in place. (Check: The rendered page order matches the stated criteria and your product is no longer first unless the criteria put it there.) 4. Review the diff before publishing: Compare the current and edited versions of each page and confirm the change is a reordering plus the text edits it requires, not a rewrite. (Check: The diff shows no deleted sections, tables or internal links, only changed order and adjusted copy.) 5. Update the intro and summary copy to match the new order: Rewrite any sentence below the list, in the intro or in the conclusion that still claims first place, so the text and the ranking agree. (Check: A search of the page for "#1", "best" and "number one" returns no claim that contradicts the new order.) 6. Save the rules for new pages: Add the author box to the page template, link to three existing pages on the same topic with descriptive anchors, and add a rule that the site never ranks itself first in a list. (Check: A newly published listicle shows the author box, three descriptive internal links, and a Person node in the page's JSON-LD.) --- ## [Cap publishing on a new site at 3-4 URLs per week](https://seo-mcp.io/t/cap-publishing-on-a-new-site-at-3-4-urls-per-week) Cap a new site's output at three or four URLs a week and hold that ceiling until Google sends organic clicks on its own. Every page must be one a person would actually read. Pumping unoriginal pages at volume risks the scaled content abuse policy, which applies whether automation, humans or both produced the text. Prerequisites: - A new domain or a site without an established record of indexed, clicked pages - Access to the CMS or publishing workflow and its scheduling settings - Google Search Console verified for the site 1. Set a weekly ceiling of three or four URLs: In the CMS or editorial calendar, schedule at most three or four new URLs per week for the first months of a new domain. Queue the rest as drafts rather than publishing them at once. (Check: The sitemap or CMS published list shows no more than 4 URLs with a publication date in the last 7 days.) 2. Apply a one-reader quality gate to every page: Before publishing, confirm the page contains something a person would actually read: original examples, data or explanations rather than recombined text. Hold back any URL that fails the test. (Check: The editorial tracker records reviewer sign-off for each of this week's URLs, and each has at least one section that does not restate an existing page.) 3. Hold the throttle until Google sends clicks unprompted: Do not raise the cadence while the site depends on promotion to get visits. Wait until Search Console shows organic clicks arriving on published pages without new distribution pushes. (Check: The Search Console Performance report shows organic clicks in the last 28 days on URLs published before that period.) 4. Open the throttle gradually once the click signal exists: Increase output in small increments rather than jumping to a much higher daily rate, keeping the same originality gate on every new URL. (Check: The new weekly URL count is higher than the previous week's, and the Pages report shows the newly published URLs indexed rather than accumulating as Crawled - currently not indexed.) --- ## [Find information gain gaps in the top 10 search results](https://seo-mcp.io/t/find-information-gain-gaps-in-the-top-10-search-results) Audit what the top 10 Google results, relevant YouTube videos and user forums already say about your target keyword, then find the questions none of them answer. Quantify the pattern from a real sample and open the article with that original finding so the page offers something the existing results do not. Prerequisites: - A target keyword and its top 10 organic results - Access to a spreadsheet for logging sources and counts 1. Extract what the top 10 results cover: Scrape the top 10 Google results for the target keyword and record the claims, examples and questions each page covers. (Check: A sheet lists 10 result URLs with the claims, examples and questions found on each.) 2. Map what the videos add: Collect relevant YouTube videos for the keyword, pull their transcripts, and note the points they cover that the written results do not. (Check: The sheet contains a video block listing at least one transcript-derived point per video.) 3. Collect user questions and complaints: Scrape user questions, complaints and requests from forums, social media and review sites related to the topic. (Check: A raw list of user statements exists with the source URL recorded next to each one.) 4. Group and deduplicate the needs: Group repeated needs into themes, remove duplicates, and keep the source URLs and the sample count behind each group. (Check: Each theme row shows a count and at least one source URL.) 5. Compare against the ranking pages and your content: Compare the grouped needs with the ranking pages, the videos and your existing content to isolate the questions nobody answers. (Check: A shortlist of unanswered questions exists, each marked as absent from the 10 audited results.) 6. Quantify the pattern from the sample: Count the occurrences per theme and calculate percentages from the actual sample size; save the evidence behind each finding. (Check: Every percentage in the draft resolves to a count divided by a stated sample size.) 7. Lead the draft with the finding: Open the article with the original finding, explain how it was measured, then answer the unanswered question with useful detail. (Check: The first paragraph states the finding and the sample size before any general introduction.) 8. Log the SERP snapshot *(general best practice)*: General best practice: record the query, date and location used to capture the top 10 so the comparison can be repeated later. (Check: The sheet header shows the query string plus the capture date and country.) --- ## [Add topic-cluster internal links between related pages](https://seo-mcp.io/t/add-topic-cluster-internal-links-between-related-pages) Export every published URL and group it by topic and customer task. Pick one main guide and one product page per cluster, link the guide to supporting tutorials with return links where useful, and add contextual links to product and proof pages using descriptive anchor text. The result is a crawlable path from informational content to commercial pages. Prerequisites: - Access to edit page content in the CMS - An export of published URLs from the sitemap or a crawl 1. Export and group URLs by topic and customer task: Export every published URL from the sitemap or a crawl, then assign each URL to one topic cluster and one customer task in a spreadsheet. (Check: The spreadsheet has one row per published URL and no URL is assigned to more than one cluster.) 2. Choose the main guide and product page per cluster: For each cluster, select the page that best answers the core question as the main guide, and select the commercial page the cluster should support. (Check: Every cluster row contains one guide URL and one product URL.) 3. Link the guide to supporting tutorials and back: Add links from the main guide to each supporting tutorial, then add a return link from each tutorial to the guide where it helps the reader continue. (Check: The rendered guide HTML contains an href to each supporting tutorial, and each tutorial contains a link back to the guide.) 4. Add contextual links to product and proof pages: Inside relevant paragraphs, link to the product page and proof pages using anchor text that describes the destination rather than generic wording. (Check: Each new anchor names the destination topic or product, and the target URL returns HTTP 200.) 5. Have the agent draft source, destination and exact sentence: For every planned link, ask the agent to return the source URL, destination URL, anchor text and the exact sentence the link will sit in; review the plan before any edit is applied. (Check: The plan lists source URL, destination URL, anchor text and sentence for each link, and no link is published before review.) 6. Plan missing cluster pages and link them from existing articles: From the cluster gap analysis, list pages that are missing for a topic or customer task, then add links to each new page from the most relevant existing article as it is published. (Check: The gap list names each missing page, and every published gap page has at least one internal link from an existing article.) --- ## [Set up an AI SEO workspace brief before agent tasks](https://seo-mcp.io/t/set-up-an-ai-seo-workspace-brief-before-agent-tasks) Before asking an AI agent to work on SEO, save a brief with the product, buyer, country, pricing and conversion goal, add the page inventory, Search Console queries and real customer questions, then pick one product or service page to support. The agent gets enough context to make decisions that fit the business instead of generic advice. Prerequisites: - A verified Search Console property with query data - Access to the site's page inventory or sitemap - A folder or repository the agent can read and write 1. Write the business brief: Create one file in the shared workspace and record the product, the buyer, the target country, the pricing and the conversion goal in plain sentences the agent can quote. (Check: The file exists and contains a line for each of the five fields: product, buyer, country, pricing, conversion goal.) 2. Add the page inventory: List the site's existing pages grouped by template (product, integration, pricing, blog) with their URLs, rather than one flat dump. (Check: Every URL in the inventory returns HTTP 200 and the count matches the number of URLs in the sitemap file.) 3. Attach Search Console queries *(general best practice)*: Export queries from the Search Console Performance report and save them in the same folder so the agent can see what the site actually ranks for. (Check: The saved file has at least the columns query, clicks and impressions, with at least one row per target page.) 4. Collect customer questions: Pull recurring questions from support tickets, sales calls or onboarding emails and add them to the brief as the wording buyers use. (Check: The brief lists at least five verbatim customer questions.) 5. Choose one page to support: Pick a single product or service page as the target and record its URL in the brief as the page the next steps will work on. (Check: The brief contains a target page field holding one URL that returns HTTP 200.) 6. Keep all working files in one folder: Store research notes, screenshots and finished edits alongside the brief so the agent reads from and writes to a single location. (Check: The folder path is written into the agent's instructions and the agent can list its contents.) 7. Record the tools you will use: Note which assistant you use for research and writing, and which tools handle classification, recurring research or platform submissions, so the workflow is reproducible. (Check: The brief names one tool per task category with no empty entries.) --- ## [Use Google Search Console's AI Search Guidance to Win AI Traffic](https://seo-mcp.io/t/use-google-search-consoles-ai-search-guidance-to-win-ai) Google now surfaces guidance inside Search Console on how businesses can earn traffic from AI Search, and it reportedly shows whether a given business is included. The tip is to audit each verified property for that guidance, capture a performance baseline, and convert every recommendation into a tracked on-site task with a re-check date. Prerequisites: - Verified ownership of the property in Google Search Console - Access to the site's CMS or codebase to implement changes - A place to log tasks and change dates (docs, issue tracker, or sheet) 1. Locate the AI Search guidance in Search Console: Open Google Search Console for each verified property and look through the navigation and any in-product notices or recommendations panels for the AI Search guidance. Note the exact label and location you found it under so the rest of the team can find it again. (Check: You have written down the property name, the label of the section, and the date you saw it.) 2. Check whether your business is represented: Use the view Google provides to see whether your business appears in the AI Search context. Record the answer per property rather than a single site-wide yes or no, since results can differ by domain and subdomain. (Check: Each verified property has a recorded yes/no with a screenshot or note attached.) 3. Capture a performance baseline: Before changing anything, export or screenshot Search Console performance data (queries and pages, last 3-6 months) so you have a before-state to compare against. Store it somewhere versioned so it cannot be overwritten. (Check: A dated baseline file or export exists for every property you plan to act on.) 4. Turn each guidance item into a task: Take every recommendation Google lists and rewrite it as a concrete task: what changes, on which template or URL group, and who owns it. Vague items like 'improve content' should be broken down until someone could start today. (Check: Every guidance item maps to at least one task with an owner and an affected URL or template.) 5. Implement and log the changes: Ship the changes on-site (content, markup, structure, or access rules as applicable) and log the deployment date next to each task. Deployment dates are what make later comparison meaningful. (Check: Each completed task has a date and a link to the change or commit.) 6. Re-check Search Console on a schedule: Return to the same Search Console view at 30, 60, and 90 days. Note whether the guidance changed, whether your business is still represented, and how the numbers compare to your baseline. (Check: A comparison table exists with baseline versus 30/60/90-day figures and a short note on what changed.) --- ## [Submit a tool to the Altern directory for a dofollow backlink](https://seo-mcp.io/t/submit-a-tool-to-the-altern-directory-for-a-dofollow) Altern is a tool directory that lists products with an outbound link. Create an account, use the Add menu to submit your tool name and URL, and confirm the published listing exposes a followed link to your site. A relevant directory listing adds a small referring link and a discovery path readers use to find new tools. Prerequisites: - An account on the Altern directory - A live URL for your tool or product page 1. Register on the directory: Open the directory site linked in the tweet and create an account with a working email address so the listing can be claimed or edited later. (Check: You can log in and reach an account or dashboard page.) 2. Open the submit form: Use the Add button in the site menu to open the tool submission form. (Check: A form appears with fields for tool name and URL.) 3. Enter your tool name and URL: Add the product name and the specific URL you want to promote, such as a feature or pricing page, rather than the site root. (Check: The URL field contains the exact page you want linked and resolves without a redirect.) 4. Submit and check the live listing *(general best practice)*: Submit the form, then open the published listing and inspect the outbound link to your site. Confirm it is a plain anchor rather than a nofollow or redirected link. (Check: Viewing the listing page source shows your URL in an <a href> without rel="nofollow" and pointing directly at your domain.) --- ## [Programmatic SEO for Niche Job Boards: Templated Pages at Scale](https://seo-mcp.io/t/programmatic-seo-for-niche-job-boards-templated-pages-at) Generate templated listing pages from structured job data so every role-and-location combination has a crawlable URL, then invest in the technical SEO underneath it. Unique titles built from template fields, internal links from hub pages, fast list and detail templates and clean indexation are what turn the template set into rankings. The tactic transfers to any niche with repeating structured records; without that technical layer the generated pages stay thin. Prerequisites: - Structured job/listing dataset with consistent fields (title, location, category, employer) - Server-side or static rendering so page content appears in the initial HTML - Access to Google Search Console for the property - CMS or codebase able to generate pages from a template at scale 1. Define the page taxonomy *(general best practice)*: List the dimensions your inventory actually supports — e.g. job title × location, title × industry, title × seniority. For each combination count how many live listings exist. Only combinations above a minimum inventory threshold become published pages; the rest stay out of the index. (Check: You have a written list of every page template and a count of qualifying pages per template.) 2. Build indexable URLs and render content server-side *(general best practice)*: Generate a clean, stable URL pattern per template (e.g. /jobs/{title}/{location}). Ensure the listing content, headings and pagination links are present in the HTML response, not injected only after client-side JavaScript runs. (Check: Fetch a sample URL with curl (no JS) and confirm listings, H1 and internal links appear in the raw response.) 3. Generate unique titles, H1s and meta descriptions *(general best practice)*: Derive title tags, H1s and meta descriptions from the data fields rather than using one generic template string. Include the specific title and location, and add live-listing counts or salary signals where the data exists. (Check: Crawl 20 sample pages and confirm zero duplicate title tags or H1s across them.) 4. Wire internal links and hub pages *(general best practice)*: Connect generated pages through category and location hub pages plus related-links blocks, so no page is orphaned and every page sits within a few clicks of the homepage. (Check: A full crawl reports no orphan URLs and maximum click depth of three from the homepage.) 5. Segment XML sitemaps by template *(general best practice)*: Emit separate sitemaps per page type (titles, locations, individual listings) with lastmod values, reference them from a sitemap index, and submit in Search Console so indexing can be tracked per group. (Check: Search Console shows each sitemap submitted and reports discovered vs indexed counts per group.) 6. Gate thin and empty combinations *(general best practice)*: Return noindex or a 404/410 for template pages below the inventory threshold, and remove them from sitemaps so crawl budget is spent on pages that can rank. (Check: Search Console shows no soft 404s or 'crawled - currently not indexed' spikes on gated templates.) 7. Monitor performance by page group *(general best practice)*: In Search Console, filter Performance reports by page path pattern to compare impressions, clicks and CTR per template. Expand templates that earn impressions; prune or merge those that do not. (Check: You can produce a per-template impressions and clicks report for the last month.) --- ## [Shorten and clean URL slugs for on-page SEO](https://seo-mcp.io/t/shorten-and-clean-url-slugs-for-on-page-seo) Rewrite each page's URL slug to two or three lowercase, hyphen-separated words built around the primary keyword. Drop underscores, capital letters and dates or numbers that do not describe time-sensitive content. Cleaner slugs are easier to read in search results and restate the target keyword in the URL; apply the rule to new content and templates first. Prerequisites: - Access to the CMS or code that sets page URLs - Ability to add 301 redirects on the server or in the CMS 1. Flag slugs that break the rules: Export URLs from Search Console or a crawler and look for slugs containing underscores, uppercase letters, four or more words, or embedded dates and numbers that are not part of the topic. (Check: The exported URL list is filtered to a set of slugs containing at least one underscore, capital letter or date segment.) 2. Rewrite the slug to two or three words: Build the new slug from the primary keyword plus at most two supporting words, lowercase only, separated by single hyphens, with dates and arbitrary numbers removed unless the content is date-specific. (Check: The new slug matches the pattern ^[a-z0-9]+(-[a-z0-9]+)*$ and contains no underscore or uppercase character.) 3. Set the slug before publishing new pages: For new content, set the slug in the CMS URL field before the first publish so no redirect is ever needed, and apply the same rule in page templates and programmatic URL generators. (Check: The preview or draft URL in the browser address bar shows the clean lowercase hyphenated slug.) 4. Redirect changed URLs *(general best practice)*: When an existing live slug changes, add a single 301 redirect from the old path to the new one and keep the old URL out of the sitemap. (Check: curl -I your production domain/old-slug/ returns HTTP/1.1 301 with a Location header pointing at the new slug.) 5. Update internal links and the sitemap *(general best practice)*: Replace internal links that point at the old slug and regenerate the sitemap so it lists only the new URL. (Check: The regenerated sitemap.xml contains the new slug and no occurrence of the old slug; a site: search for the old path returns no internal pages linking to it.) --- ## [Audit SERPs for parasite platforms outranking your own pages](https://seo-mcp.io/t/audit-serps-for-parasite-platforms-outranking-your-own-pages) Third-party hosted pages such as Spotify episodes, Jimdo and Site123 sites can outrank a brand's own pages on its target keywords. Export your keyword set with top rankings, match result domains against a maintained list of strong parasite platforms, then decide per keyword whether to publish on that platform or strengthen your own URL. Prerequisites: - A defined keyword list tied to commercial or brand pages - Access to current top-10 ranking data (rank tracker export or Search Console performance export) - A spreadsheet or script environment to run the domain matching 1. Export keywords with their top results: Pull your target keyword list with the current top-10 URLs and positions from your rank tracker, or export the Queries and Pages data from Search Console as a starting point. Keep one row per keyword-result pair so domains can be matched programmatically. (Check: Open the export and confirm it contains at least keyword, position and URL columns with no empty rows.) 2. Build and store a parasite platform list: Create a maintained list of hosted platforms that let outsiders publish and rank. Start with the three named in the tweet (Spotify episodes, Jimdo, Site123) and add any other UGC or site-builder hosts you see recurring in your niche. Store it in a config file so it can be extended later. (Check: Every domain in the config file resolves to a real site and the list loads without parse errors.) 3. Match result domains against the list: Run the export through a script that checks each result URL's registrable domain against the platform list. Output only the keywords where a matched platform ranks above your own URL, including its position and your position. (Check: Spot-check three flagged keywords manually in a browser and confirm the platform page really appears above your page.) 4. Decide claim or defend per keyword: For each flagged keyword, record whether you will publish a presence on that platform or improve your own page. Prioritise keywords with commercial value; skip low-value informational queries. (Check: Every row in the output has a decision, an owner and a target date recorded.) 5. Execute and re-check on a cadence: Ship the chosen action, then re-run the same audit monthly so newly ranking hosted pages are caught early. Log the run date and the count of flagged keywords each time to track whether the exposure is shrinking. (Check: A run log exists with the latest date and flagged-keyword count, and the next run is scheduled.) --- ## [Create a dedicated reviews domain to earn AI review citations](https://seo-mcp.io/t/create-a-dedicated-reviews-domain-to-earn-ai-review) One practitioner reports that ChatGPT cites a dedicated brand-reviews domain (brandname + reviews) for review queries. If you hold genuine customer reviews, publish them there in crawlable HTML and link the site from your main product page, then check whether an assistant retrieves it for review questions. Prerequisites: - Budget to register a second domain - An existing base of customer reviews or testimonials you are allowed to publish - Ability to edit robots.txt and add structured data on the new domain 1. Record the baseline AI answer *(general best practice)*: Ask an assistant with web access for reviews of your product by name and save the URLs it cites today. This is the comparison point for later checks. (Check: A saved list of cited URLs for at least one review query exists.) 2. Register a reviews domain for the brand: Register a domain that combines your product name with "reviews" (for example yourbrandreviews.com) alongside your existing app domain. (Check: The registrar account lists the new domain and its DNS resolves to your hosting.) 3. Publish only reviews the user supplies *(general best practice)*: Ask the user for the reviews they can attribute, then publish them in crawlable server-rendered HTML, one page per product. Do not invent ratings, dates or review counts. (Check: View source of a review page contains the review text without JavaScript, and every review has a source the user supplied.) 4. Allow crawlers and link from the main site: Confirm the reviews domain's robots.txt does not block the review paths, then add one link from the matching product or about page on the main site. (Check: The reviews domain's /robots.txt has no Disallow for the review paths, and the main product page HTML contains the href.) 5. Re-run the baseline query after crawl: Once the pages are indexed, re-run the same review query and compare the cited URLs with the baseline. Report what actually appears and do not claim a citation that was not observed. (Check: The comparison lists the baseline URLs and the current URLs with an explicit match or no-match.) --- ## [Publish a Zapier integration page for a high-authority listing](https://seo-mcp.io/t/publish-a-zapier-integration-page-for-a-high-authority) Build and publish an integration listing on Zapier so your SaaS has a page on a high-authority domain targeting branded and use-case queries. Confirm the product has a working MCP server or API first, create the app on Zapier, submit it, then check that the public listing page is indexed. Prerequisites: - A SaaS product with a working MCP server or API Zapier can connect to - A Zapier account (the source states a free trial is sufficient) 1. Confirm the integration surface works: Make sure the product exposes a working MCP server, as the source requires, or an API that Zapier can authenticate against. Test one authenticated request before starting the listing. (Check: An authenticated test request to the MCP server or API returns a successful response with valid credentials.) 2. Create a Zapier account: Sign up for Zapier; according to the source, a free trial is enough to create an integration. (Check: You can sign in and reach the app creation area of the Zapier developer platform.) 3. Create the integration: Create a new app in Zapier, fill in authentication, and define at least one trigger or action that reflects a real use case for the product. (Check: Zapier shows the app in your developer dashboard with its authentication and at least one trigger or action configured.) 4. Write the public listing copy and submit for review *(general best practice)*: Add a description that names the product category and the specific tasks the integration automates, then submit the app so a public listing page is generated. (Check: A public URL on zapier.com for the app exists and loads without being logged in.) 5. Confirm the listing page is indexed *(general best practice)*: Run a site: search on zapier.com for the app name to see whether Google has indexed the listing, and re-check after a few days if it has not appeared. (Check: A site:zapier.com query containing the app name returns the integration page URL in the results.) --- ## [Corroborate the same verifiable facts across channels for LLM citations](https://seo-mcp.io/t/corroborate-the-same-verifiable-facts-across-channels-for) Publish a post built on verifiable facts with primary sources, then repeat those same facts on YouTube, social media, press releases and internal links from older posts. Consistent corroboration across independent places on the web gives language models more evidence to trust and cite the claim. Prerequisites: - A blog you can publish to - Primary sources (studies, data, documentation) for the facts you will state - Social and YouTube accounts for the brand 1. Choose facts that can be verified: Pick a topic where you can state concrete, checkable facts such as numbers, dates or specifications, and collect a primary source URL for each one. Write each fact as a short, quotable sentence you will reuse verbatim. (Check: Your draft lists at least three facts, each with a primary source URL next to it.) 2. Publish the facts on the blog: Write the post around those facts, stating each one plainly and linking out to its primary source so a reader or a model can check it. (Check: The published URL returns HTTP 200 and its HTML contains the fact sentence plus at least one outbound link to the primary source.) 3. Link from older posts that mention the same facts: Find existing posts covering the same subject and add a contextual internal link from them to the new post, ideally in the paragraph where the fact appears. (Check: View-source of each linking post contains an href to the new URL, and the Search Console Links report lists the new post as an internal link target.) 4. Cover the same facts in a YouTube video: Record a video that states the identical facts and figures, and put the blog post URL and the same numbers in the description. (Check: The video is public and its description contains the post URL and the same figures used in the post.) 5. Share the post on social profiles: Post the link and the key fact on the brand's social accounts so the claim exists on profiles that link back to the source page. (Check: Each share has a public URL that loads without login and contains the fact and the link to the post.) 6. Distribute press releases carrying the same facts: Send releases that repeat the identical facts and figures, and treat any links in syndicated copies as promotional rather than as link equity. (Check: At least one syndicated copy of the release is live at a public URL and contains the same figures as the post.) 7. Check the facts match across every asset *(general best practice)*: General best practice: compare the fact sentences on the blog, video description, social posts and release, and make the wording and numbers identical so the corroboration holds. (Check: A text diff or manual side-by-side of the four assets shows no difference in the figures and the fact wording.) 8. Confirm AI crawlers can fetch the pages *(general best practice)*: General best practice: check robots.txt for rules that disallow AI crawlers, then ask an assistant about the fact and see whether the page is retrieved or cited. (Check: A GET request to your production domain/robots.txt shows no Disallow for the crawler groups you rely on, and the citation test returns your URL or is logged as a negative result to recheck later.) --- ## [Build a Reusable Local SEO Page Template for Every Location](https://seo-mcp.io/t/build-a-reusable-local-seo-page-template-for-every-location) A reusable template keeps every location and service-area page consistent: one NAP block, one title pattern, LocalBusiness schema and fixed internal links. The local SEO template set shared by BowTiedBills follows a repeatable setup he credits for taking 50+ businesses to first place on Google. Standardizing means each new page ships complete rather than missing schema or citations. Prerequisites: - CMS or codebase access to create or edit page templates - Google Business Profile access for each location to confirm NAP data - A list of locations and/or service areas to publish 1. List the fields every location page must carry: Audit two or three existing location pages and write down the fields that must appear on all of them: business name, street address, phone, opening hours, list of services, service area, map or directions link, reviews, and a contact CTA. Keep this as a single checklist document that the template will enforce. (Check: The checklist exists and you can score each live location page against it, noting which fields are missing.) 2. Codify the checklist as a page template: Turn the checklist into a layout or component with defined slots, so the NAP block, hours block, services list and CTA render from data rather than being hand-typed per page. Store location data in one source file or CMS collection that every page reads from. (Check: Create one test location page purely from the template with no manual field edits, and confirm every checklist field renders.) 3. Set a single title and meta pattern: Define one pattern for the template, for example {Service} in {City} | {Brand}, and generate it from the same location data. This prevents each page being titled differently and keeps the city and service in the tag naturally. (Check: Generate titles for three sample locations and confirm each renders the expected service, city and brand in the correct order.) 4. Add LocalBusiness structured data to the template: Include a LocalBusiness or appropriate subtype JSON-LD block in the template, populated from the same location data: name, address, telephone, openingHoursSpecification, areaServed, url and sameAs. Emit one block per location page, not a sitewide block. (Check: Run a published page through a structured data validator or Rich Results Test and confirm the LocalBusiness entity is detected with no errors.) 5. Align NAP with the Google Business Profile: Compare the name, address and phone rendered by the template against the Google Business Profile for that location and against any existing citations. Fix mismatches at the data source so every page inherits the corrected values. (Check: A side-by-side diff of the page NAP and the GBP NAP shows no differences in name, street address or phone number.) 6. Wire the internal link pattern into the template: Have the template output contextual links to the relevant parent service pages and to two to four nearby locations, and add links from service pages down to the location pages. This keeps new pages connected without manual editing. (Check: Crawl or inspect the rendered HTML of a new location page and confirm it contains the expected outbound service and nearby-location links plus at least one inbound internal link.) 7. Publish and submit for indexing: Ship the templated pages, confirm they appear in the sitemap, and submit them in Search Console. Track impressions and queries per location page to see whether the templated pages earn local visibility. (Check: Each new location URL appears in the sitemap file and is reported as discovered or indexed in Search Console within a few weeks.) --- ## [Allow AI crawlers in robots.txt so ChatGPT can cite the site](https://seo-mcp.io/t/allow-ai-crawlers-in-robots-txt-so-chatgpt-can-cite-the-site) Review robots.txt for Disallow rules aimed at AI crawler user agents, which many sites added in 2024, and replace them with explicit Allow rules for the pages you want cited. Then check that your CDN or WAF does not block the same bots at the edge, since a robots.txt fix alone will not help if the request never reaches the origin. Prerequisites: - Access to the robots.txt file at the site root - Access to CDN or WAF bot-management settings if one is in use 1. Open the live robots.txt: Fetch the robots.txt served on the production host, not a local copy, so CDN or app rewrites are included. (Check: A GET request to your production domain/robots.txt returns HTTP 200 with a text/plain content type.) 2. Find AI crawler groups: Scan the file for user-agent groups naming OpenAI's crawlers and for any global Disallow that would also catch them. (Check: The file lists user-agent lines such as GPTBot, OAI-SearchBot or ChatGPT-User, each followed by its rules.) 3. Replace blocks with explicit allow rules *(general best practice)*: Remove the Disallow under each AI crawler group you want to admit and add an Allow for the paths that should be readable, keeping unrelated bots untouched. (Check: robots.txt contains an Allow: / line under the target user-agent group and no Disallow: / for that group.) 4. Check CDN and WAF bot rules *(general best practice)*: Inspect the CDN or WAF dashboard for a managed rule or toggle that blocks AI bots or verified bots, and disable it for the hosts you want crawled. (Check: The bot-management setting shows AI bot blocking disabled for the production hostname.) 5. Confirm the crawler sees the allowed file *(general best practice)*: Re-fetch robots.txt from a different network or with a crawler user-agent header and compare it with what a browser sees. (Check: curl -A "OAI-SearchBot" your production domain/robots.txt returns the same Allow rules as the browser fetch.) --- ## [Add sameAs Markup to Link TikTok, Instagram and YouTube](https://seo-mcp.io/t/add-sameas-markup-to-link-tiktok-instagram-and-youtube) Adding the sameAs property to a site's Organization or Person structured data tells Google which TikTok, Instagram and YouTube profiles belong to the brand. The change takes minutes, costs nothing, and connects off-site social profiles to the entity the website already describes, giving Google an explicit link between the site and its social presence. Prerequisites: - Ability to edit the site-wide head/template or a global JSON-LD include - Live, public TikTok, Instagram and YouTube profiles owned by the brand - The canonical URLs of each profile, without tracking parameters 1. Collect the canonical profile URLs: Write down the exact public URL of each brand profile on TikTok, Instagram and YouTube. Use the plain profile URL (e.g. `https://www.tiktok.com/@brand`), not a shortened link, share link or a URL carrying `?utm_` parameters. Only include accounts the brand actually owns and maintains. (Check: Open every URL in a private browser window; each one must load the correct public profile while logged out.) 2. Add a single Organization/Person JSON-LD node with sameAs: In the site-wide head template (layout, header include, or theme functions file), output one JSON-LD block of `@type: Organization` (or `Person` for a personal brand) containing `name`, `url` and a `sameAs` array of the profile URLs. If an Organization node already exists, add `sameAs` to it instead of creating a second node. (Check: View page source and confirm exactly one Organization/Person JSON-LD block exists and that `sameAs` is an array of full absolute URLs.) 3. Use absolute, canonical URLs and keep the list short: Every entry in `sameAs` must be an absolute `https://` URL. Do not add trailing slashes, tracking parameters or duplicate entries. Exclude private, regional, inactive or partner accounts; a short accurate list beats a long noisy one. (Check: Inspect the rendered JSON-LD and confirm no relative URLs, no query strings and no duplicates are present.) 4. Deploy and validate the markup: Publish the change, then run a representative URL from each template (homepage, a post or product page, a landing page) through Google's Rich Results Test and the Schema Markup Validator. Fix any parsing errors before considering the task done. (Check: Both validators return no errors, and the sameAs array is visible in the parsed output for each template tested.) 5. Monitor the result in Search Console: After Google recrawls the URLs, check the Enhancements/structured data reporting in Search Console and watch whether the brand's social profiles begin appearing in Discover or profile-related surfaces over the following weeks. Record the change date so any movement can be attributed. (Check: The affected URLs are indexed with the new markup (URL Inspection shows it was fetched after the deploy) and no new structured-data errors appear in Search Console.) --- ## [Target buying-intent questions instead of beginner SEO content](https://seo-mcp.io/t/target-buying-intent-questions-instead-of-beginner-seo) Software sites often publish content aimed at beginners who are still learning a topic. Instead, list the questions a buyer asks while comparing options, then build or rewrite pages that answer each one so the site is eligible to be found and cited when someone is ready to choose. Prerequisites: - Access to the site's content plan or CMS - A source of real buyer questions such as sales calls or support tickets 1. List the questions asked while choosing: Write down the questions people ask when they are selecting a tool in your category rather than learning the topic: pricing comparisons, alternatives, whether a tool fits a specific use case, and switching concerns. Pull them from sales calls, support tickets and the prompts prospects say they type into assistants. (Check: A written list of at least ten decision-stage questions exists, each phrased as a real query rather than a topic label.) 2. Audit existing content aimed at learners *(general best practice)*: List published posts whose titles target learning phrasing such as what is, introduction to, or how to learn. Mark each one as keep, consolidate or rewrite depending on whether it can answer a decision-stage question. (Check: A spreadsheet lists every existing post with a target query and a keep/consolidate/rewrite decision.) 3. Create or rewrite one page per decision question *(general best practice)*: Give each question its own page that answers it directly in the opening section, then supports the answer with pricing, fit, limitations and a comparison against the alternatives a buyer would consider. (Check: Each new or rewritten URL answers its question in the first paragraph and contains at least one comparison element such as a feature or pricing table.) 4. Link the decision pages from the learning content *(general best practice)*: Add contextual internal links from the beginner posts to the matching decision pages so existing traffic is routed toward the buying content. (Check: View-source of the beginner posts shows an in-body link to the corresponding decision page with descriptive anchor text.) 5. Check indexing and query performance *(general best practice)*: Request indexing for the new URLs, then watch the query report for the question phrasing and test the assistant directly by asking the question. (Check: Search Console Pages report shows the new URL as Indexed and Performance > Queries filtered on the question phrase shows impressions; asking ChatGPT the same question returns the URL or a citation.) --- ## [List your SaaS in the Official MCP Registry](https://seo-mcp.io/t/list-your-saas-in-the-official-mcp-registry) Publish a live remote MCP server to the Official MCP Registry so agents and directories that query it can discover your product. Install the publisher CLI, authenticate, submit the server entry, then confirm the listing resolves to your endpoint. The real cost is having a working remote server; the submission itself is quick. Prerequisites: - A publicly reachable remote MCP server endpoint - Homebrew installed on macOS or Linux - An account for the Official MCP Registry (GitHub authentication is typical) 1. Confirm the remote MCP server responds: Send an MCP initialize request to your public endpoint and check that it answers with a JSON-RPC result containing serverInfo. (Check: The curl request returns HTTP 200 and a JSON body with a result.serverInfo object.) 2. Install the publisher CLI: Install mcp-publisher with Homebrew as described in the tweet. (Check: `mcp-publisher --help` exits with status 0 and prints the available subcommands.) 3. Authenticate the CLI *(general best practice)*: General best practice: sign the CLI in to the registry account (typically GitHub-based) before any publish attempt, so the submission is attributed to your organisation. (Check: The CLI reports a signed-in account or writes a credentials file, and no authentication error is returned.) 4. Publish the server entry *(general best practice)*: General best practice: run the publish flow from the repository that holds the server manifest, with the name, short description, repository URL and the public remote endpoint filled in. (Check: The CLI prints a success message naming the published server, with no validation errors.) 5. Check the public listing *(general best practice)*: Open the registry page for your server and confirm the description, repository link and endpoint are correct and that search on the registry finds it by name. (Check: The registry page for your server returns HTTP 200, shows your remote endpoint, and the site name is returned in registry search results.) --- ## [Mine question-format queries with site: searches](https://seo-mcp.io/t/mine-question-format-queries-with-site-searches) Restrict a Google search to one platform with the site: operator and combine it with quoted question phrases plus your niche. The results list pages where people already phrase the problem your app solves, giving you real question wording to answer on your own pages instead of guessed keywords. Prerequisites: - A web browser to resolve the shortened link - A defined niche term for your app 1. Resolve the domain the operator targets: Open the shortened link from the tweet in a browser and read the domain in the address bar. That domain is what the site: operator must be restricted to. (Check: The address bar shows the resolved destination domain instead of the t.co shortlink.) 2. Run the first question search: Paste the operator with the resolved domain, the quoted phrase and your niche term into Google. (Check: Results are pages on the resolved domain that contain the exact phrase plus your niche term.) 3. Run the second question search: Repeat with the second quoted phrase to capture a different question pattern. (Check: Results are pages on the resolved domain that contain "any app for" plus your niche term.) 4. Log the recurring phrasings *(general best practice)*: Copy each distinct question wording and its URL into a sheet, grouping near-duplicates into one cluster. (Check: The sheet holds at least ten distinct question phrasings, each with a source URL.) 5. Answer the questions on your own pages *(general best practice)*: Pick the pages that should rank for each cluster, add the question as a heading and follow it with a short direct answer in text, not an image. (Check: Fetching the page returns 200, the head has no noindex, and the question text appears in the rendered HTML as a heading.) --- ## [Find sites using Stripe Checkout via Similarweb referrals](https://seo-mcp.io/t/find-sites-using-stripe-checkout-via-similarweb-referrals) Open Similarweb, search checkout.stripe.com and open Referral -> Incoming Traffic. The referring websites are products that sell through Stripe Checkout. Take the interesting domains into Semrush -> Organic Rankings -> Positions to see which non-brand keywords bring them search traffic, then study what they sell, how they price and how they acquire demand. Prerequisites: - A Similarweb account that can open the Referral report (the free tier shows limited rows) - A Semrush account for the Organic Rankings -> Positions report 1. Search checkout.stripe.com in Similarweb: Open Similarweb and look up checkout.stripe.com. This is the shared checkout domain many products use, so its referral traffic is a list of sites pointing shoppers at Stripe cashiers. (Check: The Similarweb domain overview for checkout.stripe.com loads and shows a Referral section.) 2. Open Referral and Incoming Traffic: Go to Referral -> Incoming Traffic and read the Referring websites list. Page through several pages: smaller vertical product sites show up deeper in the list and are often the more interesting leads. (Check: The Referring websites table lists at least ten domains, including small vertical sites, not only marketplaces.) 3. Shortlist the product sites worth studying: Pick the referring websites that look like real products rather than payment platforms or test domains. Record each domain and what it appears to sell before opening another tool. (Check: The shortlist has one row per candidate with the domain and a one-line description of the product.) 4. Read their organic keywords in Semrush: For each shortlisted domain, open Semrush -> Organic Rankings -> Positions and sort by traffic. Look for the non-brand keywords that bring search demand; a domain with no organic traffic is a weak lead even if it sells well. (Check: Every shortlisted domain has a Semrush Positions screenshot or exported row set showing its top non-brand keywords.) 5. Combine offer, pricing and acquisition: Put what the product sells, its pricing and its acquisition keywords side by side. A pattern across several leads - a niche, a price point, a keyword family - is a stronger opportunity than a raw list of websites. (Check: The notes compare at least three leads on product, price and top keyword family.) 6. Treat referrals as leads, not revenue: Referral traffic does not equal sales. Do not estimate revenue from this data; use it only to shortlist leads and to support a judgment about a niche. (Check: The final notes contain no revenue estimate derived from referral traffic, only lead qualification.) --- ## [List a SaaS MCP server in the Official MCP Registry and Glama](https://seo-mcp.io/t/list-a-saas-mcp-server-in-the-official-mcp-registry-and) Publish the product's remote MCP server to the Official MCP Registry using the publisher CLI, then confirm the entry appears and that Glama has imported it. The result is a directory listing and an additional branded mention that surfaces the product to people browsing MCP tooling. Prerequisites: - A remote MCP server live and reachable for the product - Homebrew installed for the publisher CLI - Access to the registry publishing documentation 1. Confirm a remote MCP server is live: Make sure the product exposes a remote MCP server endpoint that external clients can reach without an invite. A local-only server cannot be published to a public registry. (Check: Calling the server endpoint from outside your network returns an MCP protocol response rather than a connection error or login page.) 2. Install the publisher CLI: Install the registry's publisher CLI with Homebrew. (Check: `mcp-publisher --help` prints usage information instead of a command-not-found error.) 3. Publish the server to the Official MCP Registry: Run the publish flow documented in the registry's publishing guide, filling in the server name, description and the public endpoint URL. (Check: Searching the Official MCP Registry for your server name returns an entry whose endpoint matches the live URL.) 4. Check that Glama imported the connector: The source says Glama pulls connectors from the registry itself, so no separate submission is needed. Search Glama for the product name after the import window. (Check: A Glama listing page exists for the product and links to the intended site URL.) 5. Align the listing details with the site *(general best practice)*: If the listing is editable, set the product name, description and link to match the canonical product page used elsewhere, then re-check the live listing. (Check: The listing's outbound link resolves to the canonical product URL with a 200 status.) --- ## [Build a keyword-targeted free tool page with on-page SEO](https://seo-mcp.io/t/build-a-keyword-targeted-free-tool-page-with-on-page-seo) Create a small free tool aimed at a single keyword: no signup, result shown instantly, mobile-friendly layout, one call to action into the product. Then complete the page's on-page SEO with a keyword-led title, meta description, H1, an FAQ block, JSON-LD schema and internal links from relevant pages. Prerequisites: - A product URL and a chosen target keyword - Ability to deploy a new page or template on the site - Access to Claude Code or a comparable code-generation tool 1. Choose the keyword and the tool output: Pick one keyword with tool-shaped intent (a calculator, checker, converter or generator) and write down the single input the visitor gives and the result the page returns. (Check: A one-line spec exists naming the target keyword, the input field and the output the page renders.) 2. Build the tool so the result needs no signup: Implement the tool so the result appears immediately after the input, with a mobile-first layout and exactly one call to action pointing at the product. (Check: Loading the page on a phone-width viewport returns a result without a login wall and shows exactly one product CTA link.) 3. Add the on-page elements: Set a title tag and meta description containing the target keyword, one H1 that names the tool, and short copy explaining the result plus an FAQ block answering related questions. (Check: View-source shows a unique title tag, a meta description, exactly one H1 and at least three visible FAQ questions.) 4. Add JSON-LD structured data *(general best practice)*: Mark the page up as a WebApplication or SoftwareApplication whose name and description match the visible H1 and copy. (Check: The Rich Results Test or Schema Markup Validator parses the page without errors and reports the application type.) 5. Link to the tool from related pages: Add contextual internal links to the tool page from the most relevant product, blog or documentation pages, using descriptive anchor text that includes the keyword. (Check: A site: search or a crawl shows at least three internal links pointing at the tool URL with non-generic anchors.) 6. Validate and request indexing *(general best practice)*: Check the canonical tag is self-referencing, confirm the page is reachable in robots.txt, then submit the URL in Search Console. (Check: Search Console URL Inspection reports the URL as crawled and indexed, and the page source shows a self-referencing rel=canonical.) --- ## [Get a dofollow backlink from the EarlyHunt launch directory](https://seo-mcp.io/t/get-a-dofollow-backlink-from-the-earlyhunt-launch-directory) Create an EarlyHunt account, open the Launch form and submit your product with its URL so the tool gets listed. The listing carries a link back to your site, adding a relevant directory placement to your backlink profile. Confirm the listing is live and the link is actually dofollow before counting it. Prerequisites: - A live product or tool page with a public URL - An email address to register an EarlyHunt account 1. Create an EarlyHunt account: Register on EarlyHunt with a working email address and complete the confirmation step so the submission form becomes available. (Check: You can sign in and reach your account dashboard without an unverified-email prompt.) 2. Open the Launch submission form: From the main menu, select the Launch option to open the product submission form. (Check: The Launch page displays fields for product name, description and URL.) 3. Add product details and the target URL: Fill in the product name, a short description and the exact URL you want the link to point at. Prefer a dedicated product or feature page over the homepage when one exists, so the link is topically relevant. (Check: The URL field contains the full https:// address of the intended page and the form shows no validation error.) 4. Submit the tool: Send the form and wait for the listing to be published, which the source says happens shortly after submission. (Check: A confirmation message appears and the submission is visible in your account as pending or live.) 5. Confirm the live link is dofollow *(general best practice)*: Open the published listing page and inspect the link markup to your domain. A dofollow link has no rel="nofollow" or rel="sponsored" attribute. If the link is nofollow, the placement still brings referral traffic but no link equity. (Check: Fetching the listing page and searching the HTML for your domain returns an anchor tag without rel="nofollow" or rel="sponsored".) 6. Record the listing for later checks *(general best practice)*: Add the live listing URL to your backlink tracker so you can re-check the link attribute and status during future audits, since directories sometimes change outbound link policies. (Check: The tracker row contains the listing URL, the target page and a status field marked live and dofollow.) --- ## [Publish a keyword-named Google Sites page for parasite SEO](https://seo-mcp.io/t/publish-a-keyword-named-google-sites-page-for-parasite-seo) Create a Google Sites page whose site name and page title match the exact target keyword, publish it with genuinely useful content, and link it back to your own domain. The tweet claims Google-hosted properties get indexed fast, so the page can surface for the term ahead of your own page. Treat it as a limited gray tactic. Prerequisites: - A Google account - One exact target keyword chosen - Content that is not copied from your own site 1. Create a Google Site named after the exact keyword: In Google Sites, create a new site and set the site name (which becomes part of the sites.google.com/view/ URL) to the exact target keyword rather than a brand name. (Check: The published URL reads sites.google.com/view/<your-keyword> and the site header shows the keyword verbatim.) 2. Add a matching page title, heading and substantive content *(general best practice)*: Set the page title and the visible H1 to the keyword, then write a self-contained page that answers the query instead of duplicating an existing article from your main site. (Check: View source shows the keyword inside the <title> element and inside an <h1>; the page body is unique text, not a copy of your own article.) 3. Publish with search visibility enabled *(general best practice)*: Publish the site and confirm the 'Request public search engines to not display my site' option is unchecked, since it adds a noindex directive. (Check: Fetch the published URL in a logged-out browser and confirm the response contains no <meta name="robots" content="noindex">.) 4. Link the hosted page to your own target page *(general best practice)*: Add one contextual link from the Google Sites page to the page on your domain you want visitors to reach. (Check: The published page contains an anchor element whose href is the full https URL of your own page.) 5. Publish a Google Doc as a second test: Publish a short document through File > Share > Publish to web and keep it publicly accessible, as the tweet reports Google Docs being indexed quickly. (Check: The docs.google.com published URL loads in a logged-out browser and shows the document content.) 6. Confirm indexing with a site: query *(general best practice)*: After a few days, check whether Google has indexed the hosted URLs before investing further in the tactic. (Check: Search results for the site: query return the published URL.) --- ## [Publish a Chrome extension to earn a branded store listing](https://seo-mcp.io/t/publish-a-chrome-extension-to-earn-a-branded-store-listing) Build a small browser extension that fits your product, publish it to the Chrome Web Store, and make sure the listing's website field points at your domain. The result is a branded page on a high-authority platform, a link to your site, referral traffic, and one more place your brand appears in search. Prerequisites: - A Google account for the Chrome Web Store developer dashboard - A working extension build for Chrome - Access to your site's analytics to track referrals 1. Choose one small job the extension does: Pick a single task your audience already does manually and that connects to your product, so the extension has a reason to exist beyond the listing. (Check: You can describe the extension's one function in a sentence and name the audience it serves.) 2. Build the extension with a minimal manifest *(general best practice)*: Create a Manifest V3 extension with the smallest permission set the feature needs, and set the homepage_url field to your site so the installed extension points back to you. (Check: chrome://extensions loads the unpacked extension without errors and the manifest shows only the permissions the feature uses.) 3. Fill in the listing's website field *(general best practice)*: In the developer dashboard, complete the store listing with an accurate name, description and screenshots, and put your site URL in the website/homepage field plus a support URL. (Check: The published listing page shows a website link whose href is your domain.) 4. Submit for review and publish *(general best practice)*: Upload the package, complete the developer verification the dashboard requires, and submit; address any review feedback about permissions or metadata. (Check: The developer dashboard shows the item status as published and the public listing URL resolves.) 5. Link to the listing from your site *(general best practice)*: Add a link to the Chrome Web Store listing from a relevant page on your site, such as a tools or integrations page, so visitors and crawlers can find it. (Check: The page on your site contains an anchor whose href is the chromewebstore.google.com listing URL and the link returns 200.) 6. Measure referrals *(general best practice)*: Tag the listing's outbound links or check your analytics for traffic whose source is the Chrome Web Store, then compare installs and conversions over the first weeks. (Check: Your analytics referral report lists chromewebstore.google.com as a source, or the campaign-tagged landing page shows sessions.) --- ## [Publish competitor comparison pages as direct answers](https://seo-mcp.io/t/publish-competitor-comparison-pages-as-direct-answers) Create a dedicated page for every head-to-head comparison buyers search (your tool vs each alternative) and open each page with a short, direct answer before any tables or feature lists. This makes the page easy for both searchers and AI assistants to extract and quote when someone asks which tool to pick. Prerequisites: - Ability to publish new blog posts on the site - A list of the competitor products buyers compare you against 1. List the pairings to cover: Write down every alternative your buyers evaluate you against and create one page per pairing, named after the query pattern "your product vs competitor". Use the naming pattern the source cites as an example of per-competitor comparison posts. (Check: A list exists with one intended page per named competitor, each mapped to a "<your product> vs <competitor>" URL slug.) 2. Open each page with the direct answer: Start the page with a short paragraph that answers the comparison question outright, naming both products and stating who each one suits, before any table, image or feature list. (Check: Fetching the page source shows the answer paragraph as the first body-text block, before the first <table> or <img> tag.) 3. Add the comparison body *(general best practice)*: Follow the answer with a structured breakdown: pricing, key features, limits and a short verdict section. Keep each claim specific and attributable rather than promotional. (Check: The page contains a pricing row, a feature row and a verdict heading, each naming both products.) 4. Internal-link the new pages *(general best practice)*: Link each comparison page from the blog index, the pricing page and any related posts so it is crawlable within a couple of clicks of the homepage. (Check: A site: search or crawl report shows the comparison URL reachable from the pricing page with a followable anchor.) 5. Check extractability *(general best practice)*: Confirm the direct answer survives without JavaScript and is not hidden behind tabs or accordions, since assistants and crawlers may not render them. (Check: curl -s <comparison URL> | grep -i "vs" returns the answer sentence in the raw HTML response.) --- ## [Mine Similarweb subdomain reports for new keyword ideas](https://seo-mcp.io/t/mine-similarweb-subdomain-reports-for-new-keyword-ideas) Open Similarweb, search vercel.app, and open the Organic landing pages report. Set the range to the last 1 to 12 months and tick "newly discovered" to list subdomains that recently started ranking; each one is a live niche test. Validate the queries it ranks for in Google Trends before building your own page. Prerequisites: - A Similarweb account (free tier gives limited data) 1. Search vercel.app in Similarweb: Open Similarweb and search for vercel.app in the domain field, then load the website overview page. (Check: The Similarweb website page for vercel.app loads with a traffic chart and the report sidebar.) 2. Open the Organic landing pages report: Inside the vercel.app website view, open the Organic landing pages report so the subdomains receiving organic traffic are listed. (Check: The Organic landing pages table lists *.vercel.app hostnames with a traffic column.) 3. Set the last 1 to 12 months and tick newly discovered: Choose a date range covering the last 1 to 12 months, then tick the "newly discovered" filter so only pages that started ranking in that window remain. (Check: The report shows the newly-discovered filter active and the selected date range echoed in the toolbar.) 4. Extract the newly discovered landing pages: Export or copy the filtered rows. For each subdomain, note the product or topic it appears to target before moving on. (Check: The exported list contains only hostnames that appear after the date-range and newly-discovered filters are applied.) 5. Validate the keywords in Google Trends: Open Google Trends for the terms the subdomain appears to rank for, check interest over time and the regional breakdown, and keep only terms with real demand in your market. (Check: Google Trends shows a non-zero interest line for the term and Google returns relevant competing results for it.) --- ## [Rank a Facebook post for a buyer question](https://seo-mcp.io/t/rank-a-facebook-post-for-a-buyer-question) Turn a question your buyers ask into a Facebook post: open with the answer in the first line, add a line that invites disagreement to pull comments, then share the post to seed engagement. Question-shaped posts can surface in search results for that query and give the brand visibility outside its own domain. Prerequisites: - A Facebook page you manage - A question your buyers actually search for 1. Pick a question your buyers ask: Choose one question prospects type into search or ask in sales conversations. Keep it question-shaped and specific enough that a single post can fully answer it. (Check: The exact question returns related searches or recorded volume in a keyword tool.) 2. Write the answer as the first line: Make the opening sentence the complete answer, with no greeting, teaser or context before it. Add the supporting detail below. (Check: The first visible line of the published post is a complete answer in one sentence.) 3. Add a challenge line to invite disagreement: Close the post with a direct invitation for readers to argue or share a different view, so the comment thread has a reason to start. (Check: The post text ends with a challenge sentence and commenting is enabled on the page.) 4. Share the post to seed engagement: Share the post link through your other channels and communities so the first comments arrive early and the post gains visible activity. (Check: The post shows at least one comment and a non-zero share count within the first day.) 5. Check whether the post is indexed *(general best practice)*: After a few days, search for the exact question phrasing to see whether the post is picked up, and reply to comments in the meantime to keep the thread active. (Check: A Google search for site:facebook.com "<exact question phrase>" returns the post URL.) --- ## [Find internal linking opportunities with a site: search](https://seo-mcp.io/t/find-internal-linking-opportunities-with-a-site-search) Run a Google site: search for your domain with the target keyword in quotes. The results are pages on your site that already discuss the topic, so they are candidates for contextual internal links to the page you want to rank. Adding those links spreads relevance and helps crawlers discover related pages. Prerequisites: - The site is indexed by Google - A keyword or topic phrase for the target page 1. Run the site: search for one topic: In Google, type the site: operator joined directly to your domain with no space, then the topic in double quotes. The quotes force an exact-phrase match so the results are pages that really discuss it. (Check: The results page shows only URLs on your domain, and each result snippet contains the quoted phrase.) 2. Record the resulting URLs: Copy the URLs from the first few pages of results into a sheet next to the keyword. Repeat step 1 for each priority topic so you end up with a topic-to-source-pages map. (Check: The sheet has at least one row per topic, and every URL starts with your domain.) 3. Pick at least five sources per target page: For the page you want to rank, choose at least five indexed pages from the map that already discuss the topic. Five contextual links is the source's target, not a maximum. (Check: Each target topic in the sheet lists at least five source URLs, and each source appears in the site: results.) 4. Add the links inside body copy, never the footer: Edit each source page and add one contextual link to the target inside the paragraph that discusses the topic. Do not put these links in the footer or a sitewide sidebar block. (Check: grep -rn 'href="/target-page/"' <content-dir> returns one hit per edited source file and no hit in the footer template.) 5. Vary the anchor text (editorial note) *(general best practice)*: Where the sentence allows it, vary the anchor wording while keeping each anchor descriptive of the target. This keeps the link profile natural; the source recommends the exact keyword, so treat variation as an editorial improvement rather than the tweet's instruction. (Check: The five anchors are not identical, and each is descriptive enough to make sense out of context.) 6. Recheck coverage in Search Console *(general best practice)*: After deployment and a crawl, open the Search Console Links report for the target URL and confirm the new source pages appear as internal links. (Check: The target URL's internal links report lists the new source pages.) --- ## [Find SEO Wins Where Google Ranks the Wrong Content Type](https://seo-mcp.io/t/find-seo-wins-where-google-ranks-the-wrong-content-type) Find queries where Google's top results are the wrong content type, such as generic blog posts or forum threads for a commercial query. Classify the dominant format on each SERP, flag mismatches with the format you can realistically build, then publish the missing format and monitor rankings over the following weeks. Prerequisites: - A list of candidate queries (Search Console export or seed keyword list) - Ability to view live Google SERPs for your target country and language - Capacity to publish new pages or substantially rework existing ones 1. Build a candidate query list: Export queries from Search Console where you already rank roughly 5-20 (Performance report, filter by position), and add seed terms from your niche. Aim for 50-200 queries so the manual SERP review stays manageable. (Check: You have a spreadsheet with query, current position, impressions and clicks columns populated.) 2. Classify the dominant format on each SERP: For each query, open the live SERP in the target locale and note the format of the top 5-10 organic results: listicle, buying guide, category page, product page, forum thread, video, tool, or local pack. Record the count per format. (Check: Every row has a dominant_format value and the number of top results matching it.) 3. Flag intent mismatches: Mark a query as an opportunity when the dominant format is generic (broad roundups, forum threads) while the query implies a more specific need, or when no result in the ideal format ranks at all. (Check: Opportunity rows are flagged and sorted; each flag has a one-line note explaining what format is missing.) 4. Check demand and winnability: For each flagged query, confirm there is real search demand (autocomplete suggestions, related searches, Search Console impressions) and that you can build a genuinely better version of the missing format. (Check: Only queries with confirmed impressions or autocomplete presence remain on the shortlist.) 5. Define the page format before writing: Write the brief as a format decision: for a shelf-specific buying query, specify a comparison table with dimensions per shelf type; for a commercial query, specify a filtered category page rather than another blog post. (Check: The brief states the format, the sections required, and why it differs from the top-ranking pages.) 6. Publish and internally link: Publish the new page or rework the existing one so it fully replaces the weaker format, then add internal links from your most relevant existing pages using descriptive anchor text. (Check: The page is live, linked from at least two relevant pages, and returns a 200 status without indexation blocks.) 7. Monitor positions for 4-8 weeks: Track the flagged queries weekly in Search Console. Compare position and click-through against the pre-publish baseline before deciding to expand the format to more queries. (Check: A before/after position comparison exists for each published page at the 4-week and 8-week marks.) --- ## [Capture and Measure Revenue From ChatGPT, Perplexity and Google AI Traffic](https://seo-mcp.io/t/capture-and-measure-revenue-from-chatgpt-perplexity-and) A brand reportedly earned more than $50,000 from ChatGPT, Google and Perplexity-driven traffic after applying an article's recommendations. The actionable version: instrument AI-assistant referrals, find which pages earn them, make those pages directly quotable, and track the revenue each source produces instead of treating assistant traffic as untracked noise. Prerequisites: - Analytics property with conversion or revenue tracking already configured - List of 10-30 buyer-intent questions your audience asks assistants - Edit access to the CMS or template for your highest-value pages - Access to analytics reports or data export (GA4, Looker Studio, or warehouse) 1. Isolate AI-assistant referrers in analytics: Open an analytics exploration and filter sessions where the referrer host contains chatgpt.com, chat.openai.com, perplexity.ai or copilot.microsoft.com. Save it as a reusable segment named "AI assistants" so every later report uses the same definition. Google AI Overviews and AI Mode generally arrive as plain google organic, so record them as a separate inferred bucket rather than mixing them in. (Check: The segment returns a session count for at least one AI host, or you have a screenshot showing an explicit zero baseline dated today.) 2. Record a dated baseline of sessions, conversions and revenue: For the last 90 days, export sessions, key events or conversions, and revenue for the AI-assistant segment, broken down by landing page. Store it as a CSV named with today's date so future comparisons are unambiguous. (Check: A dated CSV exists and its session totals reconcile with the segment count in step 1.) 3. Audit which URLs earn assistant visits and citations: Join the landing-page export with a manual prompt audit: run your fixed list of buyer-intent questions through ChatGPT, Perplexity and Google AI surfaces, and log which of your URLs (or which competitors) get cited. Keep prompt, assistant, date, cited domain and cited URL as columns. (Check: The audit sheet has at least one row per prompt with a date, and every one of your URLs cited is matched to its landing-page session count.) 4. Rewrite cited and high-value pages to be directly quotable: For each page that earns citations or assistant sessions, put a one-sentence direct answer directly under the H1 and under each H2, add concrete numbers, tables and any first-party data you own, and keep headings phrased as the questions users ask. Add FAQ or Article structured data where it matches the visible content. (Check: Re-run three of the audited prompts after re-crawling; the page content now contains a self-contained answer passage that stands alone without surrounding context.) 5. Add conversion paths for mid-research visitors: AI-referred visitors often arrive on a definitional or comparison page, not a pricing page. Add a contextual next step on those URLs (relevant guide, sample, demo or email capture) and make sure the conversion event fires for the AI-assistant segment. (Check: Trigger the conversion on the edited page yourself, then confirm the event appears in the AI-assistant segment report.) 6. Report attributed value monthly and iterate: Build a one-page monthly view: sessions, conversions and attributed revenue by traffic source, with AI assistants on their own line. Use it to decide which pages to rewrite next; do not change page strategy on a single month of noisy data. (Check: Two consecutive monthly reports exist in the same format, and the delta by source is explainable in one sentence each.) --- ## [Get a directory backlink by submitting a tool to AI Collection](https://seo-mcp.io/t/get-a-directory-backlink-by-submitting-a-tool-to-ai) Register on the AI Collection directory, use the footer's Submit Your Tool form, and add your tool name and URL. The listing gives your product page an external link and a small referral source. Check the live listing afterwards to confirm the link is followed and points at the URL you want ranked. Prerequisites: - A live tool or product page with a stable URL - An email address for account registration 1. Register on AI Collection: Open the AI Collection site and create an account with a working email address so the submission can be reviewed or edited later. (Check: You can log in and reach an account or profile page on the directory.) 2. Open the submission form: Scroll to the site footer and select the "Submit Your Tool" link. (Check: A submission form with fields for tool name and URL loads.) 3. Add the tool name and target URL: Enter the tool name and the URL of the specific tool or product page you want linked, not a generic homepage, plus any description fields the form requires. (Check: The form shows your tool name and the exact target URL before submission.) 4. Submit and confirm the listing: Send the form and complete any email confirmation. Wait for approval, then find your listing on the directory. (Check: The listing page for your tool exists on the directory and links to your submitted URL.) 5. Check the link attributes *(general best practice)*: Inspect the live listing's HTML to confirm whether the outbound link is followed and points directly at your URL rather than through a redirect. (Check: Viewing the listing's page source shows an anchor whose href is your URL; a rel attribute containing nofollow or sponsored means the link is not followed.) 6. Record the listing for audits *(general best practice)*: Save the listing URL and date in your link log so future backlink audits can confirm the link is still live. (Check: The link log row contains the listing URL, target URL, and the date checked.) --- ## [Triage SEO wins by impact versus effort before shipping fixes](https://seo-mcp.io/t/triage-seo-wins-by-impact-versus-effort-before-shipping) A link-only post pointing to a list of high-impact SEO wins without naming any. The transferable habit it points at is triage: collect candidate fixes from your audit and Search Console data, score each by expected impact and effort, and ship the highest-scoring items first instead of working through a checklist in arbitrary order. Prerequisites: - A crawl or audit export of candidate issues (CSV) - Search Console access for impressions, clicks and position by page - A rough sense of which templates and pages carry commercial value 1. Export your candidate issues *(general best practice)*: Pull the current list of known problems into one CSV: crawl errors, missing or duplicated titles, thin pages, broken internal links, pages with impressions but no clicks, and any flagged template-level problems. Keep one row per issue and note which URL pattern or template it affects. Columns: `issue`, `template_or_url`, `pages_affected`, `evidence` (crawl report, GSC query, manual check). (Check: Open the CSV and confirm every row has a non-empty `evidence` value; rows without evidence get deleted, not guessed.) 2. Attach impact signals from Search Console *(general best practice)*: For each issue, join the affected URLs to their Search Console performance over the last 90 days (impressions, clicks, average position). Sum impressions and clicks per issue so you can see which fixes sit on pages that already have demand. (Check: Every issue row shows a numeric impressions total; issues affecting zero-impression pages are visibly identified.) 3. Score impact and effort *(general best practice)*: Assign each issue an impact score (1-5) driven by the impressions and commercial value it touches, and an effort score (1-5) driven by how many templates, pages and QA cycles the fix needs. Compute a priority score such as `impact * 2 - effort` so high-impact, low-effort items float to the top. (Check: Sort the file by priority score and sanity-check the top five: you should be able to explain each one to a stakeholder in a sentence.) 4. Ship the top items and re-measure *(general best practice)*: Create a ticket per top item, ship it, and record the ship date in the same file. After the re-crawl window, compare Search Console data for the affected URLs against the pre-ship baseline. (Check: Every shipped item has a ship date and a before/after impressions figure, or an explicit note that no change was observed.) --- ## [Earn a high-authority backlink by publishing on Dev.to](https://seo-mcp.io/t/earn-a-high-authority-backlink-by-publishing-on-dev-to) Register on Dev.to, pick a low-competition keyword your team can write about credibly, and publish an SEO-friendly article with a contextual link back to the relevant page on your site. The link sits on a high-authority developer platform, so it can add referring-domain diversity alongside your own content. Prerequisites: - A Dev.to account - A topic your team can write about credibly - A target page on your own site to link to 1. Register on Dev.to: Create an account on Dev.to and complete the profile so the post is attributed to a real author. (Check: You can open the post editor at dev.to/new while signed in.) 2. Pick a low-competition keyword: Choose a keyword your target page should rank for where the current results are weak — forum threads, unanswered questions or thin posts rather than established guides. (Check: A search for the keyword returns at least one forum thread or thin post in the top five results.) 3. Write the article around that keyword: Put the keyword in the title and first paragraph, use one H2 per subtopic, and add a single contextual link to the page you want to rank. (Check: The draft contains the keyword in the title, at least two H2 headings, and one link to your target URL.) 4. Set the canonical URL when cross-posting *(general best practice)*: If the article already exists on your own blog, add the canonical_url entry to the post front matter so the original is credited as the source. (Check: The published post's HTML contains a canonical link element pointing at your original URL.) 5. Publish the post: Publish from the editor and copy the resulting public URL. (Check: The public post URL loads in a logged-out browser window.) 6. Confirm the link is crawlable and followed *(general best practice)*: Fetch the published post and inspect the anchor tag that points at your site; use the post URL from step 4. (Check: curl -s <published post URL> | grep -o '<a[^>]*href="<your site URL>[^"]*"[^>]*>' returns an anchor without rel="nofollow" or rel="ugc".) --- ## [Audit Live Google SERPs Across Niches Before Planning Content](https://seo-mcp.io/t/audit-live-google-serps-across-niches-before-planning) Instead of relying only on keyword-tool volume, sample live Google result pages for target queries spanning several niches and record who ranks and which SERP features appear. A published analysis covered 238 live US searches across twelve niches. Use the observed patterns to prioritise content formats, then verify impact against Search Console data. Prerequisites: - A list of target queries grouped by niche - Ability to query Google with a US location (browser with US geo, VPN, or a SERP data provider) - A spreadsheet or database to record results - Search Console access to compare against your own position data 1. Build the query sample: Group your target queries by niche (product category, topic cluster, or market segment) and pick a sample per niche. Keep the set small enough to review manually but wide enough to show patterns across verticals. Store queries in a CSV with columns: query, niche, target_url. (Check: The CSV has at least a handful of niches and every row has a query and a niche assigned.) 2. Capture live SERPs with a US location: For each query, load the live Google results page with the location set to the United States. Record the top ten organic URLs, their page type, and every SERP feature present above or between organic results (featured snippet, People Also Ask, video, images, shopping, local pack). (Check: Each query row has ten organic URLs recorded, or an explicit note that fewer than ten exist.) 3. Classify page types and formats: Tag each ranking URL by page type (guide, comparison, product, category, docs, forum, news) and by format cues such as word-count band, presence of tables, video embeds, or freshness dates. Do this per niche so cross-niche patterns are visible. (Check: Every captured URL has a page-type tag and no rows are left unclassified.) 4. Compare patterns across niches: Pivot the data by niche to see which page types and features recur. Repeated patterns across unrelated niches are candidates for your own content template; niche-specific patterns tell you where the competition is idiosyncratic. (Check: You can name at least three recurring patterns and the niches in which each appears.) 5. Map findings to your own pages: Match each query to the URL on your site that targets it and mark whether your page matches the dominant format. Flag mismatches as reformat, consolidate, or create. (Check: Every query in the CSV maps to an existing URL or an explicit create decision.) 6. Ship changes and measure in Search Console: Implement the highest-priority format changes, then use the Search Console Performance report filtered to the same queries to compare impressions, clicks and average position before and after. (Check: A before/after comparison exists in Search Console for the affected queries with a clear date boundary.) --- ## [See the AI grounding queries Bing uses for your site](https://seo-mcp.io/t/see-the-ai-grounding-queries-bing-uses-for-your-site) Bing Webmaster Tools has an AI Performance report with a Grounding queries view: the real retrieval phrases an AI system generates from a user question, plus which of your URLs answers each one. It is free for a verified domain and exposes citation share, intents, topics and pages, which turns guesswork about AI citations into a concrete content plan. Prerequisites: - A verified domain in Bing Webmaster Tools (free) - Ability to edit content, headings and internal links on the site - A spreadsheet for logging grounding queries, topics and pages 1. Verify your domain and open AI Performance: Go to bing.com/webmasters, add and verify your domain, then open Bing Webmaster Tools -> AI Performance -> Grounding queries. The report is free and available for your own domain only; no paid plan is needed. (Check: Bing Webmaster Tools shows your verified domain and the AI Performance -> Grounding queries table loads with rows.) 2. Read what a grounding query is: A grounding query is not what the user typed. The model first fans the question out into smaller questions, then converts the fragments into real searches it runs against the index. The report lists those internal phrases, which is more direct than guessing from Search Console. (Check: At least one grounding query in the table is phrased differently from any query in your Search Console performance report.) 3. Export the report columns: Capture the grounding queries, citation share, intents, topics and pages columns into a spreadsheet. One row per grounding query, with the URL that answers it, gives you the working list for the next steps. (Check: The spreadsheet has one row per grounding query and non-empty intents and pages columns.) 4. Turn uncovered queries into content briefs: Grounding queries with no page of yours answering them are demand the AI already expresses. Write briefs for those topics using the full grounding query, not keyword-tool volume. Treat the phrase as the question the answer must resolve. (Check: Every uncovered grounding query has a brief with the exact query as the working title or H2.) 5. Protect the pages that are already cited: Pages that do appear as the citation for a grounding query are your AI-search assets. Keep them current and avoid cosmetic rewrites that could drop the passage being cited; improve them additively. (Check: Each cited URL has an owner and a check that its cited section still exists after edits.) 6. Split and consolidate by citation shape: A single URL answering many different fragments is a candidate to split into more specific pages. Many URLs answering the same fragment is cannibalization in AI retrieval: consolidate them and keep one canonical answer. (Check: No grounding query is answered by more than one competing URL after consolidation.) 7. Track movement in the Compare view: Re-open the report every few weeks and use the Compare view to see which grounding queries, topics and cited pages changed. Feed every change into the brief list or the protection list. (Check: The Compare view shows a before/after delta for at least one grounding query since the first export.) --- ## [Audit Googlebot crawl behavior with server logs to find crawl traps](https://seo-mcp.io/t/audit-googlebot-crawl-behavior-with-server-logs-to-find) Server log analysis reveals how Googlebot actually spends crawl budget, exposing infinite URL spaces, thin faceted combinations and orphan pages that internal tools miss. The tip walks through filtering verified Googlebot requests, grouping them by URL pattern, then using robots rules, canonicals and internal links to redirect crawl attention toward pages that earn traffic. Prerequisites: - Access to raw server access logs (nginx/Apache/CDN export) covering at least 2-4 weeks - Ability to run scripts or a log analysis tool against those files - Verified Search Console property for comparison data - A list of key site sections or URL patterns you care about 1. Export a representative log window: Pull raw access logs covering at least 2-4 weeks, ideally including a period after a content release so you can see discovery behavior. Keep the fields you need: timestamp, requested URL, status code, response size, user agent and client IP. Store as plain text or newline-delimited JSON so it can be streamed rather than loaded into memory. (Check: Open the export and confirm the date range is continuous with no missing days, and that lines containing "Googlebot" are present.) 2. Filter to verified Googlebot requests: Keep only entries whose user agent contains Googlebot, then verify each client IP with a reverse DNS lookup that resolves to a googlebot.com or google.com hostname and forward-confirms back to the same IP. Spoofed user agents are common and will distort every downstream number. (Check: A random sample of 20 filtered IPs all resolve to Google-owned hostnames, and the count of dropped unverified entries is logged.) 3. Aggregate requests by URL pattern: Normalize URLs by stripping query strings, numeric IDs, dates and pagination offsets so thousands of near-identical URLs collapse into a handful of patterns. For each pattern report request count, share of total Googlebot requests, status code distribution and average response size. (Check: The report shows the top 20 patterns covering the large majority of requests, with the remaining long tail grouped as "other".) 4. Flag crawl traps and infinite URL spaces: Look for patterns with high request volume and low value: calendar paths, filter and sort parameter permutations, session IDs, search result pages, and pagination that regenerates links indefinitely. Confirm each candidate by opening a few example URLs and checking whether they return unique, indexable content or near-duplicates. (Check: Every flagged pattern has at least three example URLs recorded and a one-line note explaining why it is low value.) 5. Cross-check sitemap URLs against crawled URLs: Take the URLs in your XML sitemap and test whether each appears in the log window at all. Sitemap URLs Googlebot never requests point to a discovery or internal linking problem rather than crawl budget waste, and need a different fix. (Check: You have a count of sitemap URLs with zero Googlebot requests and a shortlist of the most important ones.) 6. Apply fixes per finding: Disallow genuinely worthless infinite spaces in robots.txt, keep valuable facet combinations crawlable but canonicalized to the parent, remove internal links that expose trap patterns, and add contextual internal links or sitemap entries for orphan or undiscovered pages. Change one category at a time so the next log read stays attributable. (Check: Each fix maps to a specific flagged pattern or orphan URL list, and the change is documented with a date.) 7. Re-run the audit and compare: After the fixes have been live for a few weeks, repeat the same aggregation on a new log window and compare the share of Googlebot requests going to valuable URLs versus trap patterns, plus the 4xx/5xx rate. (Check: The new report shows the trap patterns' request share dropped and the target patterns' share rose, with no increase in 5xx responses.) --- ## [Create an industry statistics page to attract editorial links](https://seo-mcp.io/t/create-an-industry-statistics-page-to-attract-editorial) Publish a dedicated '<industry> statistics <year>' page built from sourced, dated figures, then link it from related pages and from the site footer so it is crawlable and easy to find. Journalists looking for citable numbers discover such pages and link to them, building backlinks without an outreach-first campaign. Prerequisites: - Ability to publish a new page on the site - Access to the site footer or global template - Source data or references for the industry statistics 1. Pick the industry and year target: Choose one industry and the current or next year, then search '<industry> statistics <year>' to confirm the query returns results and that existing pages are citable rather than exhaustive official reports. (Check: A search for '<industry> statistics <year>' returns a results page with competitor statistics articles on page one.) 2. Publish the statistics page *(general best practice)*: Create a single URL at a clean path such as /<industry>-statistics/ containing the figures, each one attributed to its source, plus a visible last-updated date. General best practice: keep the page focused on one query instead of mixing unrelated data. (Check: The page source contains at least one <time> element with a datetime attribute and at least one link to an external source next to a figure.) 3. Link to the page from related content: Add contextual links to the statistics page from existing articles, category pages or guides on the same topic, using descriptive anchor text. (Check: Search the site pages you edited and confirm each contains an <a href> pointing at the statistics URL.) 4. Add the footer link: Place a link to the statistics page in the site footer or another global template so every page passes a link to it. (Check: Open any unrelated page on the site and confirm the footer contains an anchor whose href matches the statistics URL.) 5. Request indexing and confirm the page is crawled *(general best practice)*: Submit the new URL in Search Console and check that it becomes indexed before starting any outreach. (Check: Search Console URL Inspection for the statistics URL reports 'URL is on Google' or the page appears in a site:<domain> "statistics" query.) 6. Pitch the page and track links *(general best practice)*: Send the page to writers or reporters covering the industry and monitor new referring domains pointing at that URL over the following weeks. (Check: A backlink tool or Search Console Links report shows at least one new referring domain to the statistics URL.) --- ## [Track competitor content through their sitemap.xml](https://seo-mcp.io/t/track-competitor-content-through-their-sitemap-xml) Open the competitor's sitemap.xml to list every page they have published. If the file does not load, read robots.txt for the Sitemap: line, then open each sitemap it lists. Copy the URLs into a sheet and use them to spot content they have launched that is not ranking yet. Prerequisites: - A competitor domain to analyze - A spreadsheet to store the collected URLs 1. Open the competitor's sitemap *(general best practice)*: Request competitor.com/sitemap.xml in the browser. If it returns XML, note whether the root element is a urlset (page URLs) or a sitemapindex (a list of further sitemaps). (Check: The URL returns HTTP 200 with an XML body whose root element is <urlset> or <sitemapindex>.) 2. Fall back to robots.txt *(general best practice)*: If sitemap.xml does not load, open competitor.com/robots.txt and find every line that starts with Sitemap:. Those lines give the real sitemap locations. (Check: robots.txt contains at least one line beginning with 'Sitemap:' followed by an absolute HTTPS URL.) 3. Open each listed sitemap: Open every Sitemap: URL from robots.txt. When a file is a sitemapindex, open each child sitemap it lists, since a large site splits its URLs across several files. (Check: Each opened sitemap returns a <urlset> containing <loc> entries rather than another level of <sitemapindex>.) 4. Extract the URLs into a sheet: Collect every <loc> value into one column of a spreadsheet. Fetching the XML and extracting the loc tags with a command avoids manual copying on large sitemaps. (Check: The sheet column count equals the number of <loc> entries in the sitemap when the same URL is counted once.) 5. Flag pages that are not ranking yet *(general best practice)*: General best practice: check the extracted URLs against the competitor's visible rankings, and keep the URLs that do not appear, because sitemaps list published pages that have no search visibility yet. Prioritise the topics those pages cover that fit your own product. (Check: The sheet contains a filtered set of URLs that do not appear in a site: search or in the rankings you checked for the competitor.) 6. Re-run the check on a schedule *(general best practice)*: General best practice: repeat the extraction monthly and diff the new list against the previous one, using sitemap lastmod values where they exist to focus on recently published URLs. (Check: The new URL list contains entries absent from the previous month's list, and each is dated by its lastmod value where present.) --- ## [Tune Google Business Profile for AI local recommendations](https://seo-mcp.io/t/tune-google-business-profile-for-ai-local-recommendations) Work the surfaces AI assistants read for local queries: keep name, hours and phone identical everywhere, copy the primary category from the top local pack results, request reviews that name the service, city and result, answer real questions on the profile and site, and earn mentions on other people's pages. Prerequisites: - Google Business Profile verified - Access to the site's page templates or CMS - A list of the main directories and citation listings for the business 1. Make name, hours and phone identical everywhere *(general best practice)*: Compare the business name, opening hours and phone number on the Google Business Profile, the site footer, the contact page and the main directory listings. Change each source that differs so all of them match exactly. (Check: The name, hours and phone strings read identically on the profile, the site footer and each main listing page.) 2. Set the primary category from the local pack: Search the main service query plus the city, open the top three local pack results, and note the primary category each one shows. Pick the category that at least two of the three use as the profile's primary category. (Check: The profile's primary category matches the category shown by at least two of the current top three local pack results for the main query.) 3. Ask for reviews that name service, city and result: When requesting a review, ask the customer to mention the service they bought, the city and the outcome. Do not script the wording beyond that. (Check: The newest reviews contain the service term and the city name in the customer's own wording.) 4. Reply to reviews like a human, bad reviews first: Write short, specific replies without repeating service or city keywords, and work through the lowest-rated reviews before the recent positive ones. (Check: Every review rated below four stars has an owner reply that contains no repeated keyword string.) 5. Answer the questions Google already shows: Collect the questions shown on the profile and in the question suggestions for your service queries, then answer each one on the profile Q&A and in a section of the matching site page. (Check: Each collected question appears with an answer either in the profile Q&A or on a live site page.) 6. Put reviews on your site and build service plus city pages: Publish review quotes as HTML text on your own pages, then create one page per service and city combination, built by hand before any templating. (Check: A live URL containing the service and city returns the review text in the HTML source, not only in an image.) 7. Get named on other people's pages: Pitch inclusion in local lists, directories and community threads where your business belongs, so third-party pages mention the name, service and city. (Check: A brand-name search returns at least one third-party list or directory page that names the business and its service.) 8. Track real prompts by hand every week: Choose three to five prompts a customer would actually type, ask them in the assistants weekly, and log the date, the prompt and whether the business was named. (Check: The log holds at least four weekly entries per prompt with a named or not-named result.) --- ## [Audit NAP and service consistency across local listings](https://seo-mcp.io/t/audit-nap-and-service-consistency-across-local-listings) Make the business's name, address, phone, hours and services identical on Google Business Profile, the site footer and contact page, and every directory listing. Contradictions between sources make it hard for search and AI systems to describe the business, so resolving them protects both map visibility and AI recommendations. Prerequisites: - Access to the Google Business Profile - A list of existing directory, social and map listings - Access to the site's footer and contact page templates 1. Collect every listing URL: Open a Claude project and paste the URLs of every place the business exists online: the Google Business Profile, the site footer and contact page, Facebook, Instagram, Yelp, Apple Maps, Bing Places, the directories the business is listed in, and the trade or industry sites it appears on. (Check: The pasted list contains the Google Business Profile plus at least five other source URLs.) 2. Build one row per listing *(general best practice)*: Ask for a table with one row per listing and columns for name, address, phone, opening hours, services, opening date and source URL. Flag every row that disagrees with the canonical business data. (Check: Each mismatch row shows both the canonical value and the conflicting value with the URL where the wrong value appears.) 3. Fix the table top to bottom: Work down the table, correcting the Google Business Profile and the site footer and contact page first, then each external directory and social profile so it repeats the same name, address, phone and hours. (Check: Open three of the corrected listings and confirm the name, address, phone and hours match the Google Business Profile exactly.) 4. Align the services listed *(general best practice)*: Compare the services named on the profile with the services described on the site. If the profile claims a service the site never mentions, add that service to the relevant page or remove the claim from the profile. (Check: Every service phrase on the Google Business Profile also appears on a live page of the site.) 5. Check the map pin position *(general best practice)*: Open the profile location in Google Maps and switch to satellite view to confirm the pin sits on the building entrance, then move it if it has drifted. (Check: In satellite view the pin marker sits on the building entrance rather than a street, car park or neighbouring unit.) 6. Fill the opening date field: Enter the business opening date in the profile field that records how long the business has existed. (Check: The profile shows a populated opening date instead of an empty field.) 7. Confirm the primary category *(general best practice)*: Review the primary category against the core service the business sells and change it if it describes a secondary activity. (Check: The Google Business Profile dashboard lists the intended category as the primary one.) --- ## [Build a local keyword page plan from Google autosuggest](https://seo-mcp.io/t/build-a-local-keyword-page-plan-from-google-autosuggest) Inventory every treatment and brand you offer, pair each with your city and nearby suburbs, then mine Google autosuggest and the People also ask box for each query. Sort the results into treatment, brand, problem, price and comparison buckets to produce a page plan covering the searches patients actually type. Prerequisites: - A list of the treatments and brands the business offers - A target city and 3 to 5 surrounding suburbs or neighbourhoods - A spreadsheet or document to record queries 1. Inventory every treatment and brand: Write down each treatment the business offers and each brand product it carries, one per row, before looking at any keyword tool. (Check: The list contains one row per treatment and one row per brand name.) 2. Add the city and surrounding suburbs: Pair the location terms with each row: the main city plus the 3 to 5 neighbourhoods or suburbs the business draws patients from. (Check: Each treatment row has a matching entry for the city and for every one of the recorded suburbs.) 3. Mine Google autosuggest per query *(general best practice)*: Type each treatment plus city, each brand plus city, each symptom, each price phrase and each comparison into Google and record what the search box suggests while typing. (Check: The sheet holds the recorded autosuggest completions for every seed query typed.) 4. Record People also ask questions *(general best practice)*: For each seed query, expand the People also ask box on the results page and copy the questions shown against the matching row. (Check: Each seed query has at least one captured People also ask question in the sheet.) 5. Sort queries into the five buckets: Group the collected queries as treatment plus city, brand, problem or symptom, price, and comparison, and assign one planned URL per group. (Check: The page plan lists at least one planned URL for each of the five buckets on the top treatments.) 6. Check for existing pages before publishing *(general best practice)*: Run a site-restricted search and a Search Console query filter for each planned term to confirm no existing URL already competes for it. (Check: A site: search for the term returns no existing URL targeting the same query, or the plan merges the new intent into that URL.) --- ## [Build one dedicated page per treatment for local SEO](https://seo-mcp.io/t/build-one-dedicated-page-per-treatment-for-local-seo) Split a bulky services page into one page per treatment, each covering what it treats, how it is done, downtime, suitability, price and who performs it. Add provider bio pages, consented before/after photos and original location pages. Each page then matches a specific treatment query instead of competing on one crowded list. Prerequisites: - Access to the site's CMS or page templates to publish new pages - Provider names, credentials and medical director details - Written patient consent for any before/after photo used 1. Split the services page into one page per treatment: List every treatment currently bundled on the services page. Create a separate page for each one, and give each brand its own page when two popular brands are offered for the same treatment. (Check: Each treatment named on the old services page resolves to its own URL that returns HTTP 200 and whose title contains the treatment name.) 2. Fill each treatment page with the required sections: For every treatment page include what it treats, how it is done and how long it takes, downtime and aftercare, who it suits and who should skip it, a price or starting price, and real FAQs taken from questions patients ask at the front desk. (Check: Each treatment page contains a heading or block for all seven sections; spot-check two pages end to end.) 3. Name the provider and medical director on the page: State who performs the treatment with their title (RN, NP, PA or MD) and name the medical director, then link the provider name to their bio page. (Check: View source of a treatment page shows the provider name, credential and medical director in the visible body copy.) 4. Publish a bio page per provider: Create one page per provider covering training, certifications and years of experience, and link to it from every treatment page that provider performs. (Check: Each provider bio URL loads and lists training, certifications and years of experience.) 5. Add consented before/after photos: Publish before and after images shot at the same angle and in the same lighting, keep written consent on file for each patient, and avoid wording that promises a result. (Check: Each image pair uses matched angle and lighting and the page copy says results vary rather than guaranteeing an outcome.) 6. Write an original page for each nearby suburb: For every area patients travel from, build a location page written from scratch with real local detail such as parking, landmarks and drive times. Do not duplicate one page and swap the town name. (Check: Each location page contains at least one local detail that appears on no other location page.) 7. Make the mobile page fast with the booking button in view: Test the treatment and location pages on a phone, cut render-blocking scripts and oversized images, and move the booking button into the first screen without scrolling. (Check: At a 390px viewport the booking button is visible before any scroll, and PageSpeed Insights mobile reports no failing Core Web Vitals.) 8. Give every new page a unique title and H1 *(general best practice)*: Set a distinct title tag and H1 per treatment, provider and location page, and link the new pages from the main navigation or services hub so they are reachable by crawling. (Check: No two published pages share the same title tag or H1, and each new URL is linked from at least one page on the site.) --- ## [Prioritize the five ranking levers before on-page polish](https://seo-mcp.io/t/prioritize-the-five-ranking-levers-before-on-page-polish) Work the five levers in order: match the page type Google shows for the query, start the title with the target keyword word for word, add at least five internal links using that keyword as anchor, build domain authority, then earn deeplinks to the page. Polish items such as alt text, schema and meta descriptions wait until these are done. Prerequisites: - Access to the page template or CMS to edit titles and body content - The target query and its current search results 1. Check which page type ranks for the target query: Search the target query and look at the top 10 organic results. Note whether they are guides, comparisons, category pages or product pages, because that format is what can rank. (Check: You can name the dominant page type in the top 10 results for the query.) 2. Align the page type or change the target *(general best practice)*: If your page is a different format from the dominant one, either rebuild it in that format or pick a query where your format already matches. (Check: The page you plan to optimize is the same type as the majority of the top 10 results.) 3. Start the title tag with the target keyword *(general best practice)*: Rewrite the title element so the target keyword appears word for word at the beginning, then add the qualifier and brand after it. (Check: View-source of the URL shows a title element whose first words are the target keyword.) 4. Add at least five internal links to the page: From pages on the same topic, add in-body links pointing to the target page with the target keyword as the anchor text. (Check: A crawl or source search of the site lists at least five distinct same-topic URLs whose body links to the target page with that anchor.) 5. Build domain-level links *(general best practice)*: Start acquiring links to the domain from other sites so the site has enough authority to compete for the target query at all. (Check: The Search Console Links report or a backlink tool lists new referring domains pointing at the site.) 6. Earn deeplinks to the target page *(general best practice)*: Once the domain has baseline authority, pursue links and mentions that point at the target URL rather than the homepage. (Check: The Search Console Links report shows referring URLs pointing at the target URL.) 7. Defer polish until the levers are done: Postpone alt text, heading hierarchy, meta description, URL shape and schema changes until the five levers are in place for the page. (Check: A checklist of the five levers for the page is complete before any polish task is scheduled.) --- ## [Connect Search Console data before AI keyword research](https://seo-mcp.io/t/connect-search-console-data-before-ai-keyword-research) Before asking an AI model for keyword ideas, give it real data: install Claude Desktop, point it at one site folder, and connect Search Console plus a SERP and volume provider. A model with no data connection still answers, inventing volumes and difficulty scores, so the connection is what makes the research usable. Prerequisites: - Claude Desktop installed - Access to a Google Search Console property for the site - An account or API key for a SERP and keyword-volume provider - A local folder holding the site's templates, process notes and roadmap 1. Create one site folder for the model: Install Claude Desktop, open the Code tab, select the model the source names (Opus 5.5), and give it access to a single folder that holds the site's templates, process file and roadmap. (Check: The Code tab lists the folder and the model can read a file you name inside it (for example roadmap.md).) 2. Connect Search Console as the first data source *(general best practice)*: Add a Search Console MCP server so the model can read clicks, impressions, queries and pages for the property. Claude Desktop loads MCP servers from its configuration file; add the entry, save and restart the app. (Check: Ask the model for the top 10 queries by impressions over the last 28 days and compare the values with the Search Console Performance report.) 3. Add a live SERP and volume provider: Connect a second source that returns live search results and keyword volumes, so the model can see who ranks and how large a query is. Use any provider that returns real data. (Check: Ask for the top three organic URLs for a test query and match them against an incognito search for the same query.) 4. Sanity-check one number before trusting output *(general best practice)*: Pick a keyword the model reports a volume for and look the same keyword up in the provider's own interface for the same country and month. (Check: The volume shown in the chat equals the value in the provider UI for that keyword, country and period.) --- ## [Sort AI visibility gaps into six buckets before fixing them](https://seo-mcp.io/t/sort-ai-visibility-gaps-into-six-buckets-before-fixing-them) Group each AI-visibility gap into one of six buckets: visibility, narrative, topic, format, web mentions or demand. Counting gaps per bucket shows which one or two cause most of the problem, so remediation effort goes there instead of being spread evenly across every prompt where the brand is absent. Prerequisites: - A recorded set of prompts or buyer questions run through at least one AI assistant - The answers saved with the brand and competitor mentions noted 1. Build the prompt set to audit *(general best practice)*: List the category, comparison and buyer questions where your brand should appear, and run each one through the AI assistants your audience uses. Save every answer with the prompts so the gaps can be classified. (Check: A sheet exists with at least 20 prompts, each with the saved answer and the assistant and date used.) 2. Mark every gap *(general best practice)*: For each answer, record whether the brand is named, how it is described, and which competitors and third-party sources are cited instead. (Check: Every row has a value in brand_named and at least one competitor or source recorded where the brand is absent.) 3. Assign one bucket per gap: Label each gap with a single bucket: visibility (competitors named more), narrative (you are named but described wrongly, e.g. premium brand called budget), topic (a subject you should own where you never appear), format (competitors win with video, comparisons or reviews while you have blog posts), web mentions (listicles and review sites name them, not you), or demand (searches in your space where the brand never appears). (Check: Every gap row carries exactly one of the six bucket labels and none is blank.) 4. Tally and pick the top buckets: Count gaps per bucket and identify the one or two buckets holding most of them. Scope remediation work to those buckets first and leave the rest for a later cycle. (Check: A pivot count by bucket exists and the two largest buckets account for the majority of rows.) --- ## [Find sleeper pages in Search Console and refresh them](https://seo-mcp.io/t/find-sleeper-pages-in-search-console-and-refresh-them) Compare clicks per page in Search Console against the same three months a year earlier to surface declining pages, then check each URL's referring domains in Ahrefs. Pages that lost clicks but kept backlinks are refreshed with new data, examples and sections; pages without links need a different diagnosis. Prerequisites: - Google Search Console access with at least 15 months of page-level data - Ahrefs account, or another backlink index, for referring domain counts - Access to the CMS to edit the affected pages 1. Compare page clicks year over year: Ask an AI SEO tool connected to Search Console to compare clicks per page for the last three months against the same three months a year earlier. Without the tool, open the Search Console Performance report, switch to the Pages tab, set the date range and enable the comparison against the matching period last year. (Check: The report returns one row per page with clicks for both periods and a delta column.) 2. List the ten biggest losers with their lost queries: Sort the comparison by click change ascending and take the ten pages with the largest loss. For each page, open the Queries tab for that URL to record which queries lost the most clicks. (Check: A sheet lists ten URLs, each with a click delta and at least one query with a negative click change.) 3. Record referring domains per URL *(general best practice)*: For each of the ten URLs, open Ahrefs Site Explorer, paste the full URL, set the mode to Exact URL, open the Backlinks report and read the Referring domains total; export to CSV. Record the count next to each URL so the list can be split by links. The Ahrefs API v3 returns the same number for a batch of URLs. (Check: Every row in the sheet has a numeric referring-domain count, including zeros.) 4. Split the list by link profile: Mark each URL as either links plus decline (referring domains above zero) or no links plus decline (zero referring domains). Only the first group is a refresh candidate. (Check: The sheet has two labelled groups and every one of the ten URLs sits in exactly one of them.) 5. Refresh the pages that have links: Rewrite the linked pages properly: update figures, add new examples, cover queries the page lost, and add internal links from related pages. Do not change only the published date. (Check: A version diff of the page shows new facts, examples or sections, and the visible date change is not the only edit.) 6. Re-diagnose the pages without links *(general best practice)*: Treat zero-link decliners as a different problem rather than refreshing them: check search intent, cannibalization with a stronger URL, and whether the topic is still worth targeting. (Check: No content edit is scheduled for the zero-link group until an intent or cannibalization check is recorded.) 7. Request reindexing and measure the same queries *(general best practice)*: General best practice: run URL Inspection on each refreshed URL, request indexing, and re-check the recorded query set after 28 days against the same period last year. (Check: URL Inspection shows the URL is on Google with a recent crawl date, and the 28-day query comparison shows an updated click delta.) --- ## [Structure page sections so AI models can lift and cite them](https://seo-mcp.io/t/structure-page-sections-so-ai-models-can-lift-and-cite-them) Rewrite content pages so each section leads with the direct answer, stands alone without the paragraph above it, names concrete entities instead of vague pronouns, and keeps one idea per sentence. This makes passages easy for AI assistants to extract and quote, and easier for skimming readers at the same time. Prerequisites: - Edit access to the page content or templates - A list of pages you want AI assistants to cite 1. Pick the pages worth restructuring *(general best practice)*: Choose the pages that answer buyer questions or define terms, since those are the passages an assistant can quote. Start with one page and use it as the pattern for the rest. (Check: A short list of target URLs exists, each with the question it should answer.) 2. Rewrite each section to lead with the answer: Open every section with the direct answer in the first sentence, then add context and caveats after it. Move any background paragraph that currently sits above the answer to below it. (Check: The first sentence under each H2 answers the heading's question without needing the next sentence.) 3. Make every section stand alone: Read each H2 and its paragraph in isolation. If it needs the section above to make sense, restate the missing subject or context inside the section itself. (Check: Copying a single section into a blank document still produces a readable, complete answer.) 4. Replace vague references with named entities *(general best practice)*: Swap phrases like "this tool" or "it" for the concrete product, company or concept, and state the relationship explicitly. (Check: A grep of the page for "this tool", "it helps" and "the platform" returns no ambiguous instances in the rewritten sections.) 5. Split sentences to one idea each: Break multi-clause sentences so each carries a single claim. If a sentence needs two reads, split it in two. (Check: Every rewritten sentence contains a single main clause and no more than one conjunction joining independent claims.) 6. Refresh the page before republishing *(general best practice)*: Update the content with current details and expose a visible last-updated date so the edit is verifiable. (Check: The page shows a current last-updated date and the changed sections are live in the rendered HTML.) 7. Recheck the rendered page *(general best practice)*: Load the published URL and confirm the new structure survived the CMS and any page builder. (Check: View-source of the live URL shows answer-first paragraphs directly under each H2 and the updated date element.) --- ## [Rebuild store pages per country instead of translating](https://seo-mcp.io/t/rebuild-store-pages-per-country-instead-of-translating) For each new country, collect the local-language terms buyers use for your top collections with volume data, flag where a literal translation is not the searched term, and rewrite those pages and collections around the local queries. The products stay the same; the wording matches local demand. Prerequisites: - Access to the store's collection and product templates - A keyword source that returns monthly volume by country and language - A defined target country and the collections to localize 1. Pull local keywords for the top collections: For the target country, request the terms buyers use for the top five collections, in the local language and with monthly search volume, from a keyword tool or an assistant that returns search data. (Check: A keyword list exists for each of the five collections, each row carrying the local-language term and a monthly volume value.) 2. Flag literal-translation mismatches: Translate each source-language keyword literally, compare it with the local term found in step 1, and record every case where the two differ. This list is the set of pages a translation would have got wrong. (Check: Every flagged keyword row shows both the literal translation and the actual local term, and the mismatches are marked.) 3. Identify the local competitors: For each keyword, name the three competitors ranking in the top five in the target country, not the competitors from the home market. (Check: Each keyword row lists three domains observed in the top five results of a search on the target country's Google domain in the local language.) 4. Rewrite pages and collections for the local queries: Change collection names, titles, H1s, meta descriptions and body copy to the local terms rather than the translated ones, keeping the same products and structure. (Check: The rendered title and H1 of each collection contain the local term from step 1, and searching that term on the country's Google domain returns the page.) 5. Publish local guide and comparison pages: Build buying-guide and comparison pages in the local language aimed at the competitors found in step 3, linking to the corresponding local collections. (Check: Each guide and comparison page returns HTTP 200 on the country version and contains at least one internal link to a localized collection.) 6. Add reciprocal hreflang between country versions *(general best practice)*: Emit an alternate hreflang tag for every country version of a page on each version, including a self-reference and an x-default. (Check: View-source on each country URL shows the full set of hreflang alternates, and every referenced URL returns 200.) 7. Track orders by country in GA4 *(general best practice)*: Segment orders and sessions by country in GA4 so the new markets can be compared with the home market over time. (Check: The GA4 reports show a country dimension with order and session counts for each localized market.) --- ## [Add brand trust signals: About page, author box, schema](https://seo-mcp.io/t/add-brand-trust-signals-about-page-author-box-schema) Publish an About page built from real facts, a linked legal notice, and an author box with LinkedIn and X profiles under every article. Add Organization schema sitewide and Person schema for each author. These cheap on-page signals let search engines confirm a real entity behind the site instead of sorting it with junk pages. Prerequisites: - Access to the site's page templates, header and footer - Verified company details (legal name, postal address, contact method) for the legal notice - LinkedIn and X profile URLs for each author 1. Publish an About page from verified facts: Create or rewrite the About page with who you are, where the company came from and who is on the team. Ask the owner for any fact you do not have and never invent history, names or dates. Link the page from the main navigation and the footer. (Check: The About URL returns HTTP 200, names at least one real team member and the company origin, and its link appears in the homepage navigation and footer.) 2. Add a legal notice and link it in the footer: Publish a legal notice page listing the company name, postal address and a contact method, and place a link to it in the sitewide footer. (Check: The homepage footer contains a link to the legal page, which returns HTTP 200 and shows the company name, an address and a contact method.) 3. Add an author box to the article template: In the article template, render an author box under the body with the author's name, a one-line bio and links to their LinkedIn and X profiles. Populate it from real profiles only. (Check: View the source of a published article: it contains the author name, the bio line and two outbound links, one to linkedin.com and one to x.com.) 4. Add Organization schema sitewide *(general best practice)*: Output Organization structured data on every page from the sitewide template, including the organization name, URL, logo and sameAs links to the brand's social profiles. (Check: The Rich Results Test on the homepage detects an Organization item whose name and url match the site.) 5. Add Person schema for each author *(general best practice)*: Add Person structured data to article pages for the byline author, with name, job title, profile URL and sameAs links to the same LinkedIn and X profiles shown in the author box. (Check: The Rich Results Test on an article URL lists a Person item whose sameAs values equal the profile links in the visible author box.) 6. Connect the two entities with @id references *(general best practice)*: Reference the Organization from each Person via worksFor and give both nodes stable @id values so the author is tied to the brand entity rather than floating alone. (Check: A JSON-LD validator returns no errors for the page and the Person node's worksFor @id equals the Organization node's @id.) --- ## [Publish where AI assistants cite sources (GEO workflow)](https://seo-mcp.io/t/publish-where-ai-assistants-cite-sources-geo-workflow) Ask the buying questions customers use across several AI assistants, log which pages get cited, then publish the full research and evidence on your own site and adapt it into the video, discussion and social formats you found. Repeat the questions weekly to track citations and the trials or sales they produce. Prerequisites: - Access to at least two AI assistants (for example ChatGPT, Perplexity, Gemini) - A list of the buying questions customers actually ask - Ability to publish or edit pages on your own site 1. List the buying questions customers use: Collect the questions buyers ask before purchase from sales calls, support tickets, site search and paid-search terms. Write them the way a customer phrases them, not as short head terms. (Check: A document lists at least five full questions and where each was observed.) 2. Ask each question in several AI assistants: Run every question through more than one assistant and open the citations attached to each answer. Record the exact cited URL, the assistant, the date and the position in the answer. (Check: A spreadsheet has one row per question and assistant with a full cited URL, not just the brand name.) 3. Classify the cited sources: Tag every recorded citation with the domain type (own site, forum, review platform, video, publisher), the page format and the topic it covers. (Check: Every citation row carries a domain type, a page format and a topic tag.) 4. Publish the full research on your own site: Turn the topic into a first-party guide that carries the original research, data and evidence rather than a summary of the cited pages. (Check: The guide URL returns HTTP 200, contains the original data, and its rel=canonical points to itself.) 5. Adapt the guide into the formats you found: Produce the assets that matched the citation patterns: a YouTube walkthrough, an answer in a relevant discussion, an X article, a LinkedIn post or a review-platform entry. (Check: Each adapted asset contains a link to the first-party guide URL.) 6. Keep product details current and link to the evidence: Update prices, features and availability on the guide as the product changes, and add outbound links to the primary sources the research relies on. (Check: Prices and feature statements match the live product pages and every outbound evidence link returns HTTP 200.) 7. Separate AI referrals in analytics *(general best practice)*: Filter sessions by the referrers used by AI assistants so traffic from those answers can be compared with search traffic. (Check: A report filtered on the referrer pattern returns sessions in the last 28 days.) 8. Repeat weekly and track outcomes: Re-run the same question set on a weekly cadence, log new and lost citations, and keep a separate column for the trials or sales the cited pages produce. (Check: The weekly log shows a cited-URL count per assistant per week plus an outcome column populated for at least one period.) --- ## [Find and group buy-intent keywords into comparison pages](https://seo-mcp.io/t/find-and-group-buy-intent-keywords-into-comparison-pages) List the searches that contain alternatives, versus, pricing, best software for or a buying constraint, check which page types Google shows for them, group the ones that need the same answer, and improve an existing page before building a new one. Each page should carry the comparison, proof and next step a buyer needs. Prerequisites: - A list of the products or categories the site competes in - Access to a keyword tool or search engine for modifier research 1. Build the buy-intent query list: Collect searches that combine your product or category with a buying modifier: alternatives, versus, pricing, best software for, or a specific constraint such as a platform or company size. (Check: A spreadsheet holds the modifier next to each candidate query, with at least one query per modifier.) 2. Check which page types Google shows: Open the results for each query and note whether the top results are comparison listicles, vendor pages, forums or product pages. Record the dominant page type per query. (Check: Every query row has a page-type label taken from the live results page.) 3. Group queries that need the same answer: Cluster the queries whose answer would be the same page, for example all "X alternatives" variants for one product, and assign one target page per cluster. (Check: Each cluster maps to exactly one URL and no URL appears under two clusters.) 4. Improve an existing page before creating one: Search the site for an existing URL that already targets the cluster, using a site: query or the Search Console Pages report, and update that page instead of publishing a competitor. (Check: A site: query for the cluster's main term returns the existing URL, and the content was edited rather than a new URL published.) 5. Add comparison, proof and a next step: On the chosen page, add the comparison buyers need (price, migration, automations or the relevant criteria), a proof element, and a clear next step such as a trial, demo or enquiry. (Check: The rendered page contains the comparison section, a proof element and a call-to-action link that returns HTTP 200.) --- ## [Add decision detail to product pages for AI recommendations](https://seo-mcp.io/t/add-decision-detail-to-product-pages-for-ai-recommendations) Add five decision facts to each product page: who the buyer is, the workflow in screenshots, dated pricing with plan and usage, how it differs from alternatives including limits, and consistent product facts. Put a trial or demo link beside the proof so people and AI assistants can justify a recommendation. Prerequisites: - Edit access to the product or service page templates - Approved pricing details and the date they take effect 1. Name the customer and the job on the page: Open the product or service page and add a short section that states which customer segment it is for and the specific task it finishes, using the segment and task names buyers use. (Check: The rendered page contains an H2 naming a customer segment and at least one sentence naming the completed job, not just feature adjectives.) 2. Show the workflow with screenshots or a demo: Document the main flow step by step with annotated screenshots or an embedded short demo, and give every image descriptive alt text that names the step. (Check: The page includes at least three screenshots covering consecutive flow steps, or an embedded demo, and each image tag has non-empty alt text.) 3. Publish pricing with plan, usage and date *(general best practice)*: Add a pricing block that lists the plan name, the usage limits or contact count it covers, and the date the price was last checked. (Check: The pricing block shows plan, usage limit and a visible date such as "Pricing as of September 2026".) 4. Compare against alternatives including limitations: Add a comparison section that names the alternatives buyers actually consider and lists where this product is weaker or out of scope next to the differences in its favour. (Check: The comparison section names at least one alternative product and contains an explicit limitations entry.) 5. Align product facts across site and profiles *(general best practice)*: List the core facts (price, usage limits, supported flows) and check each one against the homepage, pricing page, product page and any directory or social profiles you control; correct every mismatch. (Check: A grep for the price strings across page templates returns only values that match the published pricing page.) 6. Place the trial or demo link beside the proof *(general best practice)*: Put the trial signup or demo booking link inside the section that contains the workflow and pricing proof, not only in the site header. (Check: A link with href to the trial or demo path appears inside the proof section and returns a 200 response.)