Social media and marketing workflows

Guide

1. Paste the complete draft into a private working document, including spaces, line breaks, hashtags, mentions, emoji, and URLs.
2. Review X's documented weighted rules, including its treatment of URLs, emoji sequences, and characters outside the single-weight ranges.
3. Revise text that is likely to exceed the standard-post allowance without relying on the TimeToPost character counter as a weighted validator.
4. Paste the final draft into the official X composer and use its displayed limit as the final validation before publishing or scheduling.

Further reading

• https://docs.x.com/fundamentals/counting-characters

Guide

1. Paste the proposed post into a private working document and leave each destination URL in its intended position.
2. Identify each URL and note that X documentation describes transformed links as using a fixed t.co length, currently 23 characters.
3. Revise the surrounding copy conservatively without treating the TimeToPost character counter as a weighted X validator.
4. Make sure nearby words explain what the reader will open instead of presenting an unexplained link.
5. Paste the complete draft into the official X composer and use its displayed limit for final validation.

Further reading

• https://docs.x.com/fundamentals/counting-characters
• https://accessible.org/social-media-content-accessibility/

Guide

1. Paste the exact line containing each emoji, including skin-tone modifiers and joined family sequences.
2. Identify complete grapheme or emoji sequences instead of assuming that one visible symbol equals one Unicode code point.
3. Consult X's documented weighted rules for recognized emoji sequences, but do not use the TimeToPost character counter as a weighted validator.
4. Check whether any emoji conveys meaning that is absent from the surrounding words and add a short textual gloss when needed.
5. Paste the completed post into the official X composer for final limit validation.

Further reading

• https://docs.x.com/fundamentals/counting-characters
• https://accessible.org/social-media-content-accessibility/

Guide

1. Paste the original-language draft without transliterating it.
2. Identify CJK spans that are treated differently from single-weight Latin characters under X's documented rules.
3. Remove repetition or optional qualifiers while preserving names, figures, factual meaning, and the original language.
4. Do not treat the TimeToPost character counter's Unicode code-point total as an X weighted total.
5. Paste the shortened draft into the official X composer and use its displayed limit for final validation.

Further reading

• https://docs.x.com/fundamentals/counting-characters

Guide

1. Separate the core caption from the proposed hashtag list.
2. Review each hashtag as typed, including its number sign and text, while remembering that the complete post is subject to X's weighted rules.
3. Preserve the complete sentence before deciding which optional tags to remove.
4. Use the official X composer to test the combined post and remove optional tags if its limit display shows an overflow.
5. Return one composer-validated post and a separate unused-tag list without claiming an ideal hashtag count.

Further reading

• https://docs.x.com/fundamentals/counting-characters

Guide

1. Copy the visible caption, proposed alt text, and hashtag list into separate private fields.
2. Remove hashtag tokens from the alt text while retaining details that describe the image.
3. Produce cleaned alt text and a separate list of removed tags.
4. Add only useful tags to the visible caption, then validate the completed post in the official X composer rather than relying on a simple character count.
5. Keep remaining tags outside the alt field and do not claim that alt text supplies search reach.

Further reading

• https://help.x.com/en/using-x/write-image-descriptions

Guide

1. Provide the image caption and all proposed hashtags.
2. Keep the complete message in the main post and move only optional overflow tags to a separate reply draft.
3. Review the main post and reply separately, without treating a simple Unicode code-point count as X weighted validation.
4. Do not start the reply with an account mention unless the author intentionally wrote one.
5. Validate both drafts separately in the official X composer and describe the reply as separate distribution without promising identical reach.

Further reading

• https://help.x.com/en/using-x/types-of-posts
• https://docs.x.com/fundamentals/counting-characters

Guide

1. Input: list each intended hashtag as ordinary words, such as open data day.
2. Check: remove spaces and capitalize the first letter of each word.
3. Output: convert the example to #OpenDataDay and show the recovered words.
4. Check: preserve official capitalization for names and acronyms instead of blindly title-casing them.
5. Output: count the formatted tag as part of the final X post before use.

Further reading

• https://accessible.org/social-media-content-accessibility/
• https://docs.x.com/fundamentals/counting-characters

Guide

1. Paste only the image description, not the visible post caption, into the character counter.
2. Read the displayed total as a simple Unicode code-point count. It is not a grapheme count and may differ for joined emoji or combining sequences.
3. Use X's documented 1,000-character maximum as a review target, but do not treat the counter as a guarantee that the platform will accept the text.
4. Treat 200 to 250 characters only as an optional succinctness review point, not a blocking platform limit.
5. Retain essential visual information and confirm the final description in X's image-description field.

Further reading

• https://help.x.com/en/using-x/write-image-descriptions
• https://mefmobile.org/just-how-long-should-alt-text-be-theres-no-universal-character-limit/

Guide

1. Input: provide the draft description and identify whether the asset is a screenshot, illustration, painting, or photograph.
2. Check: remove a generic opening such as photo of, image of, or picture of.
3. Output: retain or add Screenshot of when the fact that it is a screenshot matters.
4. Check: keep useful form details such as close-up, aerial view, black and white, or illustration.
5. Output: return a full-sentence description within X's 1,000-character maximum.

Further reading

• https://help.x.com/en/using-x/write-image-descriptions

Guide

1. Transcribe the text visible in the image and provide the visible caption separately.
2. Compare the transcription with the caption to identify essential words not available elsewhere.
3. Place missing essential text in the image description when it fits, using X's documented field maximum as a review target.
4. If it does not fit, write a complete summary of the image's point rather than cutting the transcription mid-sentence.
5. Put any public source URL in the visible post, account for X's documented URL treatment when planning, and validate the completed post in the official X composer.

Further reading

• https://help.x.com/en/using-x/write-image-descriptions
• https://www.reddit.com/r/accessibility/comments/1l31pl9/social_media_alt_text_and_repeated_information/

Guide

1. Input: provide the visible caption, current alt text, and any image-only facts.
2. Check: mark exact or near-exact sentences that appear in both fields.
3. Output: when the caption already carries the message, keep only useful visual details in the alt text.
4. Check: when the caption omits essential image text, retain that text in the description instead of deleting it.
5. Output: verify that the revised description remains objective and within 1,000 characters.

Further reading

• https://help.x.com/en/using-x/write-image-descriptions
• https://www.reddit.com/r/accessibility/comments/1m1t7q7/screen_reader_users_verbatim_text_in_alt_text_for/
• https://www.reddit.com/r/accessibility/comments/1l31pl9/social_media_alt_text_and_repeated_information/

Guide

1. Input: provide the description and list any abbreviations visibly printed in the image.
2. Check: find shortened titles, street terms, months, and organization names.
3. Output: expand author-written forms such as Doctor, Avenue, or December where clarity improves.
4. Check: preserve a printed abbreviation when accurately transcribing the image and capitalize acronyms appropriately.
5. Output: recount the revised description and keep it within 1,000 characters.

Further reading

• https://help.x.com/en/using-x/write-image-descriptions

Guide

1. Input: paste the current description and separately list facts known directly by the photographer.
2. Check: underline judgments or guesses such as having fun, upset, successful, or about to leave.
3. Output: replace each guess with visible evidence such as smiling, raised hands, a packed suitcase, or objects in frame.
4. Check: keep known intent only when the author can confirm it rather than inferring it from appearance.
5. Output: produce full sentences under X's 1,000-character maximum.

Further reading

• https://help.x.com/en/using-x/write-image-descriptions

Guide

1. Provide the chart type, main takeaway, highest and lowest values, relevant labels, units, and source URL.
2. Identify the finding a reader should retain rather than listing every plotted point.
3. Write alt text containing the trend, important extremes, units, and necessary labels.
4. Omit decorative interface controls and review the description against X's documented image-description maximum.
5. Add the source URL to the visible post, account for X's documented URL treatment only as a planning rule, and validate the post in the official X composer.

Further reading

• https://help.x.com/en/using-x/write-image-descriptions
• https://docs.x.com/fundamentals/counting-characters

Guide

1. Paste the complete draft exactly as it would appear on X.
2. Determine whether the first visible characters form an @username mention.
3. Rewrite the opening so the main point comes first and the mention appears naturally later.
4. Prepare a quote-post comment as an alternative when the goal is to discuss another post.
5. Validate each selected option in the official X composer rather than using a simple code-point count as a weighted validator.

Further reading

• https://help.x.com/en/using-x/types-of-posts
• https://docs.x.com/fundamentals/counting-characters

Guide

1. Provide the reply text and separately list the handles that X added automatically.
2. Identify which leading reply mentions are interface-provided and which mentions were manually typed into the reply body.
3. Apply X's documented exception only to genuinely auto-populated reply mentions.
4. Review URLs, emoji, CJK text, and manually typed mentions as categories that can affect weighted counting.
5. Use the official X composer to confirm whether the completed reply fits before publishing.

Further reading

• https://docs.x.com/fundamentals/counting-characters

Guide

