{"id":7492,"date":"2026-05-05T18:55:30","date_gmt":"2026-05-05T10:55:30","guid":{"rendered":"http:\/\/longzhuplatform.com\/?p=7492"},"modified":"2026-05-05T18:55:30","modified_gmt":"2026-05-05T10:55:30","slug":"how-to-build-seo-agent-skills-that-actually-work","status":"publish","type":"post","link":"http:\/\/longzhuplatform.com\/?p=7492","title":{"rendered":"How to build SEO agent skills that actually work"},"content":{"rendered":"

<\/p>

I\u2019ve built 10+ SEO agent skills in 34 days. Six worked on the first try. The other four taught me everything I\u2019m about to show you about the folder structure most LinkedIn posts about AI SEO skills gloss over.<\/p>

What makes these agents reliable isn\u2019t better prompts. It\u2019s the architecture behind them. Here\u2019s how to build an agent from scratch, test it, fix it, and ship it with confidence.<\/p>

Why most AI SEO skills fail<\/h2>

Here\u2019s what a typical \u201cAI SEO prompt\u201d looks like on LinkedIn:<\/p> 

You are an SEO expert. Analyze the following website and provide a comprehensive audit with recommendations.<\/code><\/pre> 
That\u2019s it. One prompt. Maybe some formatting instructions. The person posts a screenshot of the output, gets 500 likes, and moves on. The output looks professional. It reads well. It\u2019s also 40% wrong.<\/p> 
I know because I tried this exact approach. Early in the build, I pointed an agent at a website and said, \u201cfind SEO issues.\u201d It came back with 20 findings. Eight didn\u2019t exist. The agent had never visited some of the URLs it was reporting on.<\/p> 
Three problems kill single-prompt skills:<\/p> 
     
  • No tools:<\/strong> The agent has no way to actually check the website. It\u2019s working from training data and guessing. When you ask, \u201cDoes this site have canonical tags?\u201d the agent imagines what the site probably looks like rather than fetching the HTML and parsing it.<\/li> 
  • No verification:<\/strong> Nobody checks if the output is true. The agent says, \u201cmissing meta descriptions on 15 pages.\u201d Which 15? Are those pages even indexed? Are they noindexed on purpose? No one asks. No one verifies.<\/li> 
  • No memory:<\/strong> Run the same skill twice, you get different output. Different structure. Different severity labels. Sometimes different findings entirely. There\u2019s no consistency because there\u2019s no template, no schema, no record of past runs.<\/li> <\/ul> 
    If your skill is a prompt in a single file, you don\u2019t have a skill. You have a coin flip.<\/p> 
     
     
     Your customers search everywhere. Make sure your brand shows up<\/span>. <\/p> 
     The SEO toolkit you know, plus the AI visibility data you need. <\/p> <\/p><\/div> 
     Start Free Trial<\/span> <\/p> 
     
    Get started with<\/p> 
     \"Semrush\"Semrush <\/div> <\/p><\/div> 
    Build SEO agent skills as workspaces<\/h2> 
    Every agent in our system has a workspace. Think of it like a new hire\u2019s desk, stocked with everything they need. Here\u2019s what the workspace looks like for the agent that crawls websites and maps their architecture:<\/p> 
    agent-workspace\/ AGENTS.md instructions, rules, output format SOUL.md personality, principles, quality bar scripts\/ crawl_site.js tool the agent calls to crawl parse_sitemap.sh tool to read XML sitemaps references\/ criteria.md what counts as an issue vs noise gotchas.md known false positives to watch for memory\/ runs.log past execution history templates\/ output.md expected output structure<\/code><\/pre> 
    Six components. One prompt file would cover maybe 20% of this.<\/p> 
    AGENTS.md is the instruction manual\u00a0<\/h3> 
    I wrote thousands of words of methodology into AGENTS.md.\u00a0 Instead of \u201ccrawl the site,\u201d I laid out the steps: \u201cStart with the sitemap. If no sitemap exists, check \/sitemap.xml, \/sitemap_index.xml, and robots.txt for sitemap references.\u00a0<\/p> 
    Respect crawl-delay. Use a browser user-agent string, never a bare request. If you get 403s, note the pattern and try with different headers before reporting it as a block.\u201d<\/p> 
    Scripts are the agent\u2019s tools<\/h3> 
    The agent calls node crawl_site.js \u2013url to analyze website data. It doesn\u2019t write curl commands from scratch every time. That\u2019s the difference between giving someone a toolbox and telling them to forge their own wrench.<\/p> 
    References are the judgment calls<\/h3> 
    This contains criteria for what counts as an issue. Known false positives to watch for. Edge cases that took me 20 years to learn. The agent reads these when it encounters something ambiguous.<\/p> 
    Memory is institutional knowledge<\/h3> 
    Here I keep a log of past runs:<\/p> 
       
    • What it found last time.\u00a0<\/li> 
    • How long the crawl took.\u00a0<\/li> 
    • What broke.\u00a0<\/li> <\/ul> 
      The next execution benefits from the last.<\/p> 
      Templates enforce consistency\u00a0<\/h3> 
      This is where I get specific about the output I want: \u201cUse this exact structure. These exact fields. This severity scale.\u201d Output templates are the difference between getting the same quality in run 14 as you did in run 1.<\/p> 
      Walkthrough: Building the crawler from scratch<\/h2> 
      Let me show you exactly how I built the crawler. It maps a site\u2019s architecture, discovers every page, and reports what it finds.<\/p> 
      Version 1: The naive approach<\/h3> 
      I provided the instruction: \u201cCrawl this website and list all pages.\u201d<\/p> 
      The agent wrote its own HTTP requests, used bare curl, and got blocked by the first site it touched. Every modern CDN blocks requests without a browser user-agent string, so it was dead on arrival.<\/p> 
      Version 2: Added a script<\/h3> 
      I built crawl_site.js using Playwright. This version used a headless browser and a real user-agent. The agent calls the script instead of writing its own requests.<\/p> 
      This worked on small sites, but it crashed on anything over 200 pages. Because there was no rate limiting and no resume capability, it hammered servers until they blocked us.<\/p> 
      Version 3: Introducing rate limiting and resume<\/h3> 
      I added throttling with a two requests per second default and never every two seconds for CDN-protected sites. The agent reads robots.txt and adjusts its speed without asking permission. I also added checkpoint files so a crashed crawl can resume from where it stopped.<\/p> 
      This worked on most sites, but it failed on sites that require JavaScript rendering.<\/p> 
      Version 4: JavaSript rendering<\/h3> 
      This time, I added a browser rendering mode. The agent detects whether a site is a single-page app (React, Next.js, Angular) and automatically switches to full browser rendering.<\/p> 
      It also compares rendered HTML against source HTML, and I found real issues this way: Sites where the source HTML was an empty shell but the rendered page was full of content. Google might or might not render it properly. Now we check both.<\/p> 
      This version worked on everything, but the output was inconsistent between runs.<\/p> 
      Version 5: Time for templates and memory<\/h3> 
      For this version, I added templates\/output.md with exact fields: URL count, sitemap coverage, blocked paths, response code distribution, render mode used, and issues found. This way every run produces the same structure.<\/p> 
      I also added memory\/runs.log. The agent appends a summary after every execution. Next time it runs, it reads the log and can compare results, like \u201cLast crawl found 485 pages. This crawl found 487. Two new pages added.\u201d<\/p> 
      Version 5 is what we run today. Five iterations in one day of building.<\/p> 
      THE CRAWLER'S EVOLUTION v1: Raw curl \u2192 blocked everywhere v2: Playwright script \u2192 crashed on large sites v3: Rate limiting \u2192 couldn't handle JS sites v4: Browser rendering \u2192 inconsistent output v5: Templates + memory \u2192 stable, consistent, reliable Time: 1 day. Lesson: the first version never works.<\/code><\/pre> 
      The pattern is always the same: Start small, hit a wall, fix the wall, hit the next wall.<\/p> 
      Five versions in one day doesn\u2019t mean five failures. It means five lessons that are now permanently encoded. I\u2019ve rebuilt delivery systems four times over 20 years. The process doesn\u2019t change. You start with what\u2019s elegant, then reality hits, and you end up with what works.<\/p> 
      Tip:<\/strong> Don\u2019t try to build the perfect skill on the first attempt. Build the simplest thing that could possibly work. Run it on real data and watch it fail. The failures tell you exactly what to add next. Every version of our crawler was a direct response to a specific failure. Not a feature we imagined. A problem we hit.<\/p> 
      <\/p> 
       
       
       
      Get the newsletter search marketers rely on.<\/p> <\/p><\/div> <\/p><\/div> <\/div> 
      <\/p> 
       
      This is the most important architectural decision I made.<\/p> 
      When you write \u201cuse curl to fetch the sitemap\u201d in your instructions, the agent generates a curl command from scratch every time. Sometimes it adds the right headers. Sometimes it doesn\u2019t. Sometimes it follows redirects. Sometimes it forgets.<\/p> 
      When you give the agent a script called parse_sitemap.sh, it calls the script. The script always has the right headers, always follows redirects, and always handles edge cases. The agent\u2019s judgment goes into WHEN to call the tool and WHAT to do with the results. The tool handles HOW.<\/p> 
      Our agents have tools for everything:<\/p> 
         
      • crawl_site.js: Playwright-based crawler with rate limiting, resume, and rendering<\/li> 
      • parse_sitemap.sh: Fetches and parses XML sitemaps, counts URLs, detects nested indexes<\/li> 
      • check_status.sh: Tests HTTP response codes with proper user-agent strings<\/li> 
      • extract_links.sh: Pulls internal and external links from page HTML<\/li> <\/ul> 
        The agent decides which tools to use and what parameters to set. The crawler chooses its own crawl speed based on what it encounters.\u00a0 It reads robots.txt and adjusts. It has judgment within guardrails.<\/p> 
        Think of it this way: You give a new hire a CRM, not instructions on how to build a database. The tools are the CRM. The instructions are the process for using them.<\/p> 
        Progressive disclosure: Don\u2019t dump everything at once<\/h2> 
        Here\u2019s a mistake I made early: I put everything in AGENTS.md. Every rule. Every edge case. Every gotcha. Thousands of words.<\/p> 
        The agent got confused. It had too much context and it started prioritizing obscure edge cases over common tasks. It would spend time checking for hash routing issues on a WordPress blog.<\/p> 
        The fix: progressive disclosure.<\/p> 
        Core rules that affect the 80% case go in AGENTS.md. This is what the agent needs to know for every single run.<\/p> 
        Edge cases go in references\/gotchas.md. The agent reads this file when it encounters something ambiguous. Not before every task. Only when it needs it.<\/p> 
        Criteria for severity scoring go in references\/criteria.md. The agent checks this when it finds an issue and needs to decide how bad it is. Not upfront.<\/p> 
        This is the same way a skilled employee operates. They know the core process by heart. They check the handbook when something weird comes up. They don\u2019t re-read the entire handbook before answering every email.<\/p> 
        If your agent output is inconsistent but your instructions are detailed, the problem is usually too much context. Agents, like new hires, perform better with clear priorities and a reference shelf than with a 50-page manual they have to digest before every task.<\/p> 
        The 10 gotchas: Failure modes that will burn you<\/h2> 
        Every one of these lessons cost me hours. They\u2019re now encoded in our agents\u2019 references\/gotchas.md files so they can\u2019t happen again.<\/p> 
        Agents hallucinate data they can\u2019t verify\u00a0<\/h3> 
        I asked the research agent to find law firms and count their attorneys. It made every number up. It had never visited any of their websites.<\/p> 
        Only ask agents to produce data they can actually fetch and verify. Separate what they know (training data) from what they can prove (fetched data).<\/p> 
        Knowledge doesn\u2019t transfer between agents<\/h3> 
        This fix I figured out on day one (use a browser user-agent string to avoid CDN blocks) had to be re-taught to every new agent. Day 34, a brand new agent hit the exact same problem.<\/p> 
        Agents don\u2019t share memories. Encode shared lessons in a common gotchas file that multiple agents can reference.<\/p> 
        Output format drifts between runs<\/h3> 
        The same prompt can result in different field names: \u201cnote\u201d vs. \u201cassessment.\u201d \u201clead_score\u201d vs. \u201cqualification_rating.\u201d If you run it twice, get two different schemas.<\/p> 
        The fix: Create strict output templates with exact field names. Not \u201cwrite a report.\u201d \u201cUse this exact template with these exact fields.\u201d<\/p> 
        Agents confidently report issues that don\u2019t exist<\/h3> 
        The first three audits delivered false positives with total confidence.<\/p> 
        The fix wasn\u2019t a better prompt. It was a better boss. A dedicated reviewer agent whose only job is to verify everyone else\u2019s work. The same reason code review exists for human developers.<\/p> 
        Bare HTTP requests get blocked everywhere<\/h3> 
        Every modern CDN blocks requests without a browser user-agent string. The crawler learned this on audit number two when an entire site returned 403s.<\/p> 
        All it required was a one-line fix, and now it\u2019s in the gotchas file. Every new agent reads it on day one.<\/p> 
        Don\u2019t guess URL paths<\/h3> 
        Agents love to construct URLs they think should exist: \/about-us, \/blog, \/contact. Half the time, those URLs 404.<\/p> 
        My rule is: Fetch the homepage first, read the navigation, follow real links. Never guess.<\/p> 
        \u2018Done\u2019 vs. \u2018in review\u2019 matters\u00a0<\/h3> 
        Agents marked tasks as \u201cdone\u201d when posting their findings. Wrong. \u201cDone\u201d means approved. \u201cIn review\u201d means waiting for human verification.<\/p> 
        This small distinction has a huge impact on workflow clarity when you have 10 agents posting work simultaneously.<\/p> 
        Categories must be hyper-specific<\/h3> 
        \u201cFintech\u201d is useless for prospecting because it\u2019s too broad. \u201cPI law firms in Houston\u201d works. Every company in a category should directly compete with every other company.<\/p> 
        My first attempt at sales categories was \u201cPersonal finance & fintech.\u201d A crypto exchange doesn\u2019t compete with a budgeting app. Lesson learned in 20 minutes.<\/p> 
        Never ask an LLM to compile data<\/h3> 
        Unless you want fabricated results. I asked an agent to summarize findings from five separate reports into one document. It invented findings that weren\u2019t in any of the source reports.<\/p> 
        Always build data compilations programmatically. Script it. Never prompt it.<\/p> 
        Agents will try things you never planned<\/h3> 
        The research agent tried to call an API we never set up. It assumed we had access because it knew the API existed.<\/p> 
        The fix: Be explicit about what tools are available. If a script doesn\u2019t exist in the scripts folder, the agent can\u2019t use it. Boundaries prevent creative failures.<\/p> 
        Build the reviewer first<\/h2> 
        This is counterintuitive. When you\u2019re excited about building, you want to build the workers. The crawler. The analyzers. The fun parts.<\/p> 
        Build the reviewer first. Without a review layer, you have no way to measure quality. You ship the first audit and it looks great. But 40% of the findings are wrong. You don\u2019t know that until a client or a colleague spots it.<\/p> 
        Our review agent reads every finding from every specialist agent. It checks:<\/p> 
           
        • Does the evidence support the claim?<\/li> 
        • Is the severity appropriate for the actual impact?<\/li> 
        • Are there duplicates across different specialists?<\/li> 
        • Did the agent check what it says it checked?<\/li> <\/ul> 
          That single agent was the biggest quality improvement I made. Bigger than any prompt tweak. Bigger than any new tool.<\/p> 
          The human approval rate across 270 internal linking recommendations: 99.6%. That number exists because a reviewer verifies every single one.<\/p> 
          I\u2019ve seen the same pattern with human SEO teams for 20 years. The teams that produce great work aren\u2019t the ones with the best analysts. They\u2019re the ones with the best review process. The analysis is table stakes. The review is the product.<\/p> 
          BUILD ORDER (WHAT I LEARNED THE HARD WAY) What I did first: Build workers \u2192 Ship output \u2192 Discover quality problems \u2192 Build reviewer What I should have done: Build reviewer \u2192 Build workers \u2192 Ship reviewed output \u2192 Iterate both The reviewer defines quality. Build it first. Everything else gets measured against it.<\/code><\/pre> 
          Tip: <\/strong>If you\u2019re building multiple agents, the reviewer should be the first agent you build. Define what \u201cgood output\u201d looks like before you build the thing that produces output. Otherwise, you\u2019re shipping hallucinations with formatting. I learned this across three audits that were embarrassing in hindsight.<\/p> 
          The validation standard (Our unfair advantage)<\/h2> 
          The reviewer catches technical errors. But there\u2019s a higher bar than \u201ctechnically correct.\u201d<\/p> 
          We have a real SEO agency with real clients and a team with 50 years of combined experience. Every agent finding gets validated against one question: \u201cWould we stake our reputation on this?\u201d<\/p> 
          Would we actually send this to a client, put our name on the report, and tell the developer to build it?<\/p> 
          Below are four tests we use for every finding:<\/p> 
             
          • The Google engineer test: <\/strong>If this client\u2019s cousin works at Google, would they read this finding and nod? Would they say, \u201cYes, this is a real issue, this makes sense\u201d? If the answer is no, it doesn\u2019t ship.<\/li> 
          • The developer test: <\/strong>Can a developer reproduce this without asking a single follow-up question? \u201cFix your canonicals\u201d fails. \u201cChange CANONICAL_BASE_URL from http to https in your production .env\u201d passes.<\/li> 
          • The agency reputation test: <\/strong>Would we defend this finding in a client meeting? If I\u2019d be embarrassed explaining it to a technical CMO, it gets cut.<\/li> 
          • The implementation test: <\/strong>Is this specific enough to actually fix? Not \u201cimprove your page speed\u201d but \u201cyour hero video is 3.4MB, which is 72% of total page weight. Serve a compressed version to mobile. Here\u2019s the file.\u201d<\/li> <\/ul> 
            This is our unfair advantage. We\u2019re not building agents in a vacuum. Most people building AI SEO tools have never run a real audit. They don\u2019t know what \u201cgood\u201d looks like. We do. We\u2019ve been delivering it for 20 years with real clients. That\u2019s why our approval rate is 99.6%.<\/p> 
            Sandbox testing: Train on planted bugs<\/h2> 
            You don\u2019t train an agent on real client sites. You build a test environment where you KNOW the answers. We built two sandbox websites with SEO issues we planted on purpose:<\/p> 
               
            • A WordPress-style site with 27+ planted issues: missing canonicals, redirect chains, orphan pages, duplicate content, broken schema markup.<\/li> 
            • A Node.js site simulating React\/Next.js\/Angular patterns with ~90 planted issues: empty SPA shells, hash routing, stale cached pages, hydration mismatches, cloaking.<\/li> <\/ul> 
              The training loop:<\/p> 
                 
              • Run agent against sandbox.<\/li> 
              • Compare agent\u2019s findings to known issues.<\/li> 
              • Agent missed something? Fix the instructions.<\/li> 
              • Agent reported a false positive? Add it to gotchas.md.<\/li> 
              • Re-run. Compare again.<\/li> 
              • Only when it passes the sandbox consistently does it touch real data.<\/li> <\/ul> 
                Think of it like a driving test course. Every accident on real roads becomes a new obstacle on the course. New drivers face every known challenge before they hit the highway.<\/p> 
                The sandbox is a living test suite. Every verified issue from a real audit gets baked back in. It only gets harder. The agents only get better.<\/p> 
                 
                \"Image\"Image<\/figure> <\/div> 
                Consistency: The unsexy secret<\/h2> 
                Nobody writes about this because it\u2019s boring. But consistency is what separates a demo from a product.<\/p> 
                Three things that make output consistent:<\/p> 
                   
                • Templates: <\/strong>Every agent has an output template in templates\/output.md: Exact fields, structure, and severity scale. If the output looks different every run, you don\u2019t need a better prompt. You need a template file.<\/li> 
                • Run logs:<\/strong> After every execution, the agent appends a summary to memory\/runs.log. Timestamp, site, pages crawled, issues found, duration. The next run reads this log. It knows what happened last time. It can compare and provide outputs like, \u201cFound 14 issues last run. Found 16 this run. 2 new issues identified.\u201d<\/li> 
                • Schema enforcement:<\/strong> Field names are locked: \u201cseverity\u201d not \u201cpriority,\u201d \u201curl\u201d not \u201cpage_url,\u201d \u201cdescription\u201d not \u201csummary.\u201d When you let field names drift, downstream tooling breaks. Templates solve this permanently.<\/li> <\/ul> 
                  If your agent output looks different every run, you need a template file, not a better prompt. I cannot stress this enough. The single fastest way to improve quality for any agent is a strict output template.<\/p> 
                  The stack that makes it work<\/h2> 
                  A quick note on infrastructure, because the tools matter.<\/p> 
                  Our agents run on OpenClaw. It\u2019s the runtime that handles wake-ups, sessions, memory, and tool routing. Think of it as the operating system the agents run on. When an agent finishes one task and needs to pick up the next, OpenClaw handles that transition. When an agent needs to remember what it did last session, OpenClaw provides that memory.<\/p> 
                  Paperclip is the company OS. Org charts, goals, issue tracking, task assignments. It\u2019s where agents coordinate. When the crawler finishes mapping a site and needs to hand off to the specialist agents, Paperclip manages that handoff through its issue system. Agents create tasks for each other. Auto-wake on assignment.<\/p> 
                  Claude Code is the builder. Every script, every agent instruction file, every tool was built with Claude Code running Opus 4.6. I\u2019m a vibe coder with 20 years of SEO expertise and zero traditional programming training. Claude Code turns domain knowledge into working software.<\/p> 
                  The combination: OpenClaw runs the agents. Paperclip coordinates them. Claude Code builds everything.<\/p> 
                   
                   
                   See the complete picture<\/span> of your search visibility. <\/p> 
                   Track, optimize, and win in Google and AI search from one platform. <\/p> <\/p><\/div> 
                   Start Free Trial<\/span> <\/p> 
                   
                  Get started with<\/p> 
                   \"Semrush\"Semrush <\/div> <\/p><\/div> 
                  The result<\/h2> 
                  This process resulted in 14+ audits completed with 12 to 20 developer-ready tickets per audit, including exact URLs and fix instructions. All produced in hours, not weeks.<\/p> 
                  We have a 99.6% approval rate on internal linking recommendations on 270 links across two sites, verified by a dedicated review process.\u00a0<\/p> 
                  We completed more than 80 SEO checks mapped across seven specialist agents. Each check has expected outcomes, evidence requirements, and false positive rules. Every finding is specific (i.e., \u201cthe main app JavaScript bundle is 78% unused. Here are the exact files to fix\u201d).<\/p> 
                  That level of specificity comes from the skill architecture. The folder structure. The tools. The references. The templates. The review layer. Not the prompt.<\/p> 
                  If you want to build SEO agent skills that actually work, stop writing prompts and start building workspaces. Give your agents tools, not instructions. Test on sandboxes, not clients.<\/p> 
                  Build the reviewer first. Enforce templates. Log everything. The first version will fail. The fifth version will surprise you.<\/p> 
                  This is how you turn agent output into something repeatable. The same system produces the same quality \u2014 whether it\u2019s the first audit or the 14th \u2014 because every step is structured, verified, and encoded.<\/p> 
                  Not because the AI is smarter. Because the architecture is.<\/p> <\/div> 
                   Contributing authors are invited to create content for Search Engine Land and are chosen for their expertise and contribution to the search community. Our contributors work under the oversight of the editorial staff and contributions are checked for quality and relevance to our readers. Search Engine Land is owned by Semrush. Contributor was not asked to make any direct or indirect mentions of Semrush. The opinions they express are their own.<\/em> <\/p> 
                  Opinion#build #SEO #agent #skills #work1777978530<\/p> ","protected":false},"excerpt":{"rendered":"
                  I\u2019ve built 10+ SEO agent skills in 34 days. Six worked on the first try. The other four taught me everything I\u2019m about to show you about the folder structure most LinkedIn posts about AI SEO skills gloss over. What makes these agents reliable isn\u2019t better prompts. It\u2019s the architecture behind them. Here\u2019s how to […]<\/p>\n","protected":false},"author":1,"featured_media":7493,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[1563,8296,155,97,8183,4475],"class_list":["post-7492","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-careers","tag-agent","tag-build","tag-opinion","tag-seo","tag-skills","tag-work"],"acf":[],"_links":{"self":[{"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/posts\/7492","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=7492"}],"version-history":[{"count":0,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/posts\/7492\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=\/wp\/v2\/media\/7493"}],"wp:attachment":[{"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7492"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/longzhuplatform.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}