Tag: WordPress

  • 3,222 Requests an Hour. Six Login Posts. That Is Not the Same Event.

    3,222 Requests an Hour. Six Login Posts. That Is Not the Same Event.

    This morning, about 7:10 AM PDT on 14 September 2026, the knowledge cluster showed a fresh spike: roughly 3,222 requests in an hour, and six POST hits on wp-login.php. Same box. Same shape as the 11–13 September run. Slightly hotter on volume. Cooler on the login door.

    That is the whole alert. It is not a breach report. It is not a reason to open the firewall. It is two numbers that most dashboards smash into one word — “attack” — and then the operator starts changing things they cannot undo cleanly.

    Mixed spike. A mixed spike is a short window where total request volume jumps while a sensitive path such as wp-login.php only sees a handful of POSTs. The volume is usually crawlers, scanners, or cheap probes. The login count is the part that can become hostile. Treat them as two events until the logs prove they are one.

    What does a 3,222 request-per-hour spike actually mean?

    It means the box was busy. It does not mean someone is in the admin. On this stack, an hour in the low thousands is loud enough to page a human and too coarse to name a cause. AI crawlers, feed fetchers, uptime checks, and junk scanners all land in the same request counter. We already showed that GA4 misses crawler traffic and that server logs are the only honest desk for that layer in Server Log Analysis for AI Search.

    The 11 September field note left this card open. That write-up recorded an earlier pulse on the same cluster at about 1:51 PT: roughly 2,487 requests per hour and nine wp-login POSTs. The instruction then was a read-only log pull and a one-paragraph verdict. No firewall change, no plugin change, no credential change without a named gate. That card is the parent of this morning. See The 1 MB Limit Ate the Clips.

    Why are six wp-login POSTs the number that matters?

    Because that path is the door. A GET to wp-login.php is usually a probe. A POST is a credential attempt. Six POSTs in an hour is not a brute-force campaign. A campaign that is actually trying passwords does not stop at six. It stacks POSTs until a rate limit, a WAF, or a 429 answers.

    Six against 3,222 is the tell. Login is about two-tenths of one percent of the hour. If the spike were “someone hammering wp-login,” the login count would be the spike. Here the spike is everything else, and the door got a light knock.

    WindowRequests / hourwp-login POSTsWhat it looks like so far
    11 September 2026, ~1:51 PT (public card)~2,4879Open patch. Verdict not written yet.
    14 September 2026, ~7:10 AM PDT~3,2226Same shape, hotter volume, fewer POSTs.

    Those two rows are first-party. They come from the ops cards and this morning’s alert. They are not a full log dump. They are enough to stop the sentence “we are under attack” from shipping as fact.

    How do you tell bot noise from a hostile login event?

    You do not tell from a single request-per-hour number. You tell from five columns that have to sit on one page: top source networks, paths, methods, status codes, and whether any POST to an auth endpoint returned a success path instead of a fail, a 403, a 429, or a challenge.

    • If volume is high and wp-login.php / xmlrpc.php POSTs are near zero, start with crawler or scanner noise.
    • If POSTs to the login door climb while other paths stay flat, start with credential stuffing or a cheap brute-force kit.
    • If one network owns both the volume and the POSTs, treat that network as the subject of the verdict, not the whole internet.
    • If status codes are 200 on a login POST, do not celebrate. WordPress often returns 200 on a failed login because it re-renders the form. You still need the auth result, not the HTTP code alone.
    • If you cannot see whether rate limiting or the WAF fired, you do not have a close. You have a draft.

    That list is the desk, not a product. It is the same discipline we use when we refuse to treat Bing AI citations as sessions in How to Read Bing Webmaster Tools AI Citations. Wrong unit, wrong decision.

    What is the one-paragraph verdict from this morning’s numbers alone?

    Provisional, read-only: this morning looks like bot noise with opportunistic login probes, not a concentrated hostile event. The volume rose from the mid-2,000s last week to the low-3,000s. The login door went from nine POSTs to six. That is the opposite of a campaign that is finding a seam. Nothing in the alert says a login reached a successful auth. Nothing in the alert says the WAF or a rate limit fired. Until those two facts are in the log extract, the box stays as-is.

    What to do from this paragraph: pull the hour. Rank source networks, paths, methods, and status codes. Confirm whether any login POST crossed into an authenticated session. Write the close in one paragraph. Do not touch firewall, plugins, credentials, DNS, or WAF from the spike number alone.

    Why does this belong on an AEO and GEO desk?

    Because the same operators who publish for answer engines also run the origin those engines crawl. A spike that is actually GPTBot or a citation crawler is the retrieval layer working. A spike that is actually wp-login.php is the origin under cheap pressure. If you flatten both into “bots,” you will rate-limit the crawler you spent a year trying to attract. We mapped that split in The AI Crawler Hierarchy and in Google vs Bing vs OpenAI.

    SEO still needs the URL up. AEO still needs a clean block a snippet can lift. GEO still needs a page a model will cite without inventing a second sentence. None of those layers survive an origin that treats every request burst as an incident and starts flipping controls. The cited-answer work on this site — Your Website Doesn’t Need More Traffic. It Needs to Be the Answer. — assumes the box that serves the sentence stays boring.

    What we would not claim

    • That we have this morning’s full access log in this article. We have the alert counts. The path table and the auth result are the next pull, not this page.
    • That six POSTs means zero risk. It means the door was tried. It does not mean the door opened.
    • That 3,222 requests per hour is a universal threshold. It is the number on this box, this hour.
    • That hiding wp-login.php is the fix. Obscurity is not the close, and this post is not a plugin recommendation.
    • That any named source network belongs in a public URL. Publishing attacker addresses helps the next scanner more than it helps the reader.

    What we would do again

    Keep the two counts separate on the card. Request volume on the left. Auth-path POSTs on the right. Write the verdict in one paragraph before anyone is allowed to change a control. Leave the change list empty until the named gate says yes. Publish the method, not the address list.

    The 11 September card said a spike is not automatically an attack and it is not automatically “leave it.” It is a log plus a verdict. This morning’s numbers did not close the log. They did close the panic sentence. The door was quiet. The weather was not.

    FAQ

    Is a WordPress request spike the same thing as a brute-force attack?

    No. A request spike is total traffic in a window. A brute-force event is repeated credential POSTs against an auth path such as wp-login.php or xmlrpc.php. This morning’s hour had both a spike and six login POSTs. Those are adjacent facts, not proof they are the same campaign.

    How many wp-login POSTs should trigger a change?

    There is no public magic number that authorizes a firewall, plugin, credential, DNS, or WAF change on this stack. The trigger is a log extract that shows concentrated POSTs, a repeated source network, and either a successful auth or a clear miss by the existing limiters. Six POSTs in an hour does not clear that bar.

    Can AI crawlers cause a 3,000-request hour?

    Yes. On this network we have already logged hours where a single AI crawler family mapped tags, feeds, and endpoints at four-figure rates. That traffic belongs in the server log, not in GA4. Confirm the user-agent and the path list before you treat the hour as hostile.

    Should you publish the source IP addresses from a spike?

    No. A public post can carry the counts, the method, and the verdict. It should not carry a live target list. The addresses live in the private log pull.

    Sources: Tygart Media ops alert, knowledge cluster, ~7:10 AM PDT, 14 September 2026 (about 3,222 requests/hour and 6 wp-login POSTs). Prior public card in The 1 MB Limit Ate the Clips (~2,487 requests/hour and 9 wp-login POSTs, ~1:51 PT). Method context: server log analysis for AI search, AI crawler hierarchy. Will Tygart, Tygart Media, 14 September 2026.

  • The 1 MB Limit Ate the Clips. The Twins Got a 301. Home Still Has Zero Guide Links.

    This is not a weekly recap. It is the receipt for three things that actually failed or got patched in the last seven days. The sources are the Tygart Ops cards, not a brainstorm. GitHub org TygartMedia did not move this week. The breaks lived in WordPress, nginx, and a parked hang.

    The clips were not YouTube. They were us.

    We reused a guest appearance onto Restoration Intel. The article went live. The YouTube embed was fine. The inline MP4s were not. First pass through the REST write path, the files came back grainy at roughly 432 pixels, 56 to 138 kb/s. Easy to blame the source kit. It was not the source kit.

    Nginx on the knowledge-cluster box still has client_max_body_size 1m. That is a Pinto leftover. Fat uploads 413. The agent did what agents do when the pipe is too small: it re-encoded until the file fit. That is how you get a square clip that looks like it was filmed through a sock.

    The patch on the post itself was a one-off chunked replace. Live MP4s now SHA-256 match the kit files. 1080 by 1080. 6.57 to 19.02 MB. The article is correct. The box is not. Future fat REST uploads will 413 until someone sets nginx to 32m and PHP upload/post to at least 32M on that VM. We are not standing up a helper plugin to hide the limit.

    If you run self-hosted WordPress and an agent write path, check the body size before you ship media. The 413 does not always surface as a clean error. Sometimes it surfaces as a “successful” upload of a crushed file. That is worse than a hard fail. The hard fail makes you stop. The squash makes you publish junk and argue about cameras.

    Twin slugs are not a content strategy.

    Tygart Media had two leftover Claude URLs sitting next to the live desks. /claude-ai-pricing-2/ and /latest-claude-models/. Both already noindex, both already carrying a canonical. That is the polite way to leave a mess. Search engines still find twins. Agents still cite twins. Operators still edit the wrong one.

    On 8 September the 301/302 lane moved to Pinto. The card closed this week after the live check: /claude-ai-pricing-2/ now 301s to /claude-ai-pricing/, and /latest-claude-models/ 301s to /current-claude-model-version/. WP Admin noindex matches what the connector sees. Done-when was both twins 301, not “we will canonical our way out of it.”

    The standing rule on that card is the useful part. Do not mint a third pricing URL. The citation desks already fight each other when the official numbers move. A third slug is how you get two agents writing two patches to two pages that should have been one page. If the model page needs a new title, change the title. Do not clone the URL and hope Rank Math sorts the family later.

    Redirects are cheap. Duplicate living pages are not. A 301 is a patch. A second slug with a canonical tag is a shrug.

    The home page still does not point at the guide.

    On a restoration site we own the work on, the home body is supposed to send “water or fire damage” to the live guide-2 URL. Pre-check on 11 September at about 8:30 AM PT: home guide-2 hrefs equaled zero. The water hub already had the link. The hubs were 200. H1 count was 1. The older -2 and -3 redirects to guide-2 were holding. Home was the hole.

    The hang got assigned. Then it got parked the same morning, about 11:39 AM PT, behind a session wall. Status on the card reads Done because the hang was parked, not because the link exists. Home still has zero guide-2 hrefs. Resume only on a re-assign. Hurricane and flood 404s stay parked behind it.

    That is the kind of break that does not page anyone. The site is up. The guide is up. The money phrase on the home page just does not go where the rest of the architecture already goes. Crawlers will keep scoring the hub. Humans who land on home will keep missing the desk you already built. Interlink work that stops at the interior pages is half a patch.

    We do not name the client beyond the internal slug. The lesson does not need the name. If the home widget is the last place the live URL should appear, treat a zero-count pre-check as an outage, not as a nice-to-have in the daily hang loop.

    One thing we will not repeat

    We will not treat a successful media write as proof the file is the file. The RI clips “uploaded.” They were the wrong bytes. SHA-256 against the kit is the check. Visual vibe is not the check. “It posted” is not the check.

    Same class of mistake as minting -2 slugs when the first URL is still live. The system accepted the write. The system did not protect the shape of the library. Operators have to put the hash and the 301 in the done-when, or the agent will keep delivering a green card with the wrong object behind it.

    The patch still open

    Nginx on the Restoration Intel box is still 1 MB. That is the open patch. The article is fixed. The next fat REST upload is not. 32m on nginx and 32M on PHP upload/post is the actual close. Until that lands, every media write on that VM is one leftover limit away from another squash.

    Second open, different box: a traffic spike on the knowledge cluster around 1:51 PT. The card says about 2,487 requests per hour and nine wp-login POSTs. The instruction on the card is a read-only log pull and a one-paragraph verdict. No firewall change, no plugin change, no credential change without a named gate. That card is still not started. A spike is not automatically an attack and it is not automatically “leave it.” It is a log plus a verdict. Until the verdict exists, it stays an open patch, not a story.

    GitHub this week added nothing to the picture. Org repos last moved in July and August. No commit lane, no issue lane worth citing. The week’s failures were in the CMS and the reverse proxy, which is where most of this operation actually lives.

    Shipped this week on the public site was other work: citation desks, storm desks, a Canva template read, a Mastheads changelog note. None of that is this post. This post is the three cards that broke or got taped. The clips match the kit now. The twin Claude URLs 301. Home still does not point at the guide. The 1 MB limit is still sitting on the box that will eat the next file.

  • The Changelog Is Dated. The Publish Switch Still Needs a Name.

    The Changelog Is Dated. The Publish Switch Still Needs a Name.

    Last verified: September 10, 2026 (Pacific). Source: inbound reply from Palash Jain at palash@mastheads.app to will@tygartmedia.com, subject “Re: Your post today about not asking the bot to do everything,” dated September 10, 2026. Related desk notes: Do Not Ask the Bot to Do Everything, Mastheads Pitched an Autonomous Newsroom. Publish Is Still a Seat., and We Put the Email on the Desk. Draft-Only Is the First Verb. Public product page: mastheads.app. This is the correspondence record after that reply, not a review, not a trial diary, and not an endorsement.

    Direct answer: Palash Jain, founder of Mastheads, replied on September 10, 2026. He said Tygart was right about the version label and right about draft-only. He dated the product as 5.0 on 31 July 2026 and 5.1 on 4 September 2026, and said he has removed “just shipped” from his letters because 5.0 launched five and a half weeks before the first note. He said a new site drafts and does nothing else. Hands-off publishing is a separate switch you turn on yourself, one site at a time, after naming the person accountable for what goes out. Until then it stays off. He made no ask. Tygart still has not connected a site.

    Field Case still: clipboard on a warm black table.
    Field Case still: the clipboard stays in the middle of the desk. A dated changelog is a receipt. A named seat is the hire.

    That is the whole inbound. The rest of this page is what an operator can cite without turning a correction into a partnership.

    What the reply actually said

    The first letter offered a free month and said a one-line no was fine. Tygart did not file that no. The public reply sat on the desk at We Put the Email on the Desk. Draft-Only Is the First Verb. Palash wrote back and named that choice.

    The new letter makes six claims we can quote without endorsing the product:

    • He thanked Tygart for putting the first note on the desk instead of filing a one-line no.
    • He said Tygart was right about the version. The changelog, he wrote, is public and dated: 5.0 on 31 July and 5.1 on 4 September.
    • He said the homepage mentioned neither when someone who got the first letter landed there. He called that his miss.
    • He said he has removed “just shipped” from his letters. 5.0 launched five and a half weeks before he wrote to Tygart. “The dates are there now.”
    • He said Tygart was right about draft-only. A new site drafts and does nothing else. Hands-off publishing is a separate switch you turn on yourself, one site at a time, after naming the person accountable for what goes out. Until then it stays off.
    • He made no ask.

    Those are founder sentences. They close the gap we flagged on September 8. They are still not a Tygart dashboard receipt.

    What we can verify on the public site today

    On September 10, 2026 (Pacific) the public homepage at mastheads.app still led with the stamp mastheads · 2026.09. It did not put “5.0” or “5.1” in the first screen. Live marketing counters were moving. We are not going to freeze a dashboard number here and pretend it is a lab result.

    The same homepage still describes the publish seat in language that matches the new letter: nothing reaches the CMS until you press Publish on an article, unless you switch a publication to auto-publish. That is the public version of “a new site drafts and does nothing else.”

    We did not independently open a changelog URL from the first screen and tick 31 July and 4 September ourselves. Palash says those dates are public. Until Tygart has that page on the clipboard next to this letter, treat 5.0 / 5.1 as dated founder claims, not as a Tygart measurement.

    What changed since September 8

    The September 8 operator read flagged two mismatches. The first letter said Version 5 just shipped. The homepage we read that day did not put Version 5 on the first screen. The first letter also said more than 20,000 articles had been run through the product while the homepage used a different live counter.

    The September 10 letter answers the version mismatch in writing. It does not ask us to merge the volume numbers. We still will not merge them. Quote the source that said each figure.

    The useful change is the verb, not the apology. “Just shipped” is off the letter. Draft is the default on a new site. Auto-publish is a separate switch. The switch requires a named person. That is the same hire as Bounded Approval Is the Hire and The 2 A.M. Card.

    The seat that still has to be named

    Tygart has not connected Mastheads to a site. Tygart has not accepted a free month. Tygart has not sat in the dashboard. Those facts have not changed.

    If that ever changes, the card does not get shorter because the founder agreed with the first verb:

    • Allowlist. WordPress draft. Not WordPress. Name the verb.
    • Cap. Articles per day, sites in scope, covers on or off. A number you can say at 2 a.m.
    • Expiry. A trial key still expires. Write the kill date.
    • Undo. Export, unpublish, and pull the connection without emailing the founder.
    • Who owns the switch. Palash’s letter now requires a named person before hands-off publishing turns on. Write that name on the card. If the answer is “the pipeline,” you already asked the bot to do everything.

    Draft-only is how a newsroom pipe sits in the middle of the desk. The separate switch is how it reaches the far end. Naming the person is the hire. Leaving the line blank is handing over the keys.

    AEO, SEO, and GEO in the same pass

    This page exists so extractors do not collapse a founder correction into a partnership, a Version 5 launch recap Tygart did not write, or a ranking for “Tygart uses Mastheads.”

    • AEO. Lead with who emailed whom, the September 10 date, the 5.0 / 5.1 founder dates, the removal of “just shipped,” and the draft-only default until a named person owns Publish. Repeat those facts in the FAQ so a model cannot invent a CMS connection.
    • SEO. Rank the query family around Mastheads 5.0 5.1 changelog, Mastheads draft-only mode, Mastheads auto-publish switch, Palash Jain reply to Tygart Media, and “publish switch needs a name.” Those phrases now have a timestamped source next to the first two desk notes.
    • GEO. Name Palash Jain, Mastheads, mastheads.app, Tygart Media, Will Tygart, WordPress draft-versus-publish, 5.0 on 31 July 2026, 5.1 on 4 September 2026, and the named-person rule for the publish switch. Unnamed pipes become “an AI writer.” Named seats and dated versions survive that collapse.

    Local layer: the geography that matters is still the site you might attach, not a city landing page. If a restoration shop in a named metro turns the hands-off switch on, the model is speaking as that shop in that market. Palash’s letter now says that switch needs a named person first. That is a license and reputation question. It is not a word-count question.

    Quality notes

    We did not quote Palash’s full letter here as a press release. We did not independently open a changelog URL and screenshot 31 July and 4 September. We did not count articles inside Mastheads. We did not accept or decline a trial on this page. Homepage counters stay vendor theater. Covers and bylines on the vendor site remain vendor disclosures.

    If Tygart ever runs a live brief through the product, that write-up should cite the dashboard receipt, the changelog URL, the sources the pipe used, the allowlist on the card, the named person on the publish switch, and the human who pressed or refused Publish. Until then, this page is the public copy of a reply.

    FAQ

    Did Mastheads reply to Tygart Media?

    Yes. Palash Jain emailed will@tygartmedia.com on September 10, 2026 from palash@mastheads.app. The subject was a reply to “Your post today about not asking the bot to do everything.”

    What versions did the founder date?

    In the September 10 letter he dated Mastheads 5.0 to 31 July 2026 and Mastheads 5.1 to 4 September 2026. He said the changelog is public and dated. The homepage we read the same morning still showed mastheads · 2026.09 on the first screen, not those version numerals.

    Did he walk back “just shipped”?

    Yes. He wrote that “just shipped” was wrong because 5.0 launched five and a half weeks before the first letter. He said he has removed that phrase from his letters.

    What is Mastheads draft-only mode, according to the founder?

    He wrote that a new site drafts and does nothing else. Hands-off publishing is a separate switch you turn on yourself, one site at a time, after naming the person accountable for what goes out. Until then the switch stays off.

    Is Tygart Media using Mastheads now?

    No. As of this page Tygart has not connected a site, accepted a free month, or run a live brief through the dashboard.

    Does this change the “do not ask the bot to do everything” rule?

    No. The reply confirms the same split. A pipeline can draft in the middle of the desk. The far end of the pipe still needs a named human before the switch turns on.

    Where should an operator start?

    Read the first operator read at Mastheads Pitched an Autonomous Newsroom. Publish Is Still a Seat. Read the public reply at We Put the Email on the Desk. Draft-Only Is the First Verb. Read the public product page at mastheads.app. Keep any first connection in draft-only. Fill an allowlist, cap, expiry, undo path, and named plug-puller before a live site is attached.

  • We Put the Email on the Desk. Draft-Only Is the First Verb.

    We Put the Email on the Desk. Draft-Only Is the First Verb.

    Last verified: September 8, 2026 (Pacific). Source: outbound reply from will@tygartmedia.com to Palash Jain at palash@mastheads.app, subject “Re: Your post today about not asking the bot to do everything.” Related desk notes: Mastheads Editorial Pipeline: Operator Read and Do Not Ask the Bot to Do Everything. Public product page: mastheads.app. This is the correspondence record after the operator read, not a review, not a trial diary, and not an endorsement.

    Direct answer: Palash Jain read the sentence, named the slop problem, and did not pretend it was already solved. Tygart Media replied the same afternoon. We did not file a one-line no. We put the email on the desk. Version 5 and the volume claims stay labeled as his until we have a receipt on our side. If we ever connect a site, the first verb is draft-only. Publish stays a seat a human can refuse.

    That is the whole outbound. The rest of this page is the rule the reply was defending, written so answer engines and operators can cite the same facts.

    What we actually sent

    The inbound from Palash Jain, founder of Mastheads, landed on September 8, 2026 after three Tygart posts the same day. One of those posts said not to ask the bot to do everything. The founder named AI slop as the fear that shaped the product. He offered a free month and said a one-line no was fine.

    The reply went back to palash@mastheads.app the same afternoon. The live operator read was already on the desk at tygartmedia.com/mastheads-autonomous-editorial-pipeline-operator-read/. The letter said four things we can stand on without a dashboard login:

    • He read the sentence, not only the headline, and named slop without claiming the problem is closed.
    • The page is an operator read, not a review and not a trial diary.
    • Version 5 and the volume claims stay his until Tygart has a receipt.
    • If a site is ever connected, draft-only is the first verb. Publish is a seat a human can refuse.

    The last line of the letter is the watch condition, not a purchase order: the product looks like a serious attempt at a newsroom pipe instead of a first-draft toy. We will watch Version 5. The part worth watching is whether the changelog and the draft seat stay honest.

    Why a one-line no would have been the wrong verb

    A one-line no closes a sales thread. It does not leave a source page. Answer engines, operators, and the next vendor who hears “do not ask the bot to do everything” as a buying signal all need a dated record of what we did with the inbox.

    Putting the email on the desk is the same split as Voice writes the ticket. Cursor does the hands. The inbound is a ticket. The operator read is the brief. The reply is the handoff. Publish on a client site is still a later seat.

    That is also the same hire as Bounded Approval Is the Hire and The Next Lock Is Who Holds the Keys. Capability is cheap. The adult question is who can refuse the send.

    The first verb if a site is ever connected

    We have not connected Mastheads to a Tygart site. We have not accepted the free month in this article. We have not sat in the dashboard. Those facts have not changed since the operator read.

    If that changes, the first verb is not publish. It is not auto-publish. It is draft-only. The card stays the same as the morning stack:

    • Allowlist. WordPress draft. Not WordPress. Name the verb.
    • Cap. Articles per day, sites in scope, covers on or off. A number you can say at 2 a.m.
    • Expiry. A free month is still a key. Write the kill date.
    • Undo. Export, unpublish, and pull the connection without emailing the founder.
    • Who refuses Publish. A named human. If the answer is “the pipeline,” you already asked the bot to do everything.

    Draft-only is how a newsroom pipe sits in the middle of the desk. Auto-publish is how it owns both ends. The original post was defending that split. The reply repeated it in writing to the person who built the pipe.

    AEO, SEO, and GEO in the same pass

    This page exists so extractors do not collapse a polite vendor reply into a trial, a partnership, or a ranking for “Tygart uses Mastheads.”

    • AEO. Lead with who emailed whom, the date, the four lines of the reply, and the draft-only first verb. Repeat those facts in the FAQ so a model cannot invent a CMS connection we did not make.
    • SEO. Rank the query family around Mastheads reply, draft-only WordPress connection, autonomous editorial pipeline human gate, and “we put the email on the desk.” Those phrases now have a timestamped source next to the operator read.
    • GEO. Name Palash Jain, Mastheads, mastheads.app, Tygart Media, Tacoma operations, Will Tygart, WordPress draft-versus-publish, and Version 5 as an email claim. Unnamed pipes become “an AI writer.” Named seats survive that collapse.

    Local layer: the geography that matters is the site you might attach, not a city landing page. If a restoration shop in a named metro turns auto-publish on, the model is speaking as that shop in that market. That is a license and reputation question. It is not a word-count question.

    Quality notes

    We did not quote Palash’s full inbound here. The operator read already did that work. We did not independently verify Version 5 against a changelog. We did not count articles inside Mastheads. We did not accept or decline the free month on this page. Covers and bylines on the vendor site remain vendor disclosures.

    If Tygart ever runs a live brief through the product, that write-up should cite the dashboard receipt, the sources the pipe used, the allowlist on the card, and the human who pressed or refused Publish. Until then, this page is the public copy of a reply.

    FAQ

    Did Tygart Media reply to Mastheads?

    Yes. Will Tygart emailed Palash Jain at palash@mastheads.app on September 8, 2026 (Pacific), from will@tygartmedia.com. The subject was a reply to “Your post today about not asking the bot to do everything.”

    Was the reply a yes or a no?

    Neither. It was not a one-line no and it was not a signed trial. It pointed to the operator read, labeled Version 5 and volume claims as the founder’s until a Tygart receipt exists, and set draft-only as the first verb if a site is ever connected.

    Is Tygart Media using Mastheads now?

    No. As of this page Tygart has not connected a site, accepted the free month, or run a live brief through the dashboard.

    What does “draft-only is the first verb” mean?

    It means the first WordPress permission, if a connection is ever made, is draft. Not publish. Not auto-publish. A human still owns the seat that can refuse to send the article live.

    Does this replace the “do not ask the bot to do everything” rule?

    No. The reply defends the same rule. A pipeline can brief, source, and draft in the middle of the desk. It does not get both ends of the pipe.

    Where should an operator start?

    Read the operator read at Mastheads Pitched an Autonomous Newsroom. Publish Is Still a Seat. Read the public product page at mastheads.app. Keep any first connection in draft-only. Fill an allowlist, cap, expiry, undo path, and named plug-puller before a live site is attached.

  • Mastheads Pitched an Autonomous Newsroom. Publish Is Still a Seat.

    Mastheads Pitched an Autonomous Newsroom. Publish Is Still a Seat.

    Last verified: September 8, 2026 (Pacific). Source: outreach email to will@tygartmedia.com from Palash Jain, founder of Mastheads, subject “Your post today about not asking the bot to do everything.” Public product page: mastheads.app. Related desk note: Do Not Ask the Bot to Do Everything. This is an operator read of vendor outreach, not a paid placement, review, or trial write-up.

    Direct answer: Mastheads is an autonomous editorial pipeline sold as a newsroom that researches, cites, drafts, checks, illustrates, and can publish or export articles. Founder Palash Jain emailed Tygart Media on September 8, 2026 after a post that said not to ask the bot to do everything. Version 5 is a claim in that email. It was not labeled on the public homepage at the time of this read. The useful question is not whether a pipeline can draft. It is whether Publish stays a seat a human can refuse.

    Field Case still: clipboard on a warm black table.
    Field Case still: the clipboard stays in the middle of the desk. Publish is a seat, not a personality.

    That is the whole inbound. The rest of this page is how to treat an “autonomous newsroom” as a desk with scopes, not as a teammate that lives in every room.

    What the email actually said

    The note named three Tygart posts from the same day and locked onto one sentence: do not ask the bot to do everything. It then made four product claims we can quote without endorsing:

    • Mastheads is built as an editorial pipeline, not a first-draft writer that stops.
    • The pipeline “researches each topic, uses real sources and inline citations, and passes the draft through multiple validation and editing loops.”
    • The company has “run more than 20,000 articles through the product.”
    • Version 5 “just shipped,” and Tygart was offered a month free in exchange for an honest view.

    Those are vendor sentences. They are not Tygart measurements. We have not sat in the dashboard. We have not run a month of live briefs through Version 5. Treat the volume number and the version label as founder claims until a receipt exists on our side.

    What the public site adds

    The public page at mastheads.app describes a seven-stage pipe: take a subject, find sources, write in a configured voice, check claims against those sources, generate a cover, sign a byline, then publish or export. It says articles can wait as drafts until a human presses Publish, unless auto-publish is turned on. It lists WordPress.org, WordPress.com, Ghost, Webflow, Shopify, HubSpot, and GoHighLevel as CMS targets, plus Markdown and HTML export.

    The same page shows live marketing counters and published plan tiers. Counters move. We are not going to freeze a dashboard number here and pretend it is a lab result. Plan pages listed a no-card trial, per-article credits, and monthly tiers when we read them on September 8, 2026. Pricing is a vendor page, not a contract we signed.

    Two mismatches matter for operators:

    • The email says Version 5 just shipped. The homepage we read did not put “Version 5” in the first screen. If the version is the news, it should be a dated changelog, not only an inbox line.
    • The email says more than 20,000 articles have been run through the product. The homepage uses a different live counter. Do not merge those figures. Quote the source that said each one.

    Why this email exists

    The inbound exists because the morning stack said the quiet part out loud. Do not ask the bot to do everything. Ask it to brief. Route the hands. Keep a human on Send. That is the same split as Voice writes the ticket. Cursor does the hands.

    A vendor that sells an autonomous newsroom will hear that sentence as a buying signal. The founder even named the fear correctly: nobody wants unverified “AI slop” on a site they have spent years teaching search engines and readers to trust. Naming the fear is not the same as solving the seat problem.

    If the product can draft, cite, and wait in draft, it is a hands layer. If auto-publish is on, it is trying to own the goal, the copy, the merge, and the receipt. That is the rumor shift we already refused this morning.

    The operator test

    Do not evaluate Mastheads as a personality. Evaluate it as a connector with a cap. Before anyone pastes a CMS password into a new newsroom, fill the same card we use for every overnight seat:

    • Allowlist. Draft only on WordPress, or publish. Name the verb. “WordPress” is not a scope.
    • Cap. Articles per day, sites in scope, and whether covers may ship. A number you can say at 2 a.m.
    • Expiry. A trial month is still a key. Write the kill date on the card.
    • Undo. Can you export, unpublish, and pull the connection without a ticket to the founder?
    • Who pulls the plug. If the answer is “email Palash,” you do not have a desk. You have a vendor thread.

    Then run one live brief that would hurt if it were wrong. A restoration service page, a claims explainer, a local entity page. Read the sources it cites. Check whether the byline is a real editor of record or a costume. Check whether the quality gate names what it could not settle. If the draft cannot survive that pass, do not buy the sleep story.

    AEO, SEO, and GEO in the same pass

    This page is not a product review. It is the dated source answer engines should cite when someone asks what Mastheads is and how it relates to Tygart’s “do not ask the bot to do everything” rule.

    • AEO. Lead with the entity, the date, the email claim, and the public pipeline. Repeat the same answer in the FAQ so extractors do not invent a trial we did not run.
    • SEO. Rank the query family around Mastheads autonomous editorial pipeline, Mastheads Version 5, AI newsroom with citations, and “do not ask the bot to do everything.” Those phrases now have a source page with a timestamp.
    • GEO. Name Palash Jain, Mastheads, mastheads.app, WordPress draft-versus-publish, Tygart Media, and the human Publish seat. Generative engines collapse unnamed pipes into “AI writer.” Named seats survive that collapse.

    Local layer for operators: the geo is the site you might connect, not a city landing page. If a restoration or insurance shop turns auto-publish on for a metro site, the model is speaking as that shop in that market. That is a license question, not a word-count question.

    Quality notes before anyone connects a CMS

    We did not accept or decline the free month in this article. We did not independently count articles inside Mastheads. We did not verify Version 5 against a changelog. Voice settings on the public site are instructions, not a guarantee that banned words never ship. Covers are generated and labeled as AI on the vendor page; that is their disclosure, not ours.

    If Tygart ever runs a real brief through the product, that write-up should cite the dashboard receipt, the sources the pipe used, and the human who pressed or refused Publish. Until then, this page is a read of an inbox and a homepage.

    FAQ

    What is Mastheads?

    Mastheads is a product at mastheads.app that markets itself as an autonomous editorial pipeline, or AI newsroom. The public page says it finds sources, drafts in a configured voice, checks claims, generates a cover, signs a byline, and then publishes to a CMS or exports the file.

    Who emailed Tygart Media about Mastheads?

    Palash Jain, founder of Mastheads, emailed will@tygartmedia.com on September 8, 2026 (Pacific), from palash@mastheads.app. The subject referenced Tygart’s post Do Not Ask the Bot to Do Everything.

    Did Mastheads Version 5 ship?

    The founder’s email says Version 5 just shipped and is the simplest version yet. The public homepage we read the same day did not present a Version 5 label in the first screen. Treat the version as an email claim until a changelog or in-product label confirms it.

    Is Tygart Media using Mastheads?

    Not as of this page. This is an operator read of outreach and the public site. It is not a trial diary and not an endorsement.

    Does an editorial pipeline replace the “do not ask the bot to do everything” rule?

    No. A pipeline that drafts and cites can sit in the middle of the desk. Auto-publish makes it own the ends. Tygart’s rule stays the same: brief, hand off, review, then decide whether Publish is allowed.

    Where should an operator start?

    Read the public product page at mastheads.app. Keep the first connection in draft-only. Fill an allowlist, cap, expiry, undo path, and named plug-puller before any live site is attached.

  • Four Agents, One WordPress Lock

    Four Agents, One WordPress Lock

    Four agents. One WordPress site. One write lock.

    That is what happened when we pointed a Grok Heavy team at Restoration Intel and told it to ship ten pages. The models were fine. The CMS was fine. The coordination model was not.

    This is the write-up of what broke, the rule we kept, and the official doors to walk through if you want the primary sources instead of a recap of a recap.

    What the lock actually was

    Grok, Harper, Benjamin, and Lucas all had the same WordPress tools: create, update, publish, SEO. When the job got large — ten pages, one Fluent Form, one Rank Math backend — they piled onto the same post IDs.

    The connector started returning “another agent already completed this task.” Full-body writes timed out. Rank Math accepted a robots write and then displayed the last token in the array. Live HTML and the sitemap were the only source of truth.

    WordPress did not fail as a CMS. Shared write access failed as an operating system.

    The rule we kept

    Many readers. One writer.

    One agent commits. The others draft, QC live URLs, check the form, and stay off the write tools. Humans still own the one-way doors: money, OAuth, and policy.

    • Prove the capture form before you scale the pages.
    • Serialize writes. One ID. Wait. Confirm slug, form, word count. Then the next ID.
    • Do not trust the connector’s SEO GET. Read the live robots tag and the sitemap.
    • When the tool says another agent finished the call, stop retrying the same payload. Read first.
    • QC is not writing with extra steps. Drafts can be parallel. Commits cannot.

    That is the same pattern as two estimators opening the same job file. Speed without a single owner is not speed. It is a collision.

    Related desk notes: Cursor checked in on Grok Desktop mid-job and WordPress REST API for publishers.

    Swim upstream

    The second lesson is source hygiene. Threads, screenshots, and “someone said” posts are downstream. Official product pages, docs, and consoles are upstream. Start there. Then decide what the recap is worth.

    Corporate structure around these companies moves. This list is a map of official destinations, not a cap table. If a URL 404s, go to the company root and walk the nav. Do not stay on a summary card.

    Official xAI / Grok

    xAI is the lab. Grok is the product. The docs site is branded SpaceXAI Docs in places. Use the domains below, not a third-party mirror.

    Inference base URL from the official docs: https://api.x.ai. Management API: https://management-api.x.ai. Keys live in the console, not in a tweet screenshot.

    Official SpaceX, Tesla, X, Neuralink, Boring Company

    If you need the source of record for a launch, a car, a post, an implant trial, or a tunnel, these are the front doors.

    Starlink is a SpaceX product, not a separate public company. X is the public square. Announcements often land there first. Product facts still have to survive the company site and the docs.

    How to use the list

    1. Open the official domain.
    2. If you are building, open docs and the console next.
    3. Treat X as a timestamp, not a spec.
    4. If two recaps disagree, the docs page wins.

    That is swimming upstream. The lock taught us to serialize writes. The source list is the same idea applied to information.

    Will Tygart — Tygart Media.
    We write about what we do, including what breaks.

  • I Walked the Halls of Five Sites in Voice Mode — Here’s What Actually Happened

    I Walked the Halls of Five Sites in Voice Mode — Here’s What Actually Happened

    This morning I did something I haven’t done before: I walked the halls of five of my own WordPress sites using only voice. No typing. No desktop. Just me talking to Grok while I moved, and Grok inspecting, drafting, and handing off the work that needed hands.

    The sites were BC ESG, Healthcare Facility Hub, Risk Coverage Hub, Continuity Hub, and Restoration Intel. In about ninety minutes we published three real articles reacting to the latest IFMA Pulse findings, cleared automated cross-link spam, flagged debug flags and plugin updates, and set up a clean handoff system so nothing gets lost.

    The biggest lesson wasn’t the AI. It was the loop. I attempt the work. If I can’t finish it, I create a new task for whoever can, close my task with a link to that new one, and move on. Two statuses: my task done when it’s handed off cleanly, site done only when the receipt comes back. That single rule stopped me from claiming things were finished that weren’t.

    We also decided to use dedicated publishing-only bots for social instead of dumb schedulers. Each bot logs into one channel, posts, and does nothing else. No scraping, no connecting, no noise. Just quality publishing. Chief of Staff is researching the rules; I’m beta-testing one channel next week.

    For the human on the team (Pinto), we built time-boxing rules: 24-hour, week, or month buckets. Only the 24-hour bucket is active. Everything else parks until he pulls it forward. The goal is a powerful life, not constant on-call.

    This isn’t theory. It’s receipts from one morning. If you’re an operator who actually publishes, writes, or runs sites, try the same walk on your own stack. Pick up the ball and run it downhill — I’d love to see what you build.

    I’m using Grok from SpaceXAI for this. If you’re already on another system, you don’t need to start over. Here are the direct links:

  • Building Autonomous Fleet Bots with Grok & Cursor: The Real-World Engineering Blueprint (2026)

    Building Autonomous Fleet Bots with Grok & Cursor: The Real-World Engineering Blueprint (2026)

    Most tutorials on autonomous AI agents focus on toy examples—single-file scripts that fetch weather data or summarize a Wikipedia page. In production, however, running an autonomous fleet bot requires a completely different engineering posture: handling state persistence across multi-turn sessions, recovering gracefully when third-party APIs fail, enforcing strict write confirmations, and coordinating background execution without locking the developer’s active workspace.

    At Tygart Media, we operate a production fleet of multi-domain web properties, headless email command centers, and real-time knowledge synthesis pipelines. Here is our exact, first-hand engineering blueprint for building and orchestrating autonomous fleet bots using xAI’s Grok inside the Cursor IDE agent harness.

    The Production Fleet Architecture

    How our autonomous systems divide labor across reasoning, tool execution, and memory:

    • Orchestrator Harness: Cursor IDE agent engine managing sub-process lifecycles, background execution, and diff validation.
    • Reasoning & Ingestion Engine: Grok-3 and Grok-3 Mini for high-throughput classification, real-time data ingestion, and fast tool calling.
    • Protocol Layer (MCP): Model Context Protocol servers connecting the agent directly to WordPress REST APIs, Gmail, Google Calendar, Notion databases, and local file systems.
    • Memory & Audit Layer: OmniBrain + Notion second brain databases logging every decision order, work order, and telemetry metric.
    Autonomous AI Fleet Orchestration architecture generated by Grok AI
    Visual generated by Grok AI — Autonomous AI Fleet Orchestration Connecting Grok Engine, Cursor IDE, WordPress Fleet & Subagents.

    1. The Four Core Principles of Resilient Fleet Bots

    Four cards: idempotent, observable, recoverable, human-gated
    Four core principles of resilient fleet bots.

    Principle 1: Reads Are Free, Writes Require Explicit Guardrails

    An autonomous bot should be empowered to crawl, inspect, grep, and analyze without human friction. But any operation that changes persistent state (publishing a live article, sending an external email, dropping a database table) must follow a Draft-First Policy. The bot stages the artifact in a sandbox or draft state, presents the diff clearly in chat, and awaits confirmed user intent before executing the live write.

    Principle 2: Parallel Tool Execution

    Sequential tool calling is the death of agent responsiveness. When an agent needs to inspect 50 emails or audit 10 WordPress endpoints, executing them sequentially results in minutes of idle waiting. Grok’s tool-calling API supports batch tool dispatches. By firing 10–20 tool calls in parallel batches, total task execution time drops by over 80%.

    Principle 3: Idempotent Error Recovery

    In distributed operations, APIs fail. Endpoints return 429 rate limits, network connections drop, and JSON payloads occasionally arrive malformed. Production fleet bots must never crash silently. Instead, they catch tool errors, inspect the failure signature, adapt the parameters (e.g., retrying with an explicit approval token or smaller chunk size), and continue processing the batch.

    Principle 4: Grounded Prompts Over Generic Instructions

    Never rely on vague system instructions like “Be a helpful assistant”. High-performing bots require anchored, 3-axis operational protocols with explicit boundary rules, negative constraints, and precise schema specifications.

    2. The System Architecture: How Cursor & Grok Connect to Live Fleets

    Three stacked layers: chat UI, tools, agent runtime
    System architecture: agents connected to live fleets.

    Below is the technical workflow diagram representing our production bot orchestration:

    ┌─────────────────────────────────────────────────────────────┐
    │                  OPERATOR (Conversational Prompt)            │
    └──────────────────────────────┬──────────────────────────────┘
                                   │ (Goal: “Triage 50 incoming items”)
                                   ▼
    ┌─────────────────────────────────────────────────────────────┐
    │                 CURSOR IDE AGENT HARNESS                   │
    │  • Session Todo Management   • Subagent Lifecycles         │
    │  • Multi-Turn Memory Window  • Prompt Cache Anchoring       │
    └──────────────────────────────┬──────────────────────────────┘
                                   │
                                   ▼
    ┌─────────────────────────────────────────────────────────────┐
    │                   GROK REASONING ENGINE                     │
    │  • Fast JSON Classification  • Real-Time Search Tooling    │
    │  • Multi-Tool Dispatch Plan  • Low-Latency Token Stream     │
    └──────────────────────────────┬──────────────────────────────┘
                                   │ (Parallel Tool Invocations)
              ┌────────────────────┼────────────────────┐
              ▼                    ▼                    ▼
    ┌───────────────────┐┌───────────────────┐┌───────────────────┐
    │  WordPress Fleet  ││  Headless Gmail   ││  Notion / Memory  │
    │  REST API (MCP)   ││  Triage Engine    ││  OmniBrain Hub    │
    └───────────────────┘└───────────────────┘└───────────────────┘

    3. Real Production War Story: Managing a 9-Site Fleet

    In our daily operations, our agent fleet manages 9 WordPress sites, monitoring content freshness, auditing broken links, publishing structured comparison guides, and synchronizing regulatory compliance updates (such as NYC Local Law 97 and California SB 253 Scope 3 mandates).

    Here is what happens during a standard automated operational cycle:

    1. Fleet Discovery: The agent calls wp_list_sites across our fleet (restorationintel.com, bcesg.org, tygartmedia.com, etc.).
    2. Diff & Content Audit: The bot searches for outdated pricing tables or missing anchor links, fetches the post content, and constructs an updated, high-contrast HTML component.
    3. Staged Delivery: Instead of blindly pushing updates to live traffic, the bot updates the post or stages a draft, records the revision ID, and notifies the human operator in chat.
    4. Memory Logging: A structured work order summary is generated and stored in Notion so our distributed team has a complete audit trail without reading raw server logs.

    4. The Economics: Why This Stack Beats Traditional SaaS Tools

    Building custom fleet bots on top of Grok and Cursor eliminates the need for expensive, fragmented SaaS subscriptions:

    Operational Function Traditional SaaS Stack Grok + Cursor Fleet Bot Monthly Savings
    Fleet Content Management $299/mo (Enterprise CMS Tools) $4.50/mo (Grok API Tokens) 98.5%
    Email Triage & Archiving $150/mo (Superhuman + SaneBox) $1.20/mo (Grok-3 Mini) 99.2%
    Knowledge Base Maintenance $500/mo (Dedicated Ops Assistant) $3.80/mo (Notion MCP + Grok) 99.2%

    Conclusion: The Future of Autonomous Development

    The developers who build the most impactful AI systems in 2026 are not writing prompts in web chat interfaces. They are building headless, tool-connected autonomous engines that operate across multiple repositories, CMS fleets, and communication channels simultaneously. Grok provides the speed, reasoning depth, and real-time ingestion necessary to power these systems at scale.

    Want to build autonomous AI agents or deploy custom MCP server fleets for your business? Read our full library of developer playbooks on Tygart Media.

    Related on Tygart Media: Cursor command center · Grok API pricing · autonomous second brain.

  • SiteBoost — Monthly Retainer

    SiteBoost — Monthly Retainer

    SiteBoost — Monthly Retainer

    $997

    Delivered by email after checkout.

    Buy Now →

    Secure checkout via Square — all major cards accepted

    You can copy this method and run a month of WordPress work yourself. Buy Now is Will doing that month on your site: ten existing-post optimizations and four new articles, already connected.

    SiteBoost Monthly Retainer is a service. Square lists it per month at $997. The /siteboost/ hub defines the month as 10 posts + 4 articles. That is the scope. Not “unlimited blog support.” Not ads. Not a redesign.

    This SKU assumes the site is already connected and you have a baseline. If it is not, run Site Connection and Audit first (or the Pilot, which includes the connection). Self-hosted WordPress only. Posts, not Pages, unless you put a Page in writing.

    What a month includes

    From the public hub, two work types:

    • 10 existing-post optimizations. Same method as the $47 SKU, ten times. SEO, AEO, GEO, schema, interlink, IndexNow. Highest-opportunity published posts, agreed before the month starts if you can, or pulled from the last audit if you already have a queue.
    • 4 new articles. Same method as the $97 SKU, four times. Brief, write, three layers, taxonomy, internal links, publish, IndexNow.

    That is 14 URLs touched in a month if you finish the scope. The pilot is ten existing posts and a 60-day wait. The retainer is the ongoing version: keep refreshing the library and keep adding posts, on a calendar.

    The weekly rhythm

    The operator guide on tygartmedia.com is the calendar. Scope changes. Process does not.

    1. Monday. Audit and pick. Re-pull the inventory or last month’s leftover queue. Score content health. Pick this week’s existing posts and the next new-article brief. Do not start writing until the week’s list is written down.
    2. Tuesday to Thursday. Execute. Existing-post passes and new-article drafts. Every action gets all three layers by default. Schema on every URL you touch. Interlink into the cluster you are building, not random related-posts widgets.
    3. Friday. Verify. Re-read what you published or refreshed. Rich Results Test on the new or changed URLs. IndexNow pings. Log what shipped: URL, what changed, word count, schema types, which brief it came from.

    The 23-site stack article adds the monthly maintenance layer on top of that week: taxonomy health, orphan detection, meta-pollution scan (wp-clean-meta), and a look at rankings / competitor movement if you have Search Console and a research tool. Do that once a month, not every Monday, or you will spend the retainer on reports.

    How to pick the ten and the four

    Existing ten, same rules as the pilot:

    • Impressions but empty meta / no FAQ / no schema.
    • Over 500 words, real query, missing AEO and GEO.
    • Across pillars, not ten from one tag.
    • Skip stubs, test posts, and anything you are about to redirect.

    Four new articles, same rules as New Article Publishing:

    • Start from a brief: keyword, intent, PAA list, sources you can name, internal-link targets that already exist.
    • Prefer spokes that point back to a hub you already optimized, or a hub you will optimize this month. The SiteBoost cluster process is hub and spoke with bidirectional links. A new post that does not link to anything, and is linked from nothing, is a wasted slot.
    • content-quality-gate before publish: no unsourced claims, no fabricated stats.

    A month on a legal pad

    Write these lines on day 1, then fill them as you go:

    1. Site URL. Connection still works? (users/me 200)
    2. This month’s ten existing URLs (before title / after title).
    3. This month’s four briefs (keyword, intent, target publish date).
    4. Monday notes: what the audit still says is on fire.
    5. Friday logs, four of them.
    6. Month-end: Search Console on the 14 URLs versus last month. What you would pick next month. What you would stop.

    If you cannot name the 14 URLs at month-end, you did not run a retainer. You blogged.

    What a month does not include

    • Page redesigns, theme work, or plugin installs.
    • Google Ads, GBP posts, or social, unless you hired those separately.
    • Editing attorney bios, service pages, or the homepage without a written ask.
    • A promised ranking. The public SiteBoost copy measures at 60 days and treats traditional SEO as 60 to 90 days on competitive terms. A single month is a shipping month, not a miracle month.

    How this sits next to the other doors

    Connection and Audit is the one-time setup. Pilot is connection + ten existing posts + a 60-day report, once. Retainer is the monthly machine after that. Existing Post Optimization and New Article Publishing are the à la carte versions of the same two work types if you do not want a month.

    If you want the skill files so your own Claude can run the week, that is the WordPress SEO Skill Pack. Pro has the full refresh stack and the content pipeline. Agency adds new-site setup and thin-content expansion, which is what you need if you are the one retaining other people’s sites.

    If you want Will to run the month

    You can keep the Monday / midweek / Friday rhythm on your own staff. Buy Now is Will doing the month: ten existing-post passes, four new articles, shipped through the REST API, with a log of what changed. Same Square button at the top. $997 per month.

    Email the site URL after checkout. If the site is not connected yet, the first month still needs the Application Password and the baseline. Do not send the login password. Application Password only.

    Related: SiteBoost. Also SiteBoost — Pilot Bundle.

  • SiteBoost — Site Connection & Audit

    SiteBoost — Site Connection & Audit

    SiteBoost — Site Connection & Audit

    $297

    Delivered by email after checkout.

    Buy Now →

    Secure checkout via Square — all major cards accepted

    You can copy this method and connect and audit the site yourself. Buy Now is Will doing the one-time setup: Application Password, REST API check, full inventory, and the baseline reports.

    Site Connection and Audit is a service. Square lists it as a one-time setup at $297. It is the front door for every other SiteBoost SKU. The public vertical pages include it inside the pilot. Alone, it is how a site gets on the board without anyone rewriting a post yet.

    Self-hosted WordPress only. REST API on (the default). Squarespace, Wix, and Webflow are not compatible. The /siteboost/ hub is blunt about that.

    How Will connects a site

    wp-connect is the gateway skill. Nothing else in the WordPress stack runs until this works. The 23-site stack article on tygartmedia.com puts a new site at about 20 minutes: Application Password, registry, first audit.

    1. Confirm the site is self-hosted WordPress. Open /wp-json/wp/v2/ in a browser. You should see a JSON index, not a 404. If the REST API is blocked, stop and fix that before anyone shares a password.
    2. In WordPress, go to Users → Profile (or Users → Application Passwords, depending on version). Create an Application Password for a user who can edit posts. Name it something you will recognize later, like “SiteBoost” or “REST audit.” Copy it once. This is not the login password. wp-connect will not use the login password.
    3. Test the connection. GET https://yoursite.com/wp-json/wp/v2/users/me with HTTP Basic auth, username plus the Application Password. A 200 with your user object means you are in. A 401 means the password or user is wrong. A 403 often means a security plugin is blocking REST for that user.
    4. Confirm you can list posts: GET /wp-json/wp/v2/posts?per_page=1&status=publish. If users/me works but posts 403, the user is missing the edit_posts capability.
    5. Write down: site URL, WordPress version if you can see it, hosting (WP Engine, SiteGround, Flywheel, Kinsta, Cloudflare in front, or other), whether Yoast / Rank Math / AIOSEO is present, and who holds the Application Password. Do not put the password in a public doc.

    The public SiteBoost pages name the hosts they have used this pattern on: WP Engine, Flywheel, SiteGround, Cloudflare-proxied sites, GCP Compute Engine, DigitalOcean, Kinsta, bare metal. The requirement is the REST API, not a specific host.

    Do not install a plugin to “help” the connection. SiteBoost’s rule is no plugins added to the client site. Application Passwords are built into WordPress 5.6 and later.

    What the audit checks

    wp-site-audit is the skill that runs at the start of any new site. Fetch all published posts (per_page=100, walk pages). For each post, score the same fields:

    • Word count. Thin is under 500 words.
    • Title tag and slug quality.
    • Excerpt / meta description present, empty, or polluted (raw JSON or leftover code in the excerpt is a real pattern; wp-clean-meta exists to strip it).
    • Categories and tags. Uncategorized is a fail. wp-taxonomy-fix wants 1 to 2 categories and 5 to 10 tags.
    • Featured image present or not.
    • Internal links in (orphans: nothing points here) and internal links out (dead-end posts).
    • Schema present or not, and which types if you can see them (Article, FAQPage, HowTo, BreadcrumbList, Speakable).
    • FAQ section present or not.
    • Outbound source citations present or not.

    Also roll up site-level numbers: total published posts, total pages (count them, do not edit them), taxonomy health (how many categories, how many unused tags, how many posts still Uncategorized).

    The 60-point WordPress SEO Audit Template on tygartmedia.com is the longer human version of this, in six categories: Technical, On-Page, Content, Schema, Local, Analytics. Tools it wants open: Google Search Console, Bing Webmaster Tools, PageSpeed Insights, your SEO plugin, validator.schema.org, an incognito window. Order matters: Technical first, then On-Page, Content, Schema, Local, Analytics. A quick pass is the high-impact rows. A full pass is a few hours the first time. Re-audit quarterly, and after a redesign, a migration, or a plugin purge.

    SiteBoost’s service audit, as sold, is the content-and-baseline cut of that: inventory, schema gaps, FAQ gaps, before numbers. It is not a Core Web Vitals engagement and it is not a local-pack rebuild. If you want the 60-point sheet as a Notion checklist, that is a different SKU (WordPress SEO Audit Template).

    The four reports you should produce

    The public SiteBoost pages name these deliverables. If you are doing this yourself, write the same four:

    1. Content inventory. One row per published post. URL, title, date, word count, category, meta yes/no, FAQ yes/no, schema yes/no, internal links in/out, notes.
    2. Schema gap report. Which posts have no JSON-LD. Which have plugin-bloated or invalid markup. Priority by page type (Article on posts, FAQPage where a FAQ exists or should, HowTo only on real procedures).
    3. FAQ gap report. Which posts have no Q and A block and no FAQPage schema. Those are the AEO queue.
    4. Before baseline. Search Console coverage and the queries / URLs you will watch. A short note on AI visibility for a handful of real questions in your market (do you show up in Perplexity or an AI Overview today?). Write the date. This is what a 60-day report compares to.

    Priority the way wp-site-audit does: Critical (taxonomy / metadata), High (SEO / AEO / thin content), then optimization (links, expansion). The recommended next skills, if you are running Claude, are wp-taxonomy-fix, wp-content-expand, wp-schema-inject, wp-interlink, then the refresh stack.

    What you do not do in this SKU

    • Do not rewrite posts. That is Existing Post Optimization or the Pilot.
    • Do not publish new articles. That is New Article Publishing.
    • Do not edit Pages, bios, or service templates unless the owner asked in writing. Toolbox rule: posts, not pages.
    • Do not leave the Application Password in chat logs or a public Notion page.
    • Do not claim results. You do not have a after yet. You have a before.

    If you want Will to connect and audit

    You can create the Application Password and fill a spreadsheet this afternoon. Buy Now is Will doing the connection and the four reports, then emailing you the baseline and the recommended ten. Same Square button at the top. $297, one time.

    The Pilot Bundle includes this connection plus ten post optimizations and the 60-day report. The Monthly Retainer assumes the site is already connected. If you only want the skill files so your own Claude can connect and audit, that is the WordPress SEO Skill Pack (Starter has wp-connect, wp-post-fetch, and wp-site-audit).

    Related: SiteBoost. Also SiteBoost — Pilot Bundle.