1. Paste the complete draft and state whether replies are limited to mentioned accounts.
2. Treat text beyond the standard-post allowance as potentially requiring an X longer-post feature, and verify current eligibility and limits in the authenticated X interface.
3. Review which mentions appear near the beginning separately from those appearing later when notification or reply settings matter.
4. If longer-post scheduling is unavailable, divide the material into coherent standard-post drafts without using the TimeToPost character counter as a weighted validator.
5. Validate every part in the official X composer and verify X's current longer-post and scheduling restrictions before proceeding.

Further reading

• https://help.x.com/en/using-x/types-of-posts
• https://help.x.com/en/using-x/how-to-post
• https://docs.x.com/fundamentals/counting-characters

Guide

1. Provide the article text or a public source URL and the desired number of posts.
2. Extract only claims supported by the supplied source and remove article transitions that do not work as standalone posts.
3. Draft an opening post around one specific claim without a leading mention or URL.
4. Give each middle post one supported point and place the article URL in the final post, accounting for X's documented URL treatment only as a planning rule.
5. Label unsupported claims for removal and validate every completed draft in the official X composer.

Further reading

• https://docs.x.com/fundamentals/counting-characters
• https://help.x.com/en/using-x/types-of-posts

Guide

1. Paste the posts in order and mark which hashtags are topical rather than reach-only.
2. Remove thread markers, requests to repost, leading account mentions, and reach-only hashtags.
3. Group the remaining supported claims under descriptive H2 headings without adding unsupported facts.
4. Draft a concise title and meta description, treating 60 and 155 characters as editing guidelines rather than hard Google limits.
5. Return the cleaned outline, removed-text log, title count, and meta-description count for human editorial review.

Further reading

• https://dev.to/wfgsss/repurpose-twitter-threads-into-blog-posts-a-complete-workflow-mm4

Guide

1. Paste the exact draft copied from the source application.
2. Compare its raw Unicode sequence with an NFC-normalized version, especially around accented letters and combining marks.
3. List visually similar spans whose underlying code points change during normalization.
4. Do not treat the TimeToPost character counter's code-point count as X weighted validation or assume that code points equal graphemes.
5. Review the selected text in the official X composer for final limit validation before use.

Further reading

• https://docs.x.com/fundamentals/counting-characters

Guide

1. Record the event datetime and IANA zone, for example 2026-11-03 20:00 in America/New_York.
2. Record the operator's IANA zone, for example Europe/Berlin.
3. Use a date-aware timezone converter backed by current IANA timezone data to obtain the operator-local datetime and UTC instant, including the calendar date.
4. Verify the dated offsets and abbreviations independently before entering the value into a device-clock scheduler.

Further reading

• https://old.reddit.com/r/ModSupport/comments/1iqzdbi/timezones_on_scheduled_posts_any_news_on_a_fix/

Guide

1. Write the event time with its zone, for example 2026-11-10 21:00 America/New_York.
2. Subtract the required lead, for example 60 minutes, before doing any zone conversion.
3. Convert the resulting 20:00 Eastern time to UTC and the operator's local zone.
4. Check the event date and post date separately before entering the post time.

Further reading

• https://old.reddit.com/r/ModSupport/comments/1iqzdbi/timezones_on_scheduled_posts_any_news_on_a_fix/

Guide

1. Enter the desired account-local value, for example 2026-10-21 18:00 America/Chicago.
2. Enter the current operator zone, for example Asia/Tokyo.
3. Record the UTC result and the operator-local value, which may be 2026-10-22.
4. Check that the account-facing date remains October 21 before saving the slot.

Further reading

• https://www.reddit.com/r/FacebookAds/comments/18nk9up/scheduling_posts_time_zone/

Guide

1. Identify the chart zone from its label, for example America/Los_Angeles.
2. Record the chart date and peak hour, for example 2026-10-06 at 09:00.
3. Convert that instant into the scheduler zone, for example Australia/Sydney.
4. Check for a next-day result before entering the converted time; do not treat the chart hour as a new recommendation.

Further reading

• https://www.reddit.com/r/FacebookAds/comments/18nk9up/scheduling_posts_time_zone/

Guide

1. Choose the anchor zone and civil time, for example Thursday 20:00 America/New_York.
2. List each event date for the season rather than adding fixed seven-day durations.
3. Convert every dated occurrence to the operator zone and UTC.
4. Flag any row whose zone gap differs from the prior week and manually verify that row.

Further reading

• https://old.reddit.com/r/ModSupport/comments/1iqzdbi/timezones_on_scheduled_posts_any_news_on_a_fix/

Guide

1. Enter the source value, for example 2026-10-21 21:00 America/Toronto.
2. Convert it to Australia/Sydney and UTC.
3. Write both results with weekday, date, time, and abbreviation rather than only clock hours.
4. Check whether the destination is on October 22 before copying the schedule.

Further reading

• https://old.reddit.com/r/ModSupport/comments/1iqzdbi/timezones_on_scheduled_posts_any_news_on_a_fix/

Guide

1. Enter the London-local date and time, for example 2026-07-15 at 19:00.
2. Resolve it with Europe/London rather than a fixed GMT offset.
3. Use the returned abbreviation, which is BST for this example, and record 18:00 UTC.
4. Check any announcement that says GMT and replace that label when it conflicts with the dated zone result.

Further reading

• https://www.reddit.com/r/VirtualYoutubers/comments/tdqz65/psa_for_vtubers_check_your_timezones_about_the/

Guide

1. Start from one UTC instant, for example 2026-11-07T17:00:00Z.
2. Convert it to US Pacific, US Eastern, UTC, Central European, and Japan time.
3. Include the correct dated abbreviations and mark Japan as the next date when applicable.
4. Check every displayed time still maps back to the same UTC instant before publishing.

Further reading

• https://www.reddit.com/r/VirtualYoutubers/comments/tdqz65/psa_for_vtubers_check_your_timezones_about_the/

Guide

1. Record the intended zone, for example America/New_York.
2. Read the browser or operating-system zone, for example America/Los_Angeles.
3. Convert the same civil time under both zones and compare the UTC results.
4. If the results differ, select the intended instant explicitly rather than saving the unverified browser interpretation.

Further reading

• https://www.reddit.com/r/royalroad/comments/y8k711/how_does_rr_scheduling_work/

Guide

1. Export or copy each item as ID, stored UTC, intended IANA zone, and intended local datetime.
2. Convert every intended local datetime independently to its correct dated UTC value.
3. Mark a mismatch when the converted UTC differs from the stored UTC, for example by 60 minutes.
4. Correct only verified rows and recheck their local date and abbreviation after editing.

Further reading

• https://www.reddit.com/r/royalroad/comments/y8k711/how_does_rr_scheduling_work/
• https://www.reddit.com/r/AutoModerator/comments/9sqsji/scheduling_timezone_issues/

Guide

1. Define the recurrence as a local rule, for example 18:00 every day in Europe/London.
2. Create each calendar date first, including dates on both sides of the clock change.
3. Convert each dated 18:00 occurrence to UTC separately.
4. Check that every local result remains 18:00 even where adjacent UTC gaps are 23 or 25 hours.

Further reading

• https://www.reddit.com/r/AutoModerator/comments/9sqsji/scheduling_timezone_issues/

Guide

1. Enter the publisher's local datetime and IANA zone, for example 2026-10-02 19:00 Asia/Tokyo.
2. Convert it once to UTC.
3. Convert that UTC instant into each viewer zone, such as America/New_York and America/Los_Angeles.
4. Check and display calendar-date changes; note that this changes timestamp display, not the publication instant.

Further reading

• https://www.reddit.com/r/explainlikeimfive/comments/t08e0h/eli5_how_does_social_media_appwebsites_show_time/

Guide

1. Create columns body, publish_at, and network.
2. Write publish_at as ISO-8601 with an offset or Z, for example 2026-10-06T09:00:00-04:00.
3. Reject bare values such as 2026-10-06 09:00 because they do not identify an instant.
4. Parse each accepted row back to UTC and check that it matches the intended local date before import or manual entry.

Further reading

• https://www.reddit.com/r/socialmedia/comments/1l5fjpx/a_fullblown_social_media_scheduler_on_google

Guide

1. Record the exact reference time, for example now equals 2026-10-01T15:00:00Z.
2. Supply the interpretation zone, for example America/New_York.
3. Resolve 'tomorrow at 4pm' to 2026-10-02T16:00:00-04:00 and 2026-10-02T20:00:00Z.
4. Confirm the written calendar date and reject phrases that omit either a clock time or timezone.

Further reading

• https://www.reddit.com/r/socialmedia/comments/1l5fjpx/a_fullblown_social_media_scheduler_on_google

Guide

1. Create rows containing channel label, title, and an offset-bearing publish_at value.
2. Convert every row to UTC and sort the combined list chronologically.
3. Choose a minimum gap, for example 60 minutes, and flag adjacent items closer than that.
4. Export the checked list to a calendar file or use it as a manual native-publishing checklist.

Further reading

• https://www.reddit.com/r/SocialMediaAPIs/comments/1qvyvcf/how_to_schedule_youtube_shorts/

Guide

1. Create a draft with body, approver, approval deadline, and proposed publish time.
2. Check that the approval deadline occurs before the proposed publish time.
3. Keep the item blocked while its status is pending, rejected, or missing an approver.
4. After explicit approval, recheck the final body and time before a separate scheduling action.

