{"slug": "hermes-agent-for-seo-from-search-console-to-a-blog-post", "title": "Hermes Agent for SEO: from Search Console to a blog post", "summary": "A developer has published a workflow that pairs the Hermes Agent with the Google Search Console API and NotFair's open-source skills to research, write, and audit SEO blog posts, adapting a process used at Straffe Sites. The tutorial covers installation, Google Cloud and Search Console authentication, and short skill commands that let the agent inspect a site and produce checkable drafts rather than generic keyword-driven copy. It also warns that credentials stay local but content sent to a cloud model may reach that provider.", "body_md": "I don't want an AI agent to turn a keyword into another 1,500 words of plausible advice. I want it to inspect the site, find a question worth answering, read the relevant documentation, and give me an article whose claims I can check.\n\nHermes Agent plus Google Search Console gets you part of the way there. Add reusable research and writing skills, your repository, and your own technical notes, and you have a workflow you can inspect instead of a conversation you hope went well.\n\nThis tutorial covers installation, connecting Google Search Console, and using short skill commands to research, write, or audit an article. It adapts the process behind my work at Straffe Sites.\n\nThere are three separate pieces:\n\n| Piece | Job | What it does not provide | \n|---|---|---|\n| [Hermes Agent](https://hermes-agent.nousresearch.com/) | Runs the conversation and tools; reads files; follows skills | A Google account or verified technical expertise | \n| [Google Search Console API](https://developers.google.com/webmaster-tools?hl=en) | Returns search performance for properties you can access | Market-wide keyword volume or an explanation of why rankings changed | \n| [NotFair's open-source skills](https://github.com/nowork-studio/notfair-plugin) | Supply research, audit, planning, and writing procedures | An automatically working replacement for their default hosted connector | \n\nYou ask for a task; Hermes loads the relevant skill, uses the connected tools, and returns an audit or draft for you to review. The skill carries the detailed procedure, so your chat message can stay short.\n\nYour Google credentials stay in the local setup, but content passed to a cloud model may reach that model provider. Use approved accounts, keep credentials out of chat, and only share client data you are allowed to process.\n\nYou will need [Git](https://git-scm.com/), a model provider configured in Hermes, and a Google account. You or your administrator must be able to approve Cloud setup and access to the intended Search Console property. Hermes can help select or create the Cloud project instead of making you configure it in advance. The [Bash](https://www.gnu.org/software/bash/) examples below target Linux, macOS, and [WSL2](https://learn.microsoft.com/en-us/windows/wsl/install) on Windows.\n\nThe [official Hermes installation guide](https://hermes-agent.nousresearch.com/docs/getting-started/installation) provides this CLI installer:\n\n```\ncurl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash\n```\n\nThat executes a downloaded installer with your user's permissions and installs dependencies. If you prefer to review it first, use this route instead:\n\n```\ncurl -fsSL https://hermes-agent.nousresearch.com/install.sh \\\n -o hermes-install.sh\nless hermes-install.sh\n# Run only after reviewing the script and its dependencies.\nbash hermes-install.sh\n```\n\nOpen a new terminal if `hermes` is not yet on your PATH. Then verify the CLI and run setup in the default Hermes profile:\n\n```\nhermes --version\nhermes setup\nhermes skills list\n```\n\nIn setup, choose your model provider and follow its authentication flow. Hermes installation and access to a model are separate requirements.\n\nThe current [platform support page](https://hermes-agent.nousresearch.com/docs/getting-started/platform-support) lists Apple Silicon macOS as supported and Intel macOS as unsupported. Check that page before assuming an older Mac has the same installation path.\n\nFor the Bash examples in this article, use WSL2. In an administrator [PowerShell](https://learn.microsoft.com/en-us/powershell/) window:\n\n```\nwsl --install\n```\n\nRestart if Windows requests it, open the installed Linux distribution, complete its initial user setup, and run the Linux installer above inside that shell. Have Hermes install [Google Cloud CLI](https://docs.cloud.google.com/sdk/docs/install-sdk?hl=en) inside WSL too. Mixing a Windows Hermes process, WSL credentials, and Bash paths makes authentication harder to diagnose.\n\nHermes also has an official native Windows installer. If you prefer PowerShell rather than WSL:\n\n```\niex (irm https://hermes-agent.nousresearch.com/install.ps1)\n```\n\nReview that script first if you would not normally execute a remote installer. Native Windows installation is an alternative, not an extra step after WSL. The remaining shell snippets here are Bash; don't paste them unchanged into PowerShell. The Google setup prompt below asks Hermes to handle installation and paths for your actual environment, including native Windows.\n\nFor an introduction that also covers the desktop app, see [installing Hermes on Voltti](https://voltti.ai/en/insights/install-hermes-desktop-app-or-terminal). Use the official Hermes docs for current commands.\n\nOpen Hermes:\n\n```\nhermes\n```\n\nReplace `[MY_WEBSITE]` with your site and give Hermes this prompt:\n\n```\nInstall gcloud and connect Google Search Console for [MY_WEBSITE]\nusing a service account. Add its email in GSC through browser control,\nor give me the email to add myself. Use read-only access, ask me to\napprove permissions, and test the connection.\n```\n\nHermes can work out the installation commands, Cloud project setup, and authentication details from the official documentation. You handle Google login, consent, and 2FA. If browser control is unavailable, a [Search Console property owner](https://support.google.com/webmasters/answer/7687615?hl=en) can add the email under **Settings → Users and permissions**. Restricted access is enough for performance reports.\n\nKeep command approvals enabled. Prefer [keyless service-account authentication](https://docs.cloud.google.com/iam/docs/service-account-impersonation), keep credentials out of chat and your repository, and don't grant site ownership or broad Cloud administrator roles just to read reports. The connection test must use the service account that was added to GSC, not a different personal account.\n\nYou should finish with the correct property identified and a real API read, not just “setup complete.” If the property has no useful history yet, Hermes should say so. My [Search Console setup guide](https://straffesites.com/en/blog/google-search-console) covers creating and verifying the property itself.\n\nThe [NotFair plugin](https://github.com/nowork-studio/notfair-plugin) provides reusable SEO, research, and writing procedures. Ask Hermes to adapt them to the Google connection you just set up:\n\n```\nAdapt the SEO and Search Console skills from\nhttps://github.com/nowork-studio/notfair-plugin for Hermes.\nUse my gcloud service account instead of the hosted connector, name\nthem notfair-*, and keep Google access read-only. Show the changes\nand test results before installing.\n```\n\nHermes should inspect the source, include the required supporting files, and test the adaptation. You don't need to dictate the folder structure or API implementation. Review what it changed; once you are satisfied, reply:\n\n```\nInstall the reviewed skills.\n```\n\nThe `notfair-*` names below are the local names requested in that prompt, not commands bundled with a fresh Hermes install. Start a new Hermes session after installation. If a command is missing, ask Hermes to check that the skill was installed and exposed under its intended command name.\n\nVoltti's [guide to retrieving marketing data with an AI agent](https://voltti.ai/en/insights/retrieve-marketing-data-with-ai-agent) explains the broader approach. Here, the goal is simply to make the skills use your own working Google connection.\n\nIn the Hermes chat box, start with **`/skill-name`**, then add a URL and what you want done. Type `/` to see available commands. Hermes [loads the installed skill's instructions](https://hermes-agent.nousresearch.com/docs/user-guide/features/skills) for you; you don't need to paste its whole procedure into the conversation.\n\nThese examples go into **Hermes chat, not Bash or PowerShell**. I use Straffe Sites URLs as examples. Replace them with your own site; a public URL does not grant access to its private Search Console data.\n\nEach block below contains the original prompt and the complete final answer from a recorded Hermes run. Intermediate tool activity is omitted. The writing follow-ups continue the same writing conversation; the audit follow-up continues its own audit conversation. Nothing was published.\n\nDEV currently labels these compatible trace imports as Claude Code. The agent that ran them was Hermes. Expand the longer answers and use the scrollbar to read them. DEV does not create section anchors inside these embeds, so an answer's contents links will not jump to its headings.\n\nThe skill supplies the writing process. Your prompt supplies the site and topic. Add an audience or angle when it matters, and let Hermes ask for anything it cannot establish from the context.\n\n/notfair-content-writer [https://straffesites.com](https://straffesites.com)\n\nWrite an English article about Astro versus WordPress for small\n\nbusiness websites.\n\n`/en/blog/astro-vs-wordpress`\nNo dedicated Astro-versus-WordPress article was found in the inspected content inventory or site search. Related coverage already exists:\n\nThis draft keeps its focus on small-business platform selection rather than repeating those implementation guides.\n\nThe verified keyword registry uses final Google Search Console data for `sc-domain:straffesites.com`, covering September 1, 2025, through September 1, 2026. It contains no retained query combining “Astro” and “WordPress.” The proposed primary keyword therefore comes from the requested topic and live search research, not a demonstrated ranking opportunity in that registry.\n\nRelevant existing queries include:\n\n| Existing destination | Recorded query | Clicks | Impressions | \n|---|---|---|---|\n| Headless CMS article | what is a headless cms | 0 | 106 | \n| WordPress maintenance article | wordpress development and maintenance | 0 | 182 | \n| Astro glossary entry | astro framework | 0 | 11 | \n\nThese are query impressions for this property and period, not search volumes. The low-click clusters are indicative, and absent queries do not establish absent demand.\n\nThe first five returned results included:\n\n| Result | Format and emphasis | Editorial response | \n|---|---|---|\n| [Web Aloha](https://webaloha.co/wordpress-vs-astro-for-business/) | Broad comparison with performance, security, and cost claims | Explain caching and avoid treating platform defaults as guaranteed outcomes. | \n| [Reddit discussion](https://www.reddit.com/r/smallbusiness/comments/1t6zldz/astro_code_or_wordpress_for_businesses_websites/) | Community discussion about editing and maintenance ownership | Full discussion unavailable: extraction failed and the browser showed a human-verification page. No anecdote from it is used as evidence. | \n| [Andrew Walpole](https://andrewwalpole.com/blog/consider-astro-over-wordpress/) | Developer perspective on custom brand sites and content architecture | Bring the decision down to small-business editing tasks and handover requirements. | \n| [MFB Solutions](https://www.mfbsolutions.hr/en/blog/wordpress-vs-astro-for-small-business) | Small-business comparison favoring Astro | Correct the implication that static delivery eliminates technical maintenance. | \n| [Dizzi Digital](https://dizzidigital.com/blog/wordpress-vs-astro-business-website/) | Business-purpose comparison and migration discussion | Add a concrete acceptance test for editing, publishing, integrations, and recovery. | \n\nTechnical claims below rely on official documentation rather than competitors' benchmarks. The business scenario is explicitly hypothetical. No speed experiment, client result, or ranking uplift is invented.\n\nAstro vs WordPress is often sold as a speed contest. For a small business, the more expensive mistake may be choosing a site that nobody can update. Choose Astro when a developer will maintain a mostly informational site; choose WordPress when the business needs a familiar publishing dashboard or depends on established plugins. A fast homepage cannot compensate for an outdated service page.\n\nThis comparison is for developers advising small businesses and owners reviewing their recommendations. WordPress here means the open-source CMS in a conventional hosted setup, not a particular WordPress.com plan. Astro means the web framework, with static delivery as the starting point rather than a restriction.\n\n**Contents**\n\nWordPress combines content management with website rendering. Its [block editor](https://wordpress.org/documentation/article/wordpress-block-editor/) gives editors a browser interface for headings, images, paragraphs, and other content. Themes control presentation, while plugins can add features.\n\nAstro is a framework for building the website. It does not supply an equivalent editorial dashboard by itself. Developers can use content files, connect a CMS, or combine sources. Its [default rendering mode](https://docs.astro.build/en/guides/on-demand-rendering/) builds pages ahead of time; routes that need fresh or personalized responses can render on demand with an adapter and suitable runtime.\n\n| Decision | Astro, starting with static pages | Conventional WordPress | \n|---|---|---|\n| Who changes content? | A developer, or editors using a separately configured CMS | Editors using the built-in dashboard | \n| How do visitors receive pages? | Prebuilt HTML for static routes; server rendering where configured | Generated pages or cached responses, depending on the setup | \n| How are features added? | Components, integrations, external services, or custom code | Core features, plugins, external services, or custom code | \n| What needs maintenance? | Dependencies, build and deployment workflow, hosting, accounts, and integrations | Core, themes, plugins, hosting, database, accounts, and integrations | \n| Where does it fit well? | Content-focused sites with deliberate control over the frontend | Sites that benefit from an established editor and plugin workflow | \n\nNeither column describes a maintenance-free product. Compare the complete setup the client will receive, including the editing interface and support arrangement.\n\nBefore approving a platform, ask the person who will maintain the content to change opening hours, replace a photo, and publish a service update in a preview environment. Give them the proposed interface, not a presentation about it.\n\nWatch where they need help. Can they preview the page on a phone? Can they correct a mistake without contacting the developer? Can another employee take over? A technically elegant setup fails this test if routine changes require skills the business does not have.\n\nWordPress supplies the basic editing interface. Its usability still depends on the theme, blocks, permissions, and customizations. A cluttered dashboard with unrestricted layout controls can be harder to use than a small set of well-designed fields.\n\nAn Astro proposal should name the content workflow: developer-managed files, a Git-based editor, or a headless CMS. These are different products for the business, even when visitors receive similar HTML.\n\nStraffe Sites provides a concrete example of the file-based option: its [website without a CMS](https://straffesites.com/en/blog/website-without-cms) uses Astro Content Collections with MDX and JSON content in Git. That demonstrates a workable approach for a technical team. It does not show that a shop owner should learn Git to change holiday hours.\n\nIf editors need a CMS, include it from the start. Agree on preview access, publication timing, image handling, and who responds when an update fails. **Choose the editing workflow before treating Astro as the finished solution.**\n\nAstro's [islands architecture](https://docs.astro.build/en/concepts/islands/) lets developers render UI components as HTML and add client-side JavaScript where interactive components need it. A service page can remain mostly HTML while a calculator receives its own interactive code.\n\nThat can reduce unnecessary browser work. It does not make large photos smaller by itself, remove an embedded booking widget, or stop a developer from adding expensive scripts. Ordinary script tags and third-party embeds still count toward the visitor's workload.\n\nWordPress is not required to rebuild every public page for every visitor. Its [official caching documentation](https://developer.wordpress.org/advanced-administration/performance/cache/) describes serving cached static files. A well-configured page cache changes the comparison substantially; dynamic and personalized pages need separate consideration.\n\nCompare representative pages with the content and features the business will actually use. Include the same images, fonts, analytics, and booking tools. Test a service page and an article, not just a nearly empty homepage.\n\nCheck loading behavior and responsiveness on mobile, keyboard navigation, layout stability, and whether the main action works. Record the test conditions. Lab tests help diagnose problems; available real-user data describes a different population and should not be presented as the same measurement.\n\nGoogle confirms that [Core Web Vitals are used by its ranking systems](https://developers.google.com/search/docs/appearance/page-experience), but good scores do not guarantee top rankings. Neither platform replaces useful content, crawlable links, or accurate service information. This article reports no controlled Astro-versus-WordPress experiment, so it makes no percentage-speedup or ranking-uplift claim.\n\nThe acceptance criterion should be a usable, measured website, not the framework name on the proposal.\n\nWordPress needs a plan for core, theme, and plugin updates, backups, access control, and recovery. Its [security guidance](https://developer.wordpress.org/advanced-administration/security/hardening/) describes security as risk reduction rather than risk elimination. Managed hosting can take responsibility for some tasks; check which ones the agreement actually covers.\n\nTest important functions after changes. For a service business, a working contact form matters more than a dashboard that says every plugin is current. The separate guide to [WordPress maintenance](https://straffesites.com/en/blog/wordpress-maintenance) covers the work in more detail.\n\nA fully static Astro frontend does not need a WordPress application or database to serve its pages. Removing that public application layer removes the need to maintain it. But the repository, dependencies, deployment accounts, domain, and hosting still need care. Forms, APIs, and any connected CMS bring their own responsibilities.\n\nA compromised deployment account can replace a static site. A broken dependency can prevent the next build. If the site uses on-demand rendering, its runtime also needs maintenance. “Nothing to patch” is not a credible handover promise.\n\nCompare ownership costs across the same scope: implementation, hosting, editor support, integrations, updates, recovery, and eventual handover. Do not compare basic static hosting with a WordPress agreement that also includes technical support. Ask who owns each task and what happens when that person is unavailable.\n\nA static page can display a form, but submitting it still needs a receiving service or server endpoint. Choose that destination before launch. Test validation, spam controls, delivery failures, and the confirmation message. A success screen should mean the receiving system accepted the request, not merely that the visitor clicked a button.\n\nFor appointments, distinguish a link to an existing booking service from a custom booking application. A local consultant who already uses a scheduling service may need only a clear link. A business managing staff calendars, deposits, cancellations, and customer accounts has a larger integration problem.\n\nThe same distinction applies to selling online. WordPress can use a commerce plugin such as [WooCommerce](https://woocommerce.com/). Astro can connect to a commerce backend, but the framework itself is not an order-management system. Define who handles products, inventory, payments, refunds, and customer notifications before selecting the frontend.\n\n**List the business operations first.** If an established WordPress plugin already supports them well, replacing it with custom integrations needs a specific benefit. If the business already runs those operations in another service, its website may not need to duplicate them.\n\nAstro and WordPress can work together. In a headless setup, WordPress manages content while Astro renders the public website. The [official Astro integration guide](https://docs.astro.build/en/guides/cms/wordpress/) explains how to retrieve content through the WordPress REST API.\n\nThis is useful when editors need to retain WordPress while developers need a separate frontend. The guide to [how a headless CMS works](https://straffesites.com/en/blog/what-is-a-headless-cms) explains that separation more broadly.\n\nIt also leaves two systems to operate. For a statically built frontend, publishing in WordPress must trigger a successful build and deployment before visitors see the new content. Draft previews, failed builds, redirects, and cache invalidation need deliberate handling. WordPress plugins that expect to render their own frontend do not automatically become Astro components.\n\nKeep private drafts behind appropriate authentication. Treat HTML returned by a CMS according to its trust boundary; rendering a string as HTML is not a substitute for controlling who can supply it.\n\nChoose this combination to preserve a valuable editorial workflow or meet a frontend requirement. It is usually unnecessary complexity if a conventional WordPress site already does the job.\n\nConsider a hypothetical electrical contractor with eight service pages, a project gallery, a contact form, and an existing external scheduling tool. The owner changes service descriptions occasionally and wants someone else to handle technical maintenance. These are example requirements, not a client case or measured experiment.\n\nAstro is a reasonable starting point. The service pages can be prebuilt, the gallery can use optimized images, and the booking action can link to the scheduling tool. The proposal still needs to explain how the owner requests content changes and how urgent corrections are handled.\n\nNow change one requirement: an office manager must publish new projects independently every week. Astro can still work, but a suitable CMS becomes part of the proposal. WordPress deserves a fresh comparison because its editor may meet that requirement with less integration work.\n\nChange another requirement: the business already relies on a WordPress plugin to coordinate bookings and payments. Keeping WordPress may now be the lower-risk choice. Rebuilding a working operational system just to change the frontend is a much larger decision than replacing a brochure site.\n\nUse this exercise in discovery. Change the requirements and see whether the recommendation changes. If the answer is always the developer's favorite framework, the evaluation is not doing its job.\n\nA working WordPress site does not need replacement because Astro exists. First identify the problem: slow pages, an unusable editor, excessive maintenance, or a design that no longer fits the business. Some problems can be fixed without changing platforms.\n\nIf a migration is justified, make an inventory of existing URLs, content, images, metadata, forms, and integrations. Preserve useful URLs where possible. Map changed URLs to relevant destinations instead of sending everything to the homepage, and check internal links after the move.\n\nAvoid these common shortcuts:\n\nBefore signing off, request a demonstration of editing, publishing, and recovery, plus a written handover plan. Choose Astro for a content-focused site with an agreed editing workflow and capable technical ownership. Choose WordPress when its editor or established integrations solve the business's needs more directly. Keep the current site when the migration cannot justify its disruption.\n\nAstro is a strong option for a content-focused site with an agreed editing workflow and technical support. WordPress is often the more direct choice when staff need its built-in editor or established plugins. Choose the complete setup, not the framework in isolation.\n\nYes, if the project includes an appropriate CMS or editing interface. Astro alone does not provide a WordPress-style dashboard. Without an editor, content changes usually go through someone comfortable with the project's files and publishing workflow.\n\nNo. Astro can support a lightweight implementation, but rankings also depend on content relevance and other signals. A migration must preserve useful URLs, internal links, metadata, and indexability. Good performance scores do not guarantee higher rankings.\n\nYes. Astro can retrieve content through the WordPress REST API while WordPress remains the editing system. The project still needs WordPress maintenance, frontend deployment, and a tested approach to previews and publishing.\n\nImage production is outside this demonstration's scope. These are concepts, not existing assets. No placeholder image tags have been inserted. The inline concepts are optional editorial suggestions, not instructions to override the site's image policy.\n\n`astro-vs-wordpress-publishing-workflows.webp`\n`website-editor-acceptance-test.webp`\n`astro-wordpress-page-delivery.webp`\n`website-maintenance-responsibilities.webp`\nThe following draft JSON-LD parses successfully, and all four FAQ questions and answers match the article.\n\nPublication-specific fields are deliberately absent: `image`, `url`, `mainEntityOfPage`, author identity, and publication dates must come from the approved publication and real assets. This is a draft schema, not a claim that a page or image has been published.\n\n`FAQPage` remains a Schema.org type, but Google's [documentation changelog](https://developers.google.com/search/updates#removing-faq-rich-result) states that FAQ rich results are no longer shown. This markup is not a promise of search-result enhancements.\n\n```\n{\n \"@context\": \"https://schema.org\",\n \"@graph\": [\n {\n \"@type\": \"BlogPosting\",\n \"headline\": \"Astro vs WordPress: choose for the person editing\",\n \"description\": \"Astro vs WordPress for small business websites: compare editing, speed, maintenance, and integrations. Use a practical checklist to choose your setup.\",\n \"inLanguage\": \"en-US\",\n \"about\": [\n {\n \"@type\": \"Thing\",\n \"name\": \"Astro\"\n },\n {\n \"@type\": \"Thing\",\n \"name\": \"WordPress\"\n }\n ]\n },\n {\n \"@type\": \"FAQPage\",\n \"inLanguage\": \"en-US\",\n \"mainEntity\": [\n {\n \"@type\": \"Question\",\n \"name\": \"Is Astro better than WordPress for a small business?\",\n \"acceptedAnswer\": {\n \"@type\": \"Answer\",\n \"text\": \"Astro is a strong option for a content-focused site with an agreed editing workflow and technical support. WordPress is often the more direct choice when staff need its built-in editor or established plugins. Choose the complete setup, not the framework in isolation.\"\n }\n },\n {\n \"@type\": \"Question\",\n \"name\": \"Can a nontechnical owner update an Astro website?\",\n \"acceptedAnswer\": {\n \"@type\": \"Answer\",\n \"text\": \"Yes, if the project includes an appropriate CMS or editing interface. Astro alone does not provide a WordPress-style dashboard. Without an editor, content changes usually go through someone comfortable with the project's files and publishing workflow.\"\n }\n },\n {\n \"@type\": \"Question\",\n \"name\": \"Does switching to Astro improve SEO automatically?\",\n \"acceptedAnswer\": {\n \"@type\": \"Answer\",\n \"text\": \"No. Astro can support a lightweight implementation, but rankings also depend on content relevance and other signals. A migration must preserve useful URLs, internal links, metadata, and indexability. Good performance scores do not guarantee higher rankings.\"\n }\n },\n {\n \"@type\": \"Question\",\n \"name\": \"Can Astro use WordPress as its CMS?\",\n \"acceptedAnswer\": {\n \"@type\": \"Answer\",\n \"text\": \"Yes. Astro can retrieve content through the WordPress REST API while WordPress remains the editing system. The project still needs WordPress maintenance, frontend deployment, and a tested approach to previews and publishing.\"\n }\n }\n ]\n }\n ]\n}\n```\n\n| Destination | Anchor used | Purpose | \n|---|---|---|\n| [Website without a CMS](https://straffesites.com/en/blog/website-without-cms) | website without a CMS | Show the site's documented file-based content workflow. | \n| [WordPress maintenance](https://straffesites.com/en/blog/wordpress-maintenance) | WordPress maintenance | Keep detailed maintenance coverage on its existing page. | \n| [What is a headless CMS?](https://straffesites.com/en/blog/what-is-a-headless-cms) | how a headless CMS works | Explain the architecture without expanding this comparison into a separate CMS tutorial. | \n\nThe headless anchor follows a recorded query variation. The maintenance anchor is a natural topic description; no ranking claim is made for that exact phrasing. The newer no-CMS article has no demonstrated cluster in the inspected snapshot.\n\nThese are recommendations only; no links were added.\n\nThis is the complete demonstration draft and writing package. Nothing has been published.\n\nThis is writing output to review, not an approved article. A short follow-up narrows the same draft to developers maintaining the site:\n\nFocus on developers maintaining the site. Show me the outline first.\n\nProposed title\n\nAstro vs WordPress: what developers maintain after launch\n\nAudience\n\nDevelopers responsible for small business websites after handover: content changes, dependency updates, forms, production failures, and eventual migration.\n\nAngle\n\nCompare the work each setup leaves you with. Keep the earlier draft's distinctions around caching, headless WordPress, and editing, but move the focus from the owner's platform choice to the maintainer's responsibilities.\n\nOutline\n\nOpen with the recommendation:\n\n - Static Astro is a strong fit when the site mostly publishes content and its publishing workflow has a clear technical owner.\n\n - Conventional WordPress is often more practical when its editor and established plugins already meet the business's needs.\n\n - Keeping a working site is a valid outcome.\n\nDefine the comparison: static-first Astro versus conventional WordPress with sensible caching and maintenance. Cover on-demand Astro and headless WordPress as separate configurations.\n\nExplain the request path briefly, then connect it to operational work:\n\n - Prebuilt Astro pages versus cached and uncached WordPress responses.\n\n - What removing a public PHP application and database removes from maintenance.\n\n - What remains: dependencies, deployment access, hosting, domains, and integrations.\n\n - How adding SSR changes the responsibilities again.\n\nInclude one compact comparison table organized by maintenance task, not feature scores.\n\nTrace the same change through both setups: update a service description and replace its image.\n\nCover:\n\n - WordPress editing, preview, publication, and cache invalidation.\n\n - Astro file changes or CMS updates, validation, build, and deployment.\n\n - Diagnosing “published in the editor, missing on the website.”\n\n - Who handles urgent corrections when the usual maintainer is unavailable.\n\nTreat the editor as part of the system the developer supports, not a separate convenience.\n\nUse two clearly labeled hypothetical incidents:\n\n - A WordPress plugin update breaks the contact form.\n\n - An Astro dependency update prevents deployment.\n\nExplain:\n\n - Staging, backups, dependency locks, and focused regression checks.\n\n - The difference between a failed build and a broken live deployment.\n\n - Why a code rollback does not necessarily reverse database changes.\n\n - What a recovery procedure must cover beyond “revert the commit.”\n\nTakeaway: define and test recovery for the actual deployment setup.\n\nFollow the business-critical path beyond the frontend:\n\n - Form submission, validation, spam protection, and delivery.\n\n - Embedded scheduling tools versus booking plugins or custom integrations.\n\n - Payments, webhooks, and external service failures where relevant.\n\n - Checks that prove an inquiry reached its destination.\n\nShow when replacing a working plugin creates more maintenance than it removes.\n\nExplain when Astro plus WordPress is justified.\n\nCover the additional work:\n\n - API access and private previews.\n\n - Build triggers, publication delays, and failed updates.\n\n - Rendering blocks and features that previously depended on the theme.\n\n - Maintaining both WordPress and the Astro frontend.\n\nKeep this section short: an operational trade-off, not an integration tutorial.\n\nApply the comparison to a hypothetical small service-business site. Change its requirements to show when the recommendation changes.\n\nEnd with a practical checklist:\n\n - Who edits, and how urgently?\n\n - Which integrations already work?\n\n - Who owns updates and recovery?\n\n - What can another developer take over?\n\n - Could the current site's problems be fixed without migrating?\n\nInclude performance checks here: representative pages, real scripts and embeds, consistent test conditions, and no automatic SEO benefit.\n\nEssential editorial decisions\n\nAn outline lets you check the angle before another writing pass. Give Hermes your own code, notes, or test results when you want first-hand examples; the agent cannot invent your experience.\n\nThe URL is enough to request a page audit. Hermes loads the audit skill, examines the page, and identifies improvements. If its GSC connection has access to that property, it can use the search data too; otherwise it should explain that limitation.\n\n/notfair-seo-page [https://straffesites.com/en](https://straffesites.com/en)\n\n*September 13, 2026 · GSC data: June 13–September 10, 2026 · 90 days, final data*\n\nThe page is indexed, its canonical is correct, and its technical foundation is strong. The main opportunity is clearer, better-qualified commercial messaging—not an indexability repair.\n\nThe audited URL is the English business homepage, not a developer tutorial. It should help prospective clients understand the service, assess the evidence, and contact the team. Tutorial content is supporting material.\n\nThese are editorial assessments, not Google scores, PageSpeed measurements, or ranking predictions. GSC metrics and browser observations are identified separately.\n\n| Dimension | Score | Weight | Weighted | \n|---|---|---|---|\n| Search Intent Alignment | 8.0/10 | 20% | 1.600 | \n| E-E-A-T Signals | 7.5/10 | 20% | 1.500 | \n| Content Quality & Depth | 7.0/10 | 20% | 1.400 | \n| On-Page SEO | 8.5/10 | 15% | 1.275 | \n| Content Structure & UX | 8.0/10 | 15% | 1.200 | \n| Technical SEO | 8.5/10 | 10% | 0.850 | \n| **Overall** | | | **7.825 → 7.8** | \n\n| Dimension | What earns the score | What prevents a higher score | \n|---|---|---|\n| Search intent | Services, portfolio, process, and “Discuss your project” fit a commercial homepage. | The headline emphasizes speed without immediately identifying the small-business audience. Actual GSC queries are sparse and ambiguous. | \n| E-E-A-T | Named contact, 12 linked case studies, linked Google reviews, technical explanations, and an HTTP Archive citation. | Hero performance claims lack an adjacent measurement date, sample definition, and clearly named loading metric. | \n| Content quality | Covers services, examples, process, editing, support, and terminology. | Buyers get limited detail about project scope and delivery dependencies. A substantial part of the content is article-card text rather than buyer guidance. | \n| On-page SEO | Complete metadata, one H1, descriptive links, responsive WebP images, and language annotations. | Minor English-copy issues and an opportunity to make the title more audience-specific. | \n| Structure and UX | Short sections, a clear primary CTA, native FAQ disclosures, and no horizontal overflow in the tested viewports. | The article rail contains 34 cards, which may be more choice than a homepage visitor needs. No conversion or usability study was available. | \n| Technical SEO | Google confirms indexing; server-rendered content, self-canonical, valid JSON-LD parsing, HTTPS, and responsive geometry. | No fresh Lighthouse or URL-level field-performance assessment was run, and this was not a full accessibility or asset audit. | \n\nNo critical indexability blocker was found.\n\nThe biggest improvement would be making the existing performance evidence precise and easy to verify. Strong numbers are useful only when visitors understand what was measured.\n\n🟡 **High**\n\n**Score impact:** Potentially +0.5 in E-E-A-T and +0.5 in Content Quality. These are editorial estimates, not projected ranking gains.\n\n**Current:**\n\n“Our case sites reach a 98/100 median mobile PageSpeed score; the fastest loads in 0.9 seconds.”\n\n**Fix:**\n\nAdd a nearby evidence link and state:\n\nDo not describe LCP as total page-load time if LCP is the underlying metric.\n\nA safe nonnumeric alternative, pending verification of those details:\n\n“Explore our case studies for monthly PageSpeed measurements and Search Console reporting.”\n\n**Why:** The audit verified that the numbers appear on the page; it did not independently reproduce them. Clear provenance strengthens trust and avoids confusing a lab performance score with a visitor-experience guarantee.\n\n**Score impact:** Potentially +0.5 in Content Quality and +0.5 in the Trustworthiness subscore.\n\n**Current heading:**\n\n“We build with Astro — the Core Web Vitals leader in the latest HTTP Archive comparison”\n\n**Current explanation:**\n\n“In July 2026, 69% of measured mobile Astro sites had good Core Web Vitals, compared with 49% for WordPress and 33% for Next.js.”\n\n**Verified finding:** The linked source confirms those July values. However, it now displays August 2026 as the latest period, with Astro at 71%, WordPress at 48%, and Next.js at 35%.\n\nSuggested heading:\n\n“Astro leads this Core Web Vitals comparison”\n\nSuggested explanation:\n\n“In HTTP Archive’s August 2026 mobile comparison, 71% of measured Astro origins had good Core Web Vitals, compared with 48% for WordPress and 35% for Next.js.”\n\nKeep the source link. Explain that an origin groups pages under the same protocol, host, and port; this is not a measurement of every page built with a framework.\n\n**Why:** The existing July figures are not fabricated or disproved, but “latest” is stale. Framework-level comparisons also do not prove that a particular website will pass Core Web Vitals.\n\n🟢 **Medium**\n\n**Score impact:** Potentially +0.5 in Search Intent Alignment and +0.3 in On-Page SEO.\n\n**Current title:**\n\n“Straffe Sites — rock-solid websites that load fast”\n\n**Current H1:**\n\n“A rock-solid site that loads fast”\n\nTest this title rather than assuming the existing one is underperforming:\n\n“Fast websites for small businesses | Straffe Sites”\n\nThe proposed title is 50 characters.\n\nKeep the distinctive H1 if desired, but make the first sentence more explicit:\n\n“We design and build fast websites and online stores for independent professionals and small businesses. Seppe is your main contact, supported by a senior team.”\n\n**Why:** The current meta description already identifies the audience. Bringing that clarity into the title or opening sentence helps qualified visitors recognize the fit.\n\nGSC does not show a proven CTR problem here. This is a relevance hypothesis, not a fix justified by a statistically reliable CTR deficit.\n\n**Score impact:** Potentially +0.5 in Content Quality.\n\n**Current timeline answer:**\n\n“It varies by project. Because you work directly with the developer, communication is quick. After our first conversation, you’ll get a realistic schedule.”\n\nExplain the factors that determine the schedule without inventing a delivery promise:\n\n“The schedule depends on the number of pages, content readiness, custom integrations, and feedback rounds. After the first conversation, we outline the project milestones and what we need from you.”\n\nReview the content-editing answer in the same way: distinguish projects with an editor-friendly CMS from projects where content is maintained through a development workflow.\n\n**Why:** Competitors explain publishing autonomy, migrations, and ongoing delivery in more detail. A few concrete answers would help buyers qualify their project without turning the homepage into a technical manual.\n\n| Signal | Score | Evidence | \n|---|---|---|\n| Experience | 8/10 | Twelve named case-study cards and practical delivery language: “You speak directly with the builder” and “You see the progress as it happens.” The homepage does not itself show detailed before-and-after evidence. | \n| Expertise | 8/10 | Correctly identifies LCP, INP, and CLS in the glossary; explains integrations, maintenance, CMS editing, and a staged delivery process. The hero’s “loads in 0.9 seconds” wording lacks metric precision. | \n| Authoritativeness | 7/10 | Seppe is named, the team page is linked, the server-rendered content states “25+ years of experience,” and relevant case studies and technical articles are linked. Independent reputation and backlinks were not assessed. | \n| Trustworthiness | 7/10 | HTTPS, direct contact details, legal links, a Google-review link, and an HTTP Archive citation. The review rating and case-performance aggregate were not independently remeasured; the “latest” comparison needs updating. | \n\n**YMYL:** This is not primarily a health, financial-advice, legal-advice, or safety page. Health-related client names in the portfolio do not make the homepage a medical-advice resource.\n\nThe page displays “4.9/5 on Google” and “26 reviews.” These are observed page claims, not independently verified review metrics from this audit.\n\n**Target keyword:** “Fast websites for small businesses” is an inferred commercial theme, not an established high-volume query for this URL.\n\n**Actual leading disclosed GSC query:** “fast sites,” with 3 clicks and 17 impressions.\n\n**Intent type:** Commercial service selection and branded navigation.\n\n**Content format match:** **Yes for the commercial theme; uncertain for the ambiguous query “fast sites.”**\n\nTwo searches were used to avoid judging intent from the homepage alone.\n\n| Search | Observed result sample | Interpretation | \n|---|---|---|\n| `fast website development small business Astro agency` | Astro Partner Agencies; Astro’s framework homepage; Lucky Media; Seibert; Opace | A mixture of agency discovery, commercial service pages, and framework information. The homepage’s service format is compatible. | \n| `fast sites` | Louisiana’s FastSites program; a governor’s announcement; WAFB coverage; a Catchpoint performance article; Louisiana Illuminator coverage | Strong ambiguity. This is not a clean web-development purchase query in the returned sample. | \n\nThese are current search-tool results, not a controlled Google rank-tracking study. Geography, device, and personalization were not matched to the historical GSC impressions.\n\n**Conclusion:** Do not optimize the homepage around “fast sites” simply because it produced three clicks. Preserve the homepage’s brand and service role, and let dedicated service pages own narrower purchase queries.\n\n| Feature | Optimized? | Fix | \n|---|---|---|\n| Featured snippet | Not established | No featured-snippet ownership was confirmed. Do not add a long informational section solely to chase one. | \n| People Also Ask | Structurally prepared | Four visible FAQs provide question-and-answer content, but PAA appearances were not reported by the search tool. Improve buyer usefulness rather than promising placement. | \n| Rich results | Markup present; appearance unconfirmed | Organization, WebSite, and FAQPage JSON-LD parse successfully. URL Inspection did not return a rich-result assessment. Markup does not guarantee an enhanced result. | \n| Image results | Basic preparation present | Descriptive alt text and WebP assets exist. Image-search visibility was not measured. | \n\n| Element | Current | Status | Recommendation | \n|---|---|---|---|\n| Title tag | “Straffe Sites — rock-solid websites that load fast” — 50 characters | Good length and clear benefit | Consider the audience-specific variant above. No demonstrated truncation problem. | \n| Meta description | “The Straffe Sites team designs and builds fast websites and online stores for independent professionals and small businesses, with no agency in between.” — 152 characters | Complete and relevant | Retain the audience clarity. A stronger invitation to view work is optional, not essential. | \n| H1 | “A rock-solid site that loads fast” | One H1; clear benefit | Clarify the service and audience in the adjacent introduction. | \n| Canonical | `https://straffesites.com/en` | Correct | Google-selected and user-declared canonicals agree. | \n| Robots metadata | No robots meta tag; no X-Robots-Tag in the checked response | No exclusion detected | An explicit `index,follow` tag is unnecessary. | \n| Open Graph | Title, description, URL, image, type, site name, and `en_US` locale | Complete | The declared 1200×630 image URL returned HTTP 200; visual preview not reviewed. | \n| Twitter Card | `summary_large_image` , title, description, and image | Complete | No urgent change. | \n| Language | HTML `lang=\"en\"` | Appropriate | Continue using US English consistently. | \n| Hreflang | `nl` ,`en` , and`x-default` | Present on the audited page | Reciprocal annotations on the Dutch page were outside this page-only audit. | \n\nSitewide title and description uniqueness was not tested.\n\nThe main content has one H1 and a consistent H2 → H3 hierarchy.\n\n```\nH1: A rock-solid site that loads fast\n H2: We build with Astro — the Core Web Vitals leader in the latest HTTP Archive comparison\n H2: One team, everything for your site\n H3: Web development\n H3: Custom features & integrations\n H3: Website maintenance\n H3: Technical partner\n H3: AI design to website\n H2: Work with real personality\n H3: Verhuurwinkel.nl\n H3: Straffe Sites\n H3: Voltti.ai\n H3: Gitaarlessen Boeckx\n H3: 2140 Boxing Training\n H3: Figur\n H3: New Impact\n H3: Roulez Roulez\n H3: sympl\n H3: ZET\n H3: HWV Facilities\n H3: CLW Antwerpen\n H2: How we work together\n H3: Introduction\n H3: Design\n H3: Build\n H3: Launch & support\n H2: No agency. Just a senior team\n H2: Keep reading\n H3: 34 linked article titles\n H2: Frequently asked questions\n H2: Terms\n H3: CMS\n H3: Responsive web design\n H3: Core Web Vitals\n H3: SEO\n H3: Web hosting\n H3: Website maintenance\n H2: Ready for a rock-solid site?\n```\n\nThe article-card H3s cover CMS integrations, websites without a CMS, agency SEO research, lab versus field performance, website costs, semantic markup, AI writing, Search Console, Storyblok, Astro, hiring developers, maintenance, keyword research, and implementation tutorials.\n\nNavigation and contact-interface headings also exist outside `
`. They are not extra page H1s.\n\n**Assessment:** Logical structure. The main weakness is not heading hierarchy but emphasis: the long framework-comparison heading is more technical than the buyer-oriented service headings.\n\nFound **122 same-origin link elements across the document**, including navigation, repeated destinations, and fragment links. **63 are inside `
`.**\n\nThese are link-element counts, not counts of unique destination pages.\n\n| Anchor text or card heading | Target | Quality | \n|---|---|---|\n| Discuss your project | `/en/contact` | Clear conversion action | \n| See recent work ↓ | `/en#werk` | Useful on-page navigation; target exists | \n| Web development | `/en/website-development` | Relevant; card description adds context | \n| Custom features & integrations | `/en/web-development` | Descriptive and differentiated | \n| Website maintenance | `/en/website-maintenance` | Strong service anchor | \n| AI design to website | `/en/ai-design-to-website` | Specific service intent | \n| Meet the team ↗ | `/en/team` | Useful trust destination | \n| Straffe Sites case card | `/en/case/straffe-sites` | Useful supporting evidence | \n| Core Web Vitals | `/en/glossary/core-web-vitals` | Relevant explanation | \n| View all articles | `/en/blog` | Appropriate directory action | \n\nThe checked contact, service, team, and own-case destinations returned HTTP 200 without a redirect. This was a targeted check, not a full crawl of every link.\n\nThe large link count is not automatically an SEO defect. Much of it comes from the portfolio, article rail, and navigation. A shorter article selection could improve decision-making, but there is no measured evidence here that link count is harming rankings.\n\nTwo outbound HTTPS link elements were found:\n\n| Link | Purpose | Assessment | \n|---|---|---|\n| Google reviews | Reputation evidence | Useful direct source; rating and count not independently confirmed | \n| HTTP Archive comparison | Framework-performance citation | Source inspected successfully in a browser; July values confirmed and newer August values found | \n\nEmail and telephone links are contact actions, not external web citations.\n\nFound **49 `` elements**:\n\n| Image group | Count | Format and attributes | Assessment | \n|---|---|---|---|\n| Case-study images | 12 | WebP, width/height attributes, responsive candidates, lazy loading | Strong implementation | \n| Article-card images | 34 | WebP, 800×450 declared dimensions, lazy loading | Mostly responsive candidates; four have only an 800w candidate | \n| Reused Seppe portraits | 3 | WebP with responsive candidates | Two lazy-loaded; the review avatar uses normal browser loading | \n\nAll images have an `alt` attribute and declared width and height. **48 are lazy-loaded.** One review-avatar image has empty alt text; that can be appropriate because the surrounding review link already has an accessible label.\n\nRepresentative findings:\n\n| Image | Current alt text | Issue or recommendation | \n|---|---|---|\n| Verhuurwinkel case | “Players in transparent bubble suits running at each other during a game of bubble football” | Descriptive and relevant | \n| Straffe Sites case | “…against a light grey background” | Use “gray” for consistent US English | \n| Figur case | “…with grey curly hair…” | Use “gray” | \n| New Impact case | “Camera operator filming a effects technician…” | Correct to “an effects technician” | \n| CMS article illustration | “Abstract Straffe Sites illustration of AI agents connecting to a CMS through MCP” | Understandable; avoid adding keywords merely for SEO | \n\nFour article assets with only an 800w candidate were observed at encoded sizes of 7,288, 17,778, 7,446, and 18,088 bytes. Smaller variants might save bytes, but these are not evidence of a major performance problem.\n\n| Signal | Present? | Evidence | \n|---|---|---|\n| Clear target audience | Partial | The meta description names independent professionals and small businesses; the hero is broader. | \n| Answers the query completely | Mostly | Services, portfolio, process, content editing, maintenance, and contact are covered. Project-planning detail is limited. | \n| Original value added | Yes | Named projects, a direct-contact model, and linked measurement-oriented case studies. | \n| Passes the “Last Click” test | Partial | Enough to begin a conversation; less useful for comparing scope, handover, and ongoing responsibilities. | \n| Appropriate depth | Yes, with a composition caveat | **1,167 words** in the extracted main-content text, including FAQs, glossary cards, and article-card text. | \n| First-hand knowledge | Yes | Practical delivery descriptions and a substantial linked portfolio. | \n| Human-first presentation | Mostly | Direct language and clear CTAs; the long article rail serves several audiences at once. | \n\n**Word-count method:** Text nodes were joined with spaces; scripts, styles, navigation, and aside elements were excluded. The same method was used for the competitor comparisons. Counts describe content volume, not quality or words visible simultaneously on screen.\n\nNo page-level publication or update date was found in `