JavaScript SEO With Hermes Agent: A Team Runbook for Evidence, Triage, and Review

JavaScript SEO sounds like a developer-only subject, but the first questions are surprisingly ordinary: What should this page help a visitor do? Which content and links must be available? What did the server return? What appeared after the page ran? Which facts do we still not have?

Hermes Agent is useful here because a JavaScript SEO investigation has several jobs that should not be blended together. One role can record the initial response, another can examine supplied rendering evidence, and a third can turn those reports into a decision card. A human owner still decides whether anyone should change code.

What you will finish with: a one-page case file for one important URL, supported by named evidence, with unknowns clearly marked and one bounded next action. This workflow does not prove Google indexed the page, promise rankings, or authorize an agent to edit production.

Part 1: JavaScript SEO for people who do not write JavaScript

A page is delivered in stages

When you open a traditional HTML page, much of the useful content may already be present in the server response. On a JavaScript-heavy site, that first response can be only the beginning. The browser may download scripts, request additional data, build product cards, insert navigation, and update metadata after the initial HTML arrives.

That does not make the page bad for SEO. Google can process JavaScript, and many modern websites use it successfully. The practical risk is inconsistency. A visitor may eventually see a complete page while an important content element, URL, or page signal is absent from the initial response, delayed behind an interaction, blocked by a failed request, or expressed in a form that is difficult to discover.

Think of the page as four observable layers:

The layers answer different questions. A screenshot shows what one browser displayed, not what the server returned. A 200 response shows successful delivery, not indexation. A rendered DOM can show a stable link, but it does not prove a search engine selected the URL for its index.

Six signals deserve attention first

Beginners do not need to learn an entire framework before they can review a page. Start with six signals that connect directly to discovery and understanding.

1. Status and redirects. A useful page should return the status intended for that page. A missing item should not disguise itself as a successful empty page, and a redirect should end at the correct destination without a confusing chain.
2. Primary content. The page title, main description, product or article information, and other purpose-defining content should be available in the relevant page state. If it appears only after a click or a fragile request, record that dependency.
3. Crawlable links. Important destinations should normally use real links with stable URLs, such as an a element with an href. A clickable card driven only by an event handler may work for a visitor but provide a weaker discovery path.
4. Canonical and robots instructions. The canonical URL, robots meta directive, response status, sitemap entry, and internal links should tell a consistent story. A canonical is a hint, not a command, and it should not be used to conceal URL duplication that the site can prevent.
5. Progressive loading. Lazy-loaded images, infinite scroll, and client-side pagination should not make valuable items dependent on scrolling, clicking, or browser-only state with no stable URL path.
6. Metadata and structured data. Titles, descriptions, canonical tags, and structured data created with JavaScript need to represent the visible page accurately. Structured data can help interpretation, but it does not guarantee a rich result.

Rendering is not the same as indexing

This distinction prevents many bad tickets. Rendering asks whether a system could process the page and obtain the intended content. Indexing asks whether a search engine chose to store and potentially surface a URL. Ranking asks where and when it appeared for a query.

You cannot prove all three from one browser session. If the only evidence is a screenshot, the honest conclusion may be: "The content appeared in this browser state; server response, search-engine rendering, and index selection remain unknown." That sentence is more useful than "Google cannot see the page," because it tells the team exactly what evidence is missing.

Write a page story before you run checks

An agent can produce a long checklist and still miss the business purpose of the page. Write a short page story first:

This page story becomes the shared brief for every Hermes role. It also gives the human owner a simple test: if a finding does not affect the visitor job or the page signals, it may not belong in this case.

Part 2: Turn the investigation into a Hermes Agent team runbook

Hermes Agent publicly documents concepts such as agents, tools, skills, memory, automation, and subagents. The exact tools and permissions still depend on the environment in which it is deployed. This runbook therefore defines outputs and boundaries without assuming that every Hermes installation can browse a URL, run a command, read a repository, or create a ticket.

Give three roles different evidence jobs

Do not open one large task called "fix JavaScript SEO." Separate collection from interpretation and interpretation from action.

These can be three subagents, three ordered tasks, or one agent operating in three explicitly separated passes. The point is not to maximize the number of agents. It is to make every handoff inspectable.

A case file keeps separate evidence sources and uncertainty states visible before a technical decision.

Establish a shared evidence contract