Further reading

• https://www.reddit.com/r/socialmedia/comments/1l5fjpx/a_fullblown_social_media_scheduler_on_google

Guide

1. Enter the source text, link, X publish time, and the second network's manual publish time.
2. Use the character counter only for a simple Unicode code-point count of the X draft. It is not an X weighted validator and does not apply the 23-character URL rule.
3. Create a separate manual version using the second network's current editorial requirements.
4. Validate the X version in the official X composer, schedule only the X item, and add a separately zoned calendar reminder for the manual item.

Further reading

• https://www.reddit.com/r/socialmedia/comments/1l5fjpx/a_fullblown_social_media_scheduler_on_google

Guide

1. Open the public timing tool and keep its result labeled as a source-labeled public baseline rather than account analytics or a personalized optimum.
2. Select a candidate window. If applying it to a particular future date, record that date explicitly.
3. Use a separate date-aware IANA timezone converter to translate the dated instant across Central, Mountain, and Pacific time; the current planner code does not guarantee future-date DST conversion.
4. Check whether the audience is known to skew west before manually recording the final window.

Further reading

• https://timetopost.co/best-time-to-post/twitter/us/

Guide

1. Collect each post's publication timestamp and one consistent metric, such as impressions.
2. Convert all timestamps to the audience timezone and group them by weekday and hour.
3. For each group, calculate post count and median metric rather than ranking a single exceptional post.
4. Exclude groups below a chosen sample threshold, then compare the remaining top three windows.

Further reading

• https://timetopost.co/best-time-to-post/twitter/us/

Guide

1. Enter the desired value, for example 2026-10-08 20:00 America/New_York.
2. Enter the unchanged device zone, for example America/Toronto.
3. Copy the returned device-local datetime and UTC instant.
4. Before saving, check the device zone still matches the entered zone and confirm the desired-zone date remains correct.

Further reading

• https://old.reddit.com/r/ModSupport/comments/1iqzdbi/timezones_on_scheduled_posts_any_news_on_a_fix/
• https://www.reddit.com/r/FacebookAds/comments/18nk9up/scheduling_posts_time_zone/

Guide

1. Prepare each row with draft text, proposed UTC time, source note, and reviewer.
2. Use the character counter only as a simple Unicode code-point editing aid, not as an X weighted validator, and verify proposed times with a date-aware IANA timezone source.
3. Validate each final text in the official X composer before creating draft-only records.
4. Create drafts only after confirming the authenticated organization and capabilities, then review their IDs, text, and proposed times as a batch.
5. Leave scheduling as a later explicit action after organization, content, and time confirmation.

Further reading

• https://www.reddit.com/r/socialmedia/comments/1l5fjpx/a_fullblown_social_media_scheduler_on_google

Guide

1. Input: paste the robots.txt text and affected URL, for example https://example.com/products/widget.
2. Match the URL path against the relevant User-agent group and its Allow and Disallow rules. Output: allowed, blocked, or unclear, plus the matching rule.
3. Open the page and view source. Check that one title element and one meta name="description" exist.
4. If the page should appear with a snippet, remove only the rule blocking that path and verify the page remains publicly accessible.
5. If the page should stay out of search, allow crawling and add meta name="robots" content="noindex" or an X-Robots-Tag noindex header. Check that no conflicting index directive remains.

Further reading

• https://www.reddit.com/r/SEO/comments/32rw5f/wordpress_robotstxt_making_problems_with/
• https://developers.google.com/search/docs/appearance/title-link
• https://developers.google.com/search/docs/crawling-indexing/robots/intro

Guide

1. Input: list each path, whether visitors can click it, and its purpose, for example /tag/seo as a browsable archive and /?s=shoes as internal search.
2. Keep useful visitor-facing archives crawlable when they provide distinct navigation or content.
3. For URLs that should not appear in search, place a page-level noindex directive while leaving them crawlable long enough for the directive to be read.
4. Treat Sitemap lines as discovery hints, not removal instructions. Multiple absolute Sitemap URLs may be declared.
5. Output: a table with path, visitor value, crawl choice, index choice, exact directive, and a check that no robots.txt rule prevents reading noindex.

Further reading

• https://www.reddit.com/r/SEO/comments/1fg3gks/am_i_doing_it_right_robottext_file/
• https://developers.google.com/search/docs/crawling-indexing/robots/intro
• https://developers.google.com/search/blog/2025/03/robots-refresher-page-level

Guide

1. Input: paste the complete robots.txt file.
2. Extract each line beginning with Sitemap: and check that its value is an absolute URL such as https://example.com/sitemap.xml.
3. Keep valid Sitemap directives wherever they occur in the file. They do not need to be the final lines.
4. Allow multiple Sitemap directives when the site has multiple sitemap files or indexes.
5. Output: valid sitemap URLs, malformed lines, corrected lines, and a manual submission checklist for the search engine's sitemap interface.

Further reading

• https://www.reddit.com/r/SEO/comments/7ysgbh/can_spiders_read_an_xml_sitemap_url_not_located/
• https://www.reddit.com/r/SEO/comments/1fg3gks/am_i_doing_it_right_robottext_file/
• https://support.google.com/webmasters/answer/183668

Guide

1. Input: collect the title element, first visible H1, og:title, site name, page language, and first 200 words.
2. Compare the fields for conflicting wording, vague labels such as Home, repeated keywords, duplicated site names, or language mismatches.
3. Choose one descriptive page-specific phrase and use it consistently in the title, main heading, and social title where editorially appropriate.
4. Output: issue list and one proposed title, for example Blue Widget Installation Guide | Example Site.
5. Check that the title is unique on the site and wait for recrawling. Search results may still vary by query and device.

Further reading

• https://developers.google.com/search/docs/appearance/title-link
• https://www.reddit.com/r/SEO/comments/32rw5f/wordpress_robotstxt_making_problems_with/

Guide

1. Input: prepare rows with URL, current title, H1, page type, and one unique fact such as product, city, category, or article subject.
2. Group titles sharing the same long prefix or suffix and mark rows that differ by only one weak token.
3. For each row, lead with the unique subject, remove repeated keyword lists, and add the site name once if useful.
4. Output: URL, detected issue, proposed title, and needs_input when no unique fact exists.
5. Check that no two proposed titles are identical and that each accurately describes its page.

Further reading

• https://developers.google.com/search/docs/appearance/title-link
• https://webmasters.stackexchange.com/questions/56196/duplicate-meta-title-and-description-displayed-in-google-webmaster-tools
• https://www.reddit.com/r/SEO/comments/1mhlyky/technical_seo_47_errors_i_found_in_50_sites_that/

Guide

1. Input: provide the current title, H1, og:title, a body sample, and the intended page language.
2. Identify fields written in a different language or writing system from the main content.
3. Draft a concise replacement title using only a translation or terminology supplied by the editor.
4. Apply matching language to the H1 and og:title where those fields describe the same page subject.
5. Output: mismatched fields, replacement title, fields to update, and needs_translation when verified wording was not supplied.

Further reading

• https://developers.google.com/search/docs/appearance/title-link

Guide

1. Input: create rows with URL, page type, name, author or business, date, price, location, hours, and a one-sentence summary where available.
2. Select only facts relevant to that page type and combine them into one readable description rather than a keyword list.
3. Output one description per URL and mark missing_facts when the row lacks enough distinct information.
4. Compare outputs and flag exact or near duplicates for revision.
5. Check each description against the live page so every stated fact is visible and current. Search engines may still choose body text instead.

Further reading

• https://developers.google.com/search/docs/appearance/snippet
• https://developers.google.com/search/docs/crawling-indexing/special-tags

Guide

1. Input: choose normal snippet, maximum character count, no snippet, or exclude one visible section.
2. For a maximum, output meta name="robots" content="max-snippet:N" using the chosen integer.
3. For no snippet, output meta name="robots" content="nosnippet" or the equivalent X-Robots-Tag header.
4. For one excluded section, add data-nosnippet to the relevant HTML element rather than blocking the whole page.
5. Check the head and response headers for duplicate directives. Output all conflicts and retain one intentional policy.

Further reading

• https://developers.google.com/search/docs/appearance/snippet
• https://developers.google.com/search/docs/crawling-indexing/special-tags
• https://developers.google.com/search/blog/2025/03/robots-refresher-page-level

Guide

1. Input: open the live page, use View Source, and copy the head section.
2. Count title elements and meta name="description" tags. Flag duplicate title elements, duplicate descriptions, or a missing title. A meta description is optional, but record when it is absent.
3. List robots and crawler-specific meta tags, then flag conflicting index or snippet directives.
4. List rel="canonical" values and verify that each observed value resolves to an absolute URL. Treat canonical tags as signals, not indexing guarantees.
5. Output: findings for each field, the exact duplicate or conflicting tags, and a note to change them in the CMS search settings when raw HTML is unavailable.

Further reading

• https://developers.google.com/search/docs/appearance/snippet
• https://developers.google.com/search/docs/crawling-indexing/robots/intro

Guide

1. Input: record the sitemap URL, target content URL, current canonical, title, sitemap membership, and whether ordinary pages link to the XML file.
2. Remove navigational or editorial links to the XML file while keeping legitimate sitemap submission methods.
3. Configure the sitemap response with X-Robots-Tag: noindex and verify the header on the live response.
4. Check that the target page returns normally, has a unique title, uses a self-referencing canonical, and is the preferred URL listed in the sitemap.
5. Output: header change, links to remove, target-page failures, and a separate content-quality review because suppressing the XML file does not improve a weak page.

Further reading

• https://www.reddit.com/r/SEO/comments/15l96ds/sitemap_ranking_for_a_keyword_instead_of_the/
• https://support.google.com/webmasters/answer/183668

Guide

1. Input: list each duplicate URL, current canonical, sitemap status, redirect status, and whether templates link to it.
2. Choose one absolute HTTPS URL as the preferred homepage based on the site's existing public convention.
3. Set every duplicate page's rel=canonical to that preferred URL, or redirect duplicates when that is appropriate for users and infrastructure.
4. Keep only the preferred URL in the sitemap and retarget internal links to it.
5. Output: preferred URL, canonical changes, sitemap removals, redirect candidates, and remaining signal conflicts.

Further reading

• https://webmasters.stackexchange.com/questions/138488/semrush-says-sitemap-xml-contains-an-incorrect-page-due-to-non-canonical-url
• https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
• https://support.google.com/webmasters/answer/139066
• https://support.google.com/webmasters/answer/183668

Guide

1. Input: export sitemap URL, HTTP status, canonical URL, and host into a table.
2. Keep rows that return 200 and identify themselves as the preferred canonical.
3. Remove rows returning 404 or 410 and rows whose canonical points to a different URL.
4. Flag URLs on a different host for separate review because sitemap host rules apply.
5. Output: keep list, remove list, and reason codes of not_found, non_canonical, wrong_host, or missing_observation. Check removed URLs against internal links before regenerating the sitemap.

Further reading

• https://support.google.com/webmasters/answer/183668
• https://developers.google.com/search/docs/advanced/sitemaps/build-sitemap
• https://www.reddit.com/r/SEO/comments/1mhlyky/technical_seo_47_errors_i_found_in_50_sites_that/
• https://webmasters.stackexchange.com/questions/135779/what-to-do-when-you-have-sitemap-xml-and-canonical-url

Guide

1. Input: provide the copy URL, canonical URL, copy sitemap host, and canonical sitemap host.
2. Confirm that the copy's rel=canonical uses the absolute preferred URL on the canonical host.
3. Omit the copy URL from the syndicating host's sitemap when it declares another host's URL as canonical.
4. Include the preferred URL only in a sitemap belonging to its own host.
5. Output: include or omit decisions for both sitemaps, the exact canonical element, and a check for conflicting noindex or canonical directives.

Further reading

• https://webmasters.stackexchange.com/questions/135779/what-to-do-when-you-have-sitemap-xml-and-canonical-url
• https://support.google.com/webmasters/answer/183668
• https://developers.google.com/search/docs/crawling-indexing/special-tags

Guide

1. Input: copy every robots and crawler-specific meta tag from the head plus any X-Robots-Tag response header.
2. List each directive in source order and mark index versus noindex, follow versus nofollow, and snippet-control conflicts.
3. If the page should be excluded, retain one noindex directive and remove code paths emitting index directives.
4. If the page should be indexed, remove noindex and either retain one index,follow tag or rely on the documented default.
5. Output: observed tags, conflict list, one final directive, likely template sources to inspect, and a check that sitemap changes alone will not repair duplicate metadata.

Further reading

• https://www.reddit.com/r/SEO/comments/xkrb82/which_one_takes_precedence_if_have_two_googlebot
• https://developers.google.com/search/docs/crawling-indexing/special-tags
• https://developers.google.com/search/blog/2025/03/robots-refresher-page-level

Guide

1. Input: provide the hub URL and a short factual summary, current canonical, and current description for each variant.
2. Compare summaries. Treat substantially equivalent pages as consolidation candidates and distinct questions as separate pages.
3. For duplicates, choose one canonical and include only it in the sitemap.
4. For distinct pages, use self-referencing canonicals, write unique factual descriptions, and link each support page to the hub with a descriptive anchor.
5. Output: consolidate or separate decision, canonical map, description changes, internal links, and a check that the decision matches actual page content.

Further reading

• https://www.reddit.com/r/SEO/comments/x74vwq/missing_meta_descriptions_on_pages_with_canonical/
• https://www.reddit.com/r/TechSEO/comments/1mwdv0c/pillar_cluster_qa_checklist_i_use_to_prevent/
• https://developers.google.com/search/docs/appearance/snippet

Guide

1. Input: provide the current canonical URL, sitemap URL, and any parameters the application genuinely needs to preserve.
2. Identify known tracking parameters such as utm_source, utm_medium, utm_campaign, gclid, and fbclid.
3. Remove known tracking parameters from the preferred absolute canonical while retaining only explicitly approved functional parameters.
4. Update the sitemap entry and internal links to the same cleaned URL.
5. Output: cleaned canonical, removed parameters, retained parameters, unknown parameters requiring review, and conflicts between canonical and sitemap.

Further reading

• https://www.reddit.com/r/SEO/comments/1mhlyky/technical_seo_47_errors_i_found_in_50_sites_that/
• https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
• https://support.google.com/webmasters/answer/139066

Guide

1. Input: split the draft into numbered paragraphs and supply existing URL, title, and one-sentence summary rows.
2. For each paragraph, identify pages whose supplied summary directly supports or expands the paragraph's topic.
3. Choose no more than one destination per paragraph and apply a page-level cap, for example three links in a short article.
4. Draft an anchor using natural words already present in the paragraph and vary anchors when the same topic recurs.
5. Output: paragraph number, destination, anchor, relevance reason, and skipped candidates. Check every destination manually before editing the draft.

Further reading

• https://www.reddit.com/r/TechSEO/comments/1lj9hxo/internal_linking_100_on_autopilot/
• https://www.reddit.com/r/Wordpress/comments/1wkqvu5/promo_i_built_a_free_internal_linking_plugin_for/

Guide

1. Input: prepare URL, indexable status, inbound internal-link count, and clicks from the homepage.
2. Exclude pages intentionally marked noindex or removed from the content plan.
3. Place pages with zero inbound internal links first, then pages at four or more clicks from the homepage.
4. For each destination, select one topically related source page from a supplied list and draft a descriptive anchor.
5. Output: ordered URL, priority reason, suggested source, anchor, and a check that the source is itself indexable and reachable.

Further reading

• https://www.reddit.com/r/Wordpress/comments/1wkqvu5/promo_i_built_a_free_internal_linking_plugin_for/
• https://www.reddit.com/r/TechSEO/comments/1mwdv0c/pillar_cluster_qa_checklist_i_use_to_prevent/

Guide