Before the scouts begin, define the sources they may use. If an input is missing, they must mark it unavailable rather than fill the gap with a likely answer.

You are working on one JavaScript SEO case.

Target page: [URL OR SUPPLIED PAGE EVIDENCE]
Visitor job: [ONE SENTENCE]
Required page elements: [LIST]
Allowed evidence: [RESPONSE HTML, RENDERED DOM, HAR, SCREENSHOT, CRAWL EXPORT,
OR REPOSITORY FILES]
Unavailable evidence: [LIST]

Stay read-only. Do not edit files, publish content, submit URLs, change a CMS,
send messages, create tickets, or access accounts that were not explicitly authorized.

For every observation, record the evidence source and use one status:
CONFIRMED, PLAUSIBLE RISK, UNKNOWN, or OWNER DECISION.

Do not claim that a search engine indexed, rendered, or ranked the page without
specific supplied evidence from an authorized source.

Expected output: a short evidence ledger. Quality check: every observation names its source. Recovery path: if a report contains unsourced conclusions, remove those rows and rerun the role using only the approved evidence list.

Run the response scout

The response scout describes what arrived before the page application did its work. Depending on the approved tools, it may inspect a saved response, a crawl export, or a public URL. It should record facts such as:

• final URL after known redirects;
• HTTP status when available;
• title, canonical, robots directive, and language signal in the response;
• presence or absence of the page-defining content;
• ordinary links to required destinations;
• script and data dependencies that are visible in the supplied source;
• conflicts, such as an indexable page canonicalizing to a different URL.

Use a simple output table:

The scout should not recommend server-side rendering merely because content is absent from the response. It has found a condition, not yet the cause or the necessary fix.

Run the render scout

The render scout examines the completed page state that the team can actually supply. It should compare that state with the page story and the response scout's ledger.

Ask it to check:

• whether the primary content appears without an arbitrary user action;
• whether important destinations are represented by stable links;
• whether metadata or canonical signals change after rendering;
• whether lazy-loaded items require scrolling or interaction;
• whether infinite scroll exposes stable, reachable page paths;
• whether error, empty, or unavailable states remain meaningful;
• whether content changes when a required data request fails.

If the team has only a screenshot, the scout cannot inspect link markup or metadata. If it has a rendered DOM but no network capture, it cannot explain why a request failed. The output must state these limits.

Let the triage editor preserve uncertainty

The triage editor combines the two reports. Its job is not to make them sound decisive. Its job is to preserve the difference between an observation, a plausible mechanism, and a missing source.

Use four states consistently:

Priority should follow page impact and evidence strength, not how technical a finding sounds. A missing primary product link on a revenue template may deserve immediate owner review. A speculative framework preference does not.

Turn one finding into an approval card

After triage, choose one confirmed or well-supported finding. Do not send the entire audit into implementation.

Finding ID: JS-01
Page and visitor job: [URL AND ONE SENTENCE]
Evidence: [SPECIFIC RESPONSE, DOM, OR CODE OBSERVATION]
Status: [CONFIRMED / PLAUSIBLE RISK]
Visitor impact: [WHAT MAY BE HARD TO REACH OR UNDERSTAND]
Proposed minimum action: [ONE BOUNDED CHANGE OR INVESTIGATION]
Affected template or system: [KNOWN / UNKNOWN]
Acceptance checks: [LOCAL BEHAVIOR, RESPONSE, RENDERED DOM, FUNCTIONAL LINK]
Rollback: [HOW TO RESTORE THE PRIOR BEHAVIOR]
Decision owner: [NAME OR ROLE]
Implementation status: WAITING FOR APPROVAL

A bounded approval card turns an agent finding into a decision a named owner can review.

Hermes may prepare the card, but it cannot own the business or engineering decision. Memory and automation features do not make a consequential change safe by themselves.

Use a separate implementation task after approval

If the owner approves an action and the Hermes environment has suitable tools, create a new task with only the approved scope. Do not quietly let an audit task become a write task.

Implement only the approved action in case JS-01.

Before changing anything, restate:
1. affected files or system,
2. acceptance checks,
3. actions that remain prohibited,
4. rollback condition.

After the change, show the exact diff or change record and run only the approved tests.
Do not deploy, publish, submit URLs, alter unrelated files, or widen the scope.
If the expected file or mechanism is different from the approved brief, stop and return
the new evidence to the owner.