1. Paste the complete file and number its lines. Raw llms.txt text # Acme Docs > Product documentation ## Guides - [Start](/start) A line-numbered copy The file has exactly one H1.
2. Check the summary and section order. H1, optional blockquote, H2 sections and Optional section > Documentation for Acme API A list of missing or misplaced elements Optional is used only for links an agent may skip.
3. Inspect every section row. Each item beneath an H2 - [Authentication](https://example.com/docs/auth): Token setup Valid markdown links with optional notes Every list item has a title and URL.
4. Remove robots.txt syntax. Directive-like lines User-agent: * Disallow: /private A violation list with line numbers No User-agent, Allow, Disallow or Crawl-delay lines remain.

Further reading

• https://llmstxt.org/
• https://www.reddit.com/r/llmscentral/comments/1nvseck/how_to_create_an_llmstxt_file_stepbystep_tutorial
• https://www.reddit.com/r/AISearchLab/comments/1mzzdqv/what_is_the_right_way_to_create_an_llmstxt

Guide

1. Write the site origin and the documentation page URL. One page URL https://example.com/docs/api/auth The origin and normalized page path Exclude the query string and fragment.
2. Check the conventional root location. The site origin https://example.com/llms.txt HTTP status and content type for /llms.txt Do not treat an HTML error page as a valid llms.txt file.
3. Record any additional llms.txt files intentionally published by the site owner. Known project or documentation paths https://example.com/docs/llms.txt A list of additional files and their stated scope Do not infer that the deepest file automatically overrides the root file.
4. Review the selected file's links and stated scope. The root file and any documented project-specific file Links under a Docs section The file to use for the stated project and any out-of-scope links State that external client discovery and adoption may vary.

Further reading

• https://llmstxt.org/

Guide

1. Normalize the page URL. Canonical HTML URL https://example.com/docs/setup A URL without query parameters Keep the original host and path.
2. Create the proposal's alternate candidates. Normalized URL /docs/setup.md, /docs/setup/index.md, /docs/setup/index.html.md A candidate URL list Do not overwrite or publish anything.
3. Open each candidate and record status and content type. Candidate list 200 text/markdown Status and content type table A 200 HTML shell is not a clean markdown response.
4. Compare the successful body with the visible page. Markdown response and source page Both contain the Installation heading Preferred alternate or none Label citation impact as unknown.

Further reading

• https://llmstxt.org/
• https://www.reddit.com/r/SEO/comments/1tc550w/we_opensourced_the_markdown_spec_we_built_after/
• https://www.reddit.com/r/webdev/comments/1nsxht3/llmstxt

Guide

1. Collect the raw response headers. One public page URL https://example.com/docs/start The complete Link header value Use the raw response rather than rendered developer tools markup.
2. Inspect raw HTML link elements. HTML head source <link rel="alternate" type="text/markdown" href="/docs/start.md"> Alternate and describedby relations The markdown relation includes type text/markdown.
3. Resolve relative targets. Every discovered href /llms.txt becomes https://example.com/llms.txt Absolute target URLs Targets resolve against the page URL.
4. Open each target. Resolved targets 200 text/markdown Broken, redirected or successful status Do not infer client adoption from a valid relation.

Further reading

• https://llmstxt.org/

Guide

1. Extract each markdown link and its section. llms.txt contents Guides | Setup | https://example.com/setup One row per link Mark whether the row is under Optional.
2. Open each URL and record the final destination. Extracted URLs /old redirects to /new Initial URL, final URL and status Treat repeated redirects as an issue.
3. Record response type and approximate size. Successful responses text/html, 420 KB Content type and byte estimate Flag unusually large files for editorial review, not as an automatic failure.
4. Prioritize repairs. Audit table 404 required guide before large optional appendix Ordered repair list Required-section failures come before Optional-section issues.

Further reading

• https://llmstxt.org/

Guide

1. Open the site's robots.txt. Site origin https://example.com/robots.txt Raw robots.txt text Confirm it is not an HTML error page.
2. List paths to test. llms.txt and important linked pages /llms.txt, /docs/start.md A path checklist Include each path exactly as requested.
3. Evaluate rules separately. Googlebot, Google-Extended and * groups Googlebot allowed; Google-Extended disallowed Token-by-path allow table Do not merge Googlebot and Google-Extended into one control.
4. Document the limitation. Completed matrix User-triggered fetch behavior may differ A factual access summary Do not promise every assistant will obey the file.

Further reading

• https://llmstxt.org/
• https://developers.google.com/search/docs/appearance/ai-features
• https://www.reddit.com/r/aeo/comments/1vsr4er/we_blocked_a_page_in_robotstxt_then_asked_8_ai/

Guide

1. Request the page without JavaScript using a command-line client or server log. One public URL https://example.com/article Status, content type and body size Do not solve or bypass a challenge.
2. Repeat with an ordinary browser user-agent. The same URL Mozilla-compatible user-agent A second status and size Keep all other request settings unchanged.
3. Repeat with a crawler token you are authorized to test. User-supplied user-agent A clearly identified test crawler A third response summary Do not impersonate a crawler for access.
4. Compare challenge indicators. Three response summaries 403 plus captcha text only for crawler token Likely accessible, blocked or inconclusive A 200 response can still contain a challenge or thin shell.

Further reading

• https://www.reddit.com/r/DigitalMarketing/comments/1uqtkoa/i_checked_34_websites_from_a_thread_here_to_see/
• https://www.reddit.com/r/webdev/comments/1nsxht3/llmstxt
• https://www.reddit.com/r/TechSEO/comments/1ucgsw1/im_crawling_1m_sites_to_see_how_theyre/

Guide

1. Save the initial HTML response without executing scripts. One page URL view-source:https://example.com/article Raw HTML Use the network response, not the rendered DOM.
2. Extract the title, headings and readable body text. Raw HTML Title plus H1 and three paragraphs Outline and approximate word count Ignore scripts, styles and navigation boilerplate.
3. Compare it with the browser-rendered article. Raw and rendered text Raw response has 40 words; rendered article has 900 Missing headings and passages Do not assign an unsupported minimum word threshold.
4. Choose a remediation. Comparison result Server-render the main article text A specific engineering action The important content should be available as text.

Further reading

• https://developers.google.com/search/docs/appearance/ai-features
• https://llmstxt.org/
• https://www.reddit.com/r/SEO/comments/1tc550w/we_opensourced_the_markdown_spec_we_built_after/
• https://www.reddit.com/r/TechSEO/comments/1vdmnwp/i_tested_11_recent_sites_with_four_ai_crawler/

Guide

1. Capture the raw HTML response. One public page URL https://example.com/service Unrendered source Do not use the post-JavaScript Elements panel.
2. Search for application/ld+json scripts. Raw source <script type="application/ld+json"> All raw JSON-LD blocks Record an explicit none-found result.
3. Parse each block. JSON-LD text "@type":"Organization" Types and top-level keys Flag invalid JSON rather than guessing its meaning.
4. Compare with rendered markup. Raw blocks and rendered DOM blocks FAQPage appears only after load Initial, client-inserted or absent classification Do not claim server-side placement improves citations.

Further reading

• https://www.reddit.com/r/aeo/comments/1sfl8mz/we_tested_50_sites_with_gtminjected_structured/
• https://developers.google.com/search/docs/appearance/ai-features

Guide

1. Extract JSON-LD from the raw response. Raw page HTML headline, name and description fields Field paths and string values Skip non-text values.
2. Extract visible text from the same response. Raw HTML Page heading and article body Normalized visible text Use the same response version for both sides.
3. Compare each structured-data string. JSON-LD values and visible text JSON-LD price is absent from the page Matched and unmatched fields Allow minor whitespace differences but not changed facts.
4. Search for template tokens. JSON-LD text {{product_name}} or ${price} Unresolved placeholder list Review every flagged value before publishing.

Further reading

• https://developers.google.com/search/docs/appearance/ai-features
• https://www.reddit.com/r/DigitalMarketing/comments/1uqtkoa/i_checked_34_websites_from_a_thread_here_to_see/

Guide

1. Classify how answers are created. Page editorial model Publisher supplies one answer per question Single-answer or community-answer classification Confirm whether users can submit alternative answers.
2. Select the candidate type. Classification Single publisher answer maps to FAQPage FAQPage or QAPage recommendation Use QAPage when users can submit competing answers.
3. List every question and accepted answer. Visible page text How do refunds work? Refunds take five business days. Question-answer pairs Each accepted answer is visible on the page.
4. State eligibility limits. Site type and chosen markup Not a government or health site A caution about rich-result expectations Do not present markup as an AI citation feature.

Further reading

• https://developers.google.com/search/docs/appearance/structured-data/faqpage
• https://developers.google.com/search/docs/appearance/ai-features

Guide

1. Run the free single-page SEO audit. Public page URL https://example.com/guide A 0 to 100 score and top three fixes Treat it as a page check, not a full crawl or ranking report.
2. Verify Googlebot access. robots.txt and page path Googlebot is not disallowed Allowed, blocked or ambiguous Do not substitute Google-Extended for Googlebot.
3. Inspect index and snippet controls. Raw HTML and response headers No noindex and no page-wide nosnippet Control inventory A canonical to another host requires review.
4. Confirm meaningful text is present. Raw response body The article heading and core answer appear in source Text-present or thin-shell result State that passing does not guarantee appearance.

Further reading

• https://developers.google.com/search/docs/appearance/ai-features
• https://dev.to/thefron/i-shipped-llmstxt-json-ld-and-ai-crawler-allowances-heres-what-each-one-actually-does-1i75

Guide

1. State the intended scope. Content to restrict Hide one pricing note but keep the article indexed Section-level or page-level requirement Do not use noindex for a section-only goal.
2. Inspect meta tags and headers. Raw HTML head and HTTP headers meta robots content="nosnippet" Page-wide controls Record noindex, nosnippet and max-snippet separately.
3. Inspect the target element. Raw HTML around the sensitive text <span data-nosnippet>Internal note</span> Section-level control status The attribute surrounds the exact text to exclude.
4. Explain the consequence. Detected controls data-nosnippet limits that region; noindex removes eligibility Plain-language effect by control Do not generalize behavior to every answer engine.

Further reading

• https://developers.google.com/search/docs/appearance/ai-features

Guide

1. Fetch the current raw HTML. Affected page URL https://example.com/pricing Current response body and headers Confirm the intended control is actually present.
2. Check the control's scope and syntax. Current markup data-nosnippet wraps the old price Correct, misplaced or absent A page-wide meta directive cannot be inferred from rendered styling.
3. Record cache information and deployment time. Cache headers and publish timestamp Updated today; CDN age 12 hours Possible stale-delivery factors Do not claim which version the crawler stored.
4. Request recrawl in the owner's search account. Verified live URL Use URL Inspection A user-completed recrawl request Allow recrawl time and avoid promising an update date.

Further reading

• https://developers.google.com/search/docs/appearance/ai-features

Guide

1. Open the Web search performance report in the site owner's account. A user-controlled search performance account Performance filtered to Web Clicks and impressions included in Web reporting Do not assume a separate AI-feature dimension exists.
2. Export the relevant date and page range. Page filter and dates /guide from August 1 to August 31 A user-provided aggregate table Label it as combined Web performance.
3. Inspect direct referral and server logs separately. Analytics export or access-log excerpt Requests to /llms.txt by user-agent Referral totals and file-fetch counts A file fetch is not evidence of a citation.
4. Write the measurement conclusion. Combined search data and logs AI-feature traffic cannot be isolated from this report Known, unknown and proxy signals Do not estimate an unsupported AI traffic share.

Further reading

• https://developers.google.com/search/docs/appearance/ai-features
• https://llmstxt.org/
• https://dev.to/thefron/i-shipped-llmstxt-json-ld-and-ai-crawler-allowances-heres-what-each-one-actually-does-1i75

Guide

1. Add https://api.timetopost.co/mcp as a remote MCP server in the client. Input example: the exact HTTPS URL. Output: a saved server entry.
2. Complete the browser OAuth flow when prompted. Check: do not paste an API key or access token into chat.
3. Call whoami. Output check: an authenticated account and organization context are returned.
4. Call get_capabilities. Output check: use only the tool names returned for the authenticated account.
5. Run list_free_tools as a read-only test. Check: a structured free-tool catalog is returned without attempting a mutation.

Further reading

• https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• https://stackoverflow.blog/2026/01/21/is-that-allowed-authentication-and-authorization-in-model-context-protocol/

Guide

1. Confirm the configured endpoint is exactly https://api.timetopost.co/mcp. Check for missing HTTPS, copied punctuation, or an extra path.
2. Reconnect and watch for a browser authorization prompt. Output check: a browser flow should open rather than asking for a token in chat.
3. If discovery still fails, remove the saved server entry and add the endpoint again to clear stale metadata.
4. Confirm the client supports authenticated remote HTTP MCP servers, not only local command-based servers.
5. Record the client name, timestamp, endpoint, and exact error text for support. Do not include access tokens or authorization codes.

Further reading

• https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• https://stackoverflow.blog/2026/01/21/is-that-allowed-authentication-and-authorization-in-model-context-protocol/

Guide

1. Start a completely new connection attempt instead of reusing the prior authorization code. Check: old codes are not copied into chat.
2. Complete browser consent promptly because authorization codes are short-lived.
3. Keep the same client and redirect flow throughout the attempt. A changed redirect URI or client identity can invalidate the exchange.
4. If the client opened multiple login tabs, close them and retry with one clean authorization flow.
5. If failure continues, report the client name and sanitized error. Output example: invalid_grant after browser consent, with no code, verifier, or token attached.

Further reading

• https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization

Guide

1. Call whoami to identify the current account and organization. Check: it is the organization the user intended to access.
2. Call get_capabilities before retrying the blocked action. Output: the capabilities currently available to that account.
3. Compare the requested tool with the returned capabilities instead of assuming every listed server tool is authorized.
4. Treat 401 as missing or invalid authentication and 403 as insufficient permission or scope.
5. If the organization is wrong, stop and reconnect with the intended account rather than attempting the write in another workspace.

Further reading

• https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• https://modelcontextprotocol.io/docs/concepts/tools

Guide

1. Call whoami to establish the authenticated account and organization.
2. Call get_capabilities and preserve the returned tool or capability names exactly.
3. Use list_free_tools for the public-tool subset and list_integrations for available connection types.
4. Copy exact names such as seo_audit or list_drafts into prompts. Do not translate them into invented names.
5. If a desired name is absent, classify the workflow as manual or guide-only rather than repeatedly calling a guessed tool.

Further reading

• https://www.reddit.com/r/GithubCopilot/comments/1kmd5nl/where_to_find_list_of_tools_available_to_agent/
• https://modelcontextprotocol.io/docs/concepts/tools

Guide

1. Write one bounded job sentence, such as auditing one page and returning three fixes.
2. Call whoami, then get_capabilities, and select only the returned tools directly required for that job.
3. Separate read-only work from mutations. Do not include scheduling or publishing tools in a research profile.
4. Write the expected output fields and stop conditions before making any task-specific call.
5. After the run, verify that the assistant called only the selected tools and did not substitute similarly named tools.

Further reading

• https://www.reddit.com/r/mcp/comments/1u1gy61/mcp_connector_v014_and_015_adaptive_tool_loading/
• https://modelcontextprotocol.io/docs/concepts/tools

Guide

1. Provide one publicly reachable page URL. Input example: https://example.com/article.
2. Run the free audit with the full or gated report disabled. Output: deterministic checks and a score from 0 to 100.
3. Extract the top three reported issues and preserve the audit's wording rather than claiming a full-site crawl.
4. For each issue, map the result to one page edit, such as changing a title or adding a missing description.
5. Recheck the page after deployment and compare the same deterministic checks. Check: do not describe this as measured live rankings.

Further reading

• https://www.reddit.com/r/BestGitHubRepos/comments/1wm7ee9/seomonster_a_local_mcp_server_that_turns_seo_work/

Guide

1. Enter one seed phrase. Input example: remote team content calendar.
2. Run the free snapshot with full=false. Output: directional ideas and estimated bands, not measured exact volume.
3. Group returned ideas by apparent intent using only the supplied wording and fields.
4. Choose one primary phrase and two supporting phrases based on relevance to the intended page.
5. Add a note to the brief that exact volume, difficulty, CPC, and trend data were not included in the free result.

Further reading

• https://www.reddit.com/r/BestGitHubRepos/comments/1wm7ee9/seomonster_a_local_mcp_server_that_turns_seo_work/
• https://www.reddit.com/r/Agentic_SEO/comments/1v2hxxa/built_an_mcp_server_that_connects_claude_to/

Guide

1. Provide the exact brand name and one natural-language prompt. Input example: Which services help with <problem>?
2. Run one free model probe. Output: whether the supplied brand appeared in that response.
3. Record the model or source label returned by the tool and the exact prompt used.
4. Classify the result only as appeared or did not appear for this probe. Do not convert it into a citation rank or market share.
5. Repeat later with the same prompt if monitoring manually, and keep each probe separate rather than claiming statistical coverage.

Further reading

• https://www.reddit.com/r/BestGitHubRepos/comments/1wm7ee9/seomonster_a_local_mcp_server_that_turns_seo_work/

Guide

1. Choose the supported platform context and an IANA timezone.
2. Run the public timing calculation. Treat the result as a source-labeled aggregate baseline, not account-specific analytics.
3. Select two candidate windows from the returned curve. For future dates, convert them with a date-aware IANA timezone converter and verify daylight-saving behavior manually; the current calculator uses a current-date UTC offset and is not reliable for arbitrary future-date conversion.
4. Place the verified windows into a manual test plan with comparable post types.
5. After several posts, compare actual account engagement and stop treating the public curve as personalized advice.

Further reading

• https://www.reddit.com/r/AgentsOfAI/comments/1wn6u20/i_was_tired_of_generic_x_advice_so_i_gave_my/

Guide

1. Call whoami and confirm the intended organization before requesting account analytics.
2. Call get_capabilities and verify that get_optimal_times is returned for the account.
3. Confirm that the requested account is connected, the required scopes are present, and sufficient analytics data is available. If any condition is missing, stop without promising personalized results.
4. If supported, request the account and timezone and preserve the tool's returned provenance and limitations.
5. Build a test calendar manually. Do not schedule or publish, and verify future dates with a date-aware IANA timezone conversion.

Further reading

• https://www.reddit.com/r/AgentsOfAI/comments/1wn6u20/i_was_tired_of_generic_x_advice_so_i_gave_my/

Guide

1. Define two equal date ranges. Input example: the last seven complete days and the preceding seven days.
2. Call whoami and get_capabilities, then confirm the intended organization and read access.
3. Call get_engagement_summary separately for each period using the same account and dimensions.
4. Calculate current minus previous for fields actually returned. Output check: absent metrics remain null rather than being invented.
5. Flag possible outliers for human review, but do not claim causation from a summary alone.

Further reading

• https://www.reddit.com/r/AgentsOfAI/comments/1wn6u20/i_was_tired_of_generic_x_advice_so_i_gave_my/
• https://www.reddit.com/r/Agentic_SEO/comments/1v2hxxa/built_an_mcp_server_that_connects_claude_to/

Guide

1. Choose a date range and one primary metric from the metrics the account actually exposes.
2. Call whoami and get_capabilities, then confirm the organization before reading post data.
3. Use list_posts to identify posts in the range and get_post_metrics for the selected posts.
4. Rank only on the selected metric and show raw values. Check: do not combine unlike metrics into an unexplained score.
5. Read the top posts with get_post and note repeated topics or formats as hypotheses to test, not proven causes.

Further reading

• https://www.reddit.com/r/AgentsOfAI/comments/1wn6u20/i_was_tired_of_generic_x_advice_so_i_gave_my/

Guide

1. Prepare a brief with topic, audience, factual inputs, prohibited claims, and desired length. Input example: a 240-character X post about a published article.
2. Call whoami and get_capabilities, then show the organization and ask the user to confirm it before creating anything.
3. Use create_drafts only after confirmation. Output: draft IDs and text, with no schedule time or publication action.
4. Use list_drafts to verify the new records exist and remain drafts.
5. Return the drafts for human editing. Check: do not call approve_draft, schedule_post, publish_post, or publish_thread.

Further reading

• https://community.n8n.io/t/draft-approve-google-sheets-gpt-draft-slack-approve-reject-human-still-posts/310875
• https://www.reddit.com/r/AI_Agents/comments/1uy2g3y/the_3_levels_i_let_ai_touch_a_task_most_people/

Guide

1. Call whoami and confirm the intended organization before reading drafts.
2. Call get_capabilities and verify list_drafts is available.
3. List the relevant drafts and retrieve individual details with get_post when a record is linked to a post object.
4. Score each draft manually for factual support, audience fit, prohibited claims, length, and required edits.
5. Return a review recommendation only. Check: no approve_draft, reject_draft, scheduling, or publishing call is made.

Further reading

• https://community.n8n.io/t/draft-approve-google-sheets-gpt-draft-slack-approve-reject-human-still-posts/310875
• https://tibinjacob.com/blog/human-in-the-loop-gtm-agents

Guide

1. Provide one source URL and a brief containing audience, channel, factual constraints, and number of drafts.
2. Call whoami and get_capabilities, show the organization, and require explicit confirmation before creating records.
3. Use create_posts_from_source after confirmation, with output constrained to drafts.
4. Use get_source_status until the source reports a terminal state, then use list_drafts to inspect the resulting drafts.
5. Check each draft against the source and return unsupported statements for removal. Do not approve, schedule, or publish.

Further reading

• https://community.n8n.io/t/draft-approve-google-sheets-gpt-draft-slack-approve-reject-human-still-posts/310875
• https://tibinjacob.com/blog/human-in-the-loop-gtm-agents

Guide

1. Call whoami and get_capabilities, then confirm the organization and that X scheduling is available.
2. Use list_drafts and get_post to read the selected draft without changing it.
3. If media is referenced, record the existing media identifiers and expected attachment order without uploading new media.
4. Build a receipt with organization, account, final text, media IDs, timezone, and scheduled timestamp.
5. Compare the receipt with the original instruction. Stop on an account, audience, channel, text, or date mismatch. Do not call schedule_post.

Further reading

• https://www.reddit.com/r/AI_Agents/comments/1va08fz/best_way_to_schedule_social_media_posts_from/
• https://modelcontextprotocol.io/docs/concepts/tools

Guide

1. Stop automatic retries when a schedule or publish result is uncertain.
2. Call whoami and get_capabilities, then confirm the intended organization.
3. Use scheduler_status and list_posts to look for the job, matching text, account, and time window.
4. If a matching queued or published post exists, record it and do not retry.
5. If no match exists, return the evidence and require a fresh human decision. Do not call schedule_post or publish_post in the diagnostic workflow.

Further reading

• https://www.reddit.com/r/AI_Agents/comments/1va08fz/best_way_to_schedule_social_media_posts_from/

Guide

1. Choose one basis for the entire batch: followers, impressions, or reach. The calculator does not retrieve platform data.
2. Prepare at least five posts. For each post, enter any available likes, comments, shares, and saves, plus its denominator. Use the same basis for every post.
3. Example follower-based input: 420 likes, 35 comments, denominator 12500, basis followers. With omitted metrics treated as zero, the rate is 3.64 percent.
4. In the web UI, calculate one post at a time. For up to 100 posts, use the MCP batch tool and review the complete input before approving calculation.
5. Read perPost rate for each row, medianRate for the typical post, and aggregateRate for total supplied engagements divided by total supplied denominators.
6. Disclose the selected basis and confirm denominator consistency. Do not present a universal good or bad benchmark.

Further reading

• https://www.reddit.com/r/SideProject/comments/1rgu79r/i_built_a_free_instagram_engagement_rate/

Guide

1. Enter followers and your own price per 1,000 followers. Example: 18000 followers and $20 per 1,000.
2. Calculate the base as followers divided by 1,000 times the supplied price. The example base is $360.
3. Calculate engagement as (likes + comments + shares) divided by followers times 100.
4. Define your own editable uplift bands before calculating. Example: 0 to 2 percent adds 0 percent, 2 to 4 adds 10 percent, and above 4 adds 20 percent.
5. Multiply the base by 1 plus the selected uplift. Output base, engagement rate, matched band, uplift, and adjusted quote.
6. Check that the result labels all bands as user assumptions and does not present them as market rates.

Further reading

• https://www.reddit.com/r/branddeals/comments/1okw4ax/how_to_charge_for_brand_deals/

Guide

1. Collect a comparable metric summary for each creator. The calculator does not retrieve or scrape creator data.
2. For each creator, enter likes, comments, shares, and saves as available, plus a denominator and one shared basis such as followers.
3. Submit the two rows together through MCP. The web UI supports only one row per calculation, so its separate results must be compared manually.
4. Review each perPost rate. The higher value indicates the stronger rate only under the supplied metrics, denominator basis, and sampling method.
5. Use aggregateRate only as the combined engagements divided by combined denominators. It is not an average creator score.
6. Report both inputs, both rates, the shared basis, and sample limitations. Do not infer pricing or apply a universal benchmark.

Further reading

• https://www.reddit.com/r/SideProject/comments/1sds2ik/i_made_an_influencer_pricing_analyzer_for

Guide

1. Label each user-supplied post with a format such as still or short-video. The calculator does not retrieve posts or infer formats.
2. Choose one denominator basis for all compared groups: followers, impressions, or reach. Enter optional engagement metrics and the applicable denominator for every post.
3. Create one batch per format and keep labels consistent. Each MCP call can calculate up to 100 posts; the web UI accepts one post at a time.
4. Run calculate_engagement separately for each format group. Do not combine reel and short-video unless you intentionally normalize those labels first.
5. Compare medianRate and aggregateRate across groups while reporting each group's row count and shared basis.
6. Treat small samples cautiously, disclose missing metrics, and do not use a universal format benchmark.

Further reading

• https://www.reddit.com/r/SideProject/comments/1rgu79r/i_built_a_free_instagram_engagement_rate/

Guide

1. Supply the engagement metrics yourself because the calculator does not retrieve platform data. Decide whether likes, comments, shares, and saves are available consistently.
2. Create one followers batch with each row's follower denominator and basis followers.
3. Create a separate impressions batch with the same engagement metrics, each row's impression denominator, and basis impressions. Do not mix bases in one call.
4. Use MCP for batches of up to 100 posts. The web UI calculates only one post at a time.
5. Compare the returned perPost, medianRate, and aggregateRate values, clearly labeling the numerator metrics and denominator basis for each result.
6. Do not choose a preferred formula solely because it is larger, and do not describe any percentage as universally good or bad.

Further reading

• https://www.reddit.com/r/SideProject/comments/1rgu79r/i_built_a_free_instagram_engagement_rate/
• https://www.reddit.com/r/branddeals/comments/1okw4ax/how_to_charge_for_brand_deals/
• https://docs.x.com/x-api/posts/post-lookup-by-post-id

Guide

1. Prepare up to 20 records. For each record, enter an HTTP or HTTPS landing URL, source, medium, and campaign, with optional term and content.
2. Repeat the approved medium and campaign across records while changing source as needed, such as x, newsletter, or community.
3. Review exact spelling and capitalization before building. The tool does not automatically require lowercase values.
4. Run the batch. The builder preserves existing non-conflicting query parameters and URL fragments, performs no network fetch, and refuses URLs containing credentials or using non-HTTP protocols.
5. Copy the returned tagged URLs and verify that each record contains the intended campaign values.
6. Destination availability is not checked locally, so test the final links separately before distribution.

Further reading

• https://support.google.com/analytics/answer/10917952?hl=en
• https://www.reddit.com/r/gamedev/comments/15bqs0o/indie_game_devs_your_practical_steam_utm_guide/

Guide

1. Paste the URLs and define your allowed source and medium values, such as x and organic_social.
2. Parse every URL and check for utm_source, utm_medium, and utm_campaign.
3. Flag uppercase characters and unencoded spaces because values are case-sensitive and spaces require encoding.
4. Compare values against your allowed list and flag near-duplicates, such as two names you use for the same source.
5. Output each issue with its URL, issue code, current value, and proposed corrected URL.
6. Review every proposed replacement so the destination path and non-UTM query parameters remain unchanged.

Further reading

• https://support.google.com/analytics/answer/10917952?hl=en
• https://www.reddit.com/r/digital_marketing/comments/1ov6ln6/utm_parameters_explained_for_a_newbie/

Guide

1. Paste the final URL you intend to use, including its query string.
2. Parse and list utm_source, utm_medium, utm_campaign, utm_id, and utm_source_platform as present or missing.
3. Treat source, medium, and campaign as the core set for this checklist and explain that partial tagging can contribute to not-set reporting.
4. Create an example URL with placeholders only for missing core values, such as YOUR_MEDIUM.
5. Output the present list, missing list, placeholder URL, and a note that parameter order does not matter.
6. Replace every placeholder and test the final link before publishing.

Further reading

• https://support.google.com/analytics/answer/10917952?hl=en
• https://support.google.com/analytics/answer/15593651

Guide

1. Choose an approved issue slug, such as october-launch, and prepare up to 20 destination records.
2. For every record, set source to newsletter, medium to email, campaign to the issue slug, and content to a position such as hero, middle, or footer.
3. Submit each HTTP or HTTPS destination as its own record. URLs containing credentials or using other protocols are refused.
4. Run the builder. Existing query parameters and fragments are preserved, and no destination is fetched.
5. Review the returned URLs and confirm that each position has the intended content value and destination.
6. Test the links in the rendered newsletter separately because the local builder does not verify that destinations load or send email.

Further reading

• https://www.reddit.com/r/independentanalytics/comments/1seuwub/why_you_should_always_use_utm_parameters_when/
• https://support.google.com/analytics/answer/10917952?hl=en

Guide

1. Enter up to 20 HTTP or HTTPS destination records with the same approved source, medium, and campaign.
2. Assign each planned post a unique content value, such as launch-hook-a or launch-hook-b.
3. Review the records for duplicate content values before calculation. The builder creates URLs but does not decide whether identifiers are semantically unique.
4. Run the builder. It preserves existing query parameters and fragments, refuses credential-bearing or non-HTTP URLs, and performs no fetch.
5. Output a mapping of your post IDs to the returned URLs. Keep the post ID separately if it differs from the content value.
6. Review every URL before use. The tool does not publish, schedule, or verify the destination.

Further reading

• https://www.reddit.com/r/digital_marketing/comments/1ov6ln6/utm_parameters_explained_for_a_newbie/
• https://support.google.com/analytics/answer/10917952?hl=en
• https://support.google.com/analytics/answer/6383005

Guide

1. Copy the exact planned URL from the post or message before clicking it.
2. Open the link in the target environment, wait for redirects to finish, and copy the final address-bar URL.
3. Parse UTM parameters from both URLs and classify each as kept, lost, added, or changed.
4. Example: planned utm_source=x and landed with no utm_source should be reported as lost, not blank success.
5. Output kept names, lost names, changed values, and a corrected planned URL for another test.
6. Repeat the click after correction because this comparison cannot guarantee that a platform or redirector will preserve tags.

Further reading

• https://www.reddit.com/r/smallbusiness/comments/1p5afly/how_are_you_handling_your_igtiktok_bio_traffic/
• https://docs.x.com/x-api/posts/post-lookup-by-post-id

Guide

1. Enter the same HTTP or HTTPS destination twice with the same source, medium, and campaign.
2. Choose two distinct content labels that identify placement or creative, such as top-button and footer-text.
3. Review the exact labels before calculation. If your naming rules normalize case or punctuation, confirm they remain distinct after that manual normalization.
4. Submit the two records. The builder preserves other query parameters and fragments, refuses credential-bearing or non-HTTP URLs, and performs no fetch.
5. Compare the returned URLs and confirm that the intended difference is the content value.
6. Place each reviewed URL in the correct message location and test the rendered message separately. The tool does not publish or verify destinations.

Further reading

• https://support.google.com/analytics/answer/10917952?hl=en
• https://developers.google.com/analytics/devguides/collection/ga4/reference/config

Guide

1. State one current goal using a verb, such as buy, book, join, or read.
2. List every link with its label, URL, and how directly it supports that goal.
3. Select the single link with the shortest path to the stated goal as primary.
4. Choose no more than three secondary links and move all remaining links into overflow.
5. Write one profile sentence naming the primary action, for example Book a 20-minute consultation.
6. Output primary, secondary, overflow, and the profile sentence, then check that similarly important styling is not assigned to every link.

Further reading

• https://www.reddit.com/r/SaaS/comments/1r5g8fz/i_analyzed_5_creators_linkinbio_pages_almost_none
• https://www.reddit.com/r/smallbusiness/comments/1p5afly/how_are_you_handling_your_igtiktok_bio_traffic/

Guide

1. Choose two non-overlapping periods and record their start date, end date, and pin type.
2. For each period, enter profile clicks, pin clicks, orders, and signups from your own records.
3. Calculate pin click share as pin clicks divided by profile clicks.
4. Calculate orders per profile click and signups per profile click separately.
5. Set a minimum profile-click threshold before reviewing results. If either period is below it, label the comparison insufficient.
6. Output both period rows and metric differences without declaring that product or signup pins win generally.

Further reading

• https://www.reddit.com/r/InstagramMarketing/comments/1onbhgx/real_question_for_creators_with_link_in_bio

Guide

1. List each tested post with impressions, profile clicks, keyword comments, messages sent, landing arrivals, and optional sales.
2. Calculate profile clicks per 100 impressions and keyword comments per 100 impressions.
3. Calculate landing arrivals per 100 impressions as a separate downstream measure.
4. Only calculate sales rates when sales were entered; otherwise leave them blank.
5. Output aggregate rates, per-post rates, and the number of posts in each path.
6. Check that results use your own counts and do not reuse conversion percentages reported by other accounts.

Further reading

• https://www.reddit.com/r/SocialMediaMarketing/comments/1r8j3fr/link_in_bio_vs_dm_for_link_i_tested_the/
• https://www.reddit.com/r/InstagramMarketing/comments/1s49bie/why_the_link_in_bio_cta_is_killing_your

Guide

1. Enter the usual URL, spike-specific URL, traffic source, post ID, and number of days for the temporary change.
2. Keep utm_campaign tied to the offer and set utm_content to the post ID followed by -spike.
3. Generate the tagged spike URL without altering required non-UTM query parameters.
4. Write profile text under 160 characters that names the immediate destination and action.
5. Calculate the revert date from the start date and selected duration.
6. Output the tagged URL, profile text, revert date, and manual restore checklist; do not claim the profile can be edited automatically.

Further reading

• https://www.reddit.com/r/smallbusiness/comments/1p5afly/how_are_you_handling_your_igtiktok_bio_traffic/

Guide

1. Paste the article text or provide a source URL, then specify the desired X thread length.
2. Extract the central claim, three supporting points, one quotable sentence, and one email takeaway before drafting locally.
3. Write the X thread so each post advances the argument, then draft a separate caption, pull quote, and email teaser.
4. Use the basic character counter only as a Unicode code-point count. It is not X-weighted, URLs are not fixed at 23 characters, and emoji grapheme clusters may count differently.
5. Paste every X post into the official X composer for final validation. Keep longer text clearly labeled rather than silently cutting it, and remove claims unsupported by the source.

Further reading

• https://www.reddit.com/r/n8n/comments/1rx58p0/i_built_a_workflow_that_turns_any_blog_post_into/
• https://www.reddit.com/r/SaaS/comments/1s8jzsf/how_we_automated_content_repurposing_1_blog_post/
• https://www.reddit.com/r/indiehackers/comments/1n4x3xj/how_are_you_all_turning_longform_blogs_into_short/
• https://docs.x.com/x-api/posts/post-lookup-by-post-id

Guide

1. Prepare up to 20 derivative records using the canonical HTTP or HTTPS article URL and one approved campaign value.
2. For each derivative, enter its source and medium, then use a unique format label such as x-thread or newsletter-hero as content.
3. Review source and medium carefully so email and social derivatives do not share the wrong channel values.
4. Run the builder. It preserves existing query parameters and fragments, refuses URLs with credentials or non-HTTP protocols, and performs no network fetch.
5. Map each derivative label to the returned URL and confirm campaign consistency across the set.
6. Test destinations separately before distribution. The tool creates links only and does not publish derivatives.

Further reading

• https://www.reddit.com/r/GrowthHacking/comments/1snv55g/our_content_repurposing_system_one_piece_becomes/
• https://support.google.com/analytics/answer/10917952?hl=en

Guide

1. Prepare rows with post ID, impressions, likes, replies, reposts, and link clicks.
2. Set a minimum impression threshold before ranking, such as 500 impressions.
3. Calculate click rate as link clicks divided by impressions and engagement rate as likes plus replies plus reposts divided by impressions.
4. Calculate the median engagement rate across eligible rows and flag posts above twice that median as outliers.
5. Rank eligible posts by click rate, but label rows with no recorded click data as unranked rather than zero-performing.
6. Output ranked rows, outlier flags, threshold, formulas, and excluded IDs, then review outliers separately from repeatable click performers.

Further reading

• https://www.reddit.com/r/SideProject/comments/1rgu79r/i_built_a_free_instagram_engagement_rate/
• https://www.reddit.com/r/smallbusiness/comments/1p5afly/how_are_you_handling_your_igtiktok_bio_traffic/
• https://docs.x.com/x-api/posts/post-lookup-by-post-id

Guide

1. Enter spend, currency, impressions, clicks, and conversions. Example: $500, 100000 impressions, 2000 clicks, and 50 conversions.
2. Calculate CPM as spend divided by impressions times 1,000. The example CPM is $5.
3. Calculate CPC as spend divided by clicks and CPA as spend divided by conversions. The example values are $0.25 and $10.
4. Calculate CTR as clicks divided by impressions times 100. The example CTR is 2 percent.
5. Return null with a denominator-zero explanation whenever impressions, clicks, or conversions are zero.
6. Output the four values and formulas without adding industry benchmarks or performance labels.

Further reading

• https://www.reddit.com/r/programmatic/comments/1pi3q4n/i_built_a_free_privacyfocused_calculator_for_ad