Expected output: one reviewable change record. Quality check: no unrelated files or actions appear. Recovery path: revert through the approved method and reopen the case if the test fails or the mechanism differs from the brief.

Verify the result in layers

An implementation is not complete merely because an agent says the task succeeded. Verify in the order the page is delivered.

1. Local behavior: the page or component builds, the intended visitor flow works, and accessibility or analytics behavior has not been broken.
2. Response layer: status, redirects, title, canonical, robots instructions, and important source content match the approved target.
3. Rendered layer: required content and links appear in the relevant page state without a hidden interaction dependency.
4. Search evidence: when authorized data becomes available, record what URL Inspection, a crawl, logs, or Search Console actually reports. Do not substitute a local render for this layer.
5. Decision record: save the date, evidence, approved action, test result, owner, and rollback reference.

If one layer fails, do not compensate with a confident summary. Return to the owner with the failed check and the smallest next investigation.

A weekly Hermes routine that stays manageable

Choose one representative, high-value template each week rather than launching a site-wide swarm.

When several pages show the same confirmed mechanism, open a new scoped case for the affected template. Do not declare a site-wide defect from a single URL.

Common failures and how to recover

The agents produce duplicate reports

Their assignments overlap. Give each role a distinct source list and output contract. The response scout should not interpret rendered behavior, and the render scout should not rewrite response facts.

The triage report sounds certain even when data is missing

Require the four status labels and reject any row without an evidence source. Unknown is a useful result because it tells the owner what to request next.

The team argues about SSR before identifying the bug

Return to the page story and confirmed symptom. SSR, prerendering, hydration changes, and client-only rendering are architecture options, not universal answers.

A scheduled task starts creating noise

Reduce the scope to one template or a supplied URL list. A schedule should produce a review queue with dates, failures, and owners. It should not create changes or external messages unless those actions are separately authorized.

The response and rendered reports disagree

That disagreement is often the point of the investigation. Keep both observations instead of choosing the friendlier one. For example, the source can lack product details while the rendered DOM contains them. The next question is then whether the rendering path is reliable for the page and whether the result still exposes stable destinations. Ask for the smallest additional source, such as a known response capture or approved crawl result, rather than treating the mismatch as proof of failure.

A reviewer wants a site-wide conclusion from one page

One URL can reveal a template hypothesis; it cannot establish the scope of that hypothesis. Add a second representative page only after the first case identifies a plausible shared mechanism. If the second page differs, split the cases. This is slower than declaring a universal defect, but it avoids creating an expensive project around a single edge case.

A practical first case, end to end

Suppose a category page receives organic visits, but an SEO colleague notices that its product cards feel hard to audit. The page story says visitors must compare products and open detail pages. The response scout finds a 200 response and a self-referencing canonical in the supplied capture, but no product names in the initial source. The render scout sees names and prices after rendering; it cannot confirm whether the primary card action contains a standard link because the supplied capture is incomplete.

The triage editor should not write "Google cannot index products." The defensible case file is smaller:

The first owner decision may simply be to authorize a repository inspection. If the code owner later confirms that the card uses a click handler without a stable primary destination, the second decision can approve a small, tested component change. That is a successful Hermes workflow even before any ranking data changes: the team moves from an anxious claim to one testable mechanism.

FAQ

Can Hermes agents work in parallel on one page?

Yes, when they have different read-only roles, non-overlapping evidence sources, and a shared case-file format. Do not let several agents edit the same implementation area.

Can Hermes tell whether Google indexed my JavaScript page?

Not from source code or a browser view alone. Supply authorized URL Inspection, crawl, log, or Search Console evidence; otherwise keep the indexation question marked unknown.

Should the response scout always browse the live URL?

No. Use only tools and sources that are available and approved. A saved response or crawl export may be the correct input in a restricted environment.

Does every missing source element require server-side rendering?

No. The actual solution may be a stable link, a corrected status, an available data path, consistent metadata, or another small template change. Diagnose the mechanism first.

What is the best first Hermes task for a beginner?

Use one response scout on one important URL. Require a sourced facts table, then decide whether rendered-page evidence is needed.

Author: Julian Mercer, 14-Year Technical SEO Practitioner at Auspia. Julian writes about crawlability, rendering, site architecture, and technical foundations for AI-readable content.