Hermes Agent for SEO: from Search Console to a blog post 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. 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. Hermes 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. This 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. There are three separate pieces: | Piece | Job | What it does not provide | |---|---|---| | Hermes Agent https://hermes-agent.nousresearch.com/ | Runs the conversation and tools; reads files; follows skills | A Google account or verified technical expertise | | 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 | | 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 | You 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. Your 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. You 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. The official Hermes installation guide https://hermes-agent.nousresearch.com/docs/getting-started/installation provides this CLI installer: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash That executes a downloaded installer with your user's permissions and installs dependencies. If you prefer to review it first, use this route instead: curl -fsSL https://hermes-agent.nousresearch.com/install.sh \ -o hermes-install.sh less hermes-install.sh Run only after reviewing the script and its dependencies. bash hermes-install.sh Open a new terminal if hermes is not yet on your PATH. Then verify the CLI and run setup in the default Hermes profile: hermes --version hermes setup hermes skills list In setup, choose your model provider and follow its authentication flow. Hermes installation and access to a model are separate requirements. The 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. For the Bash examples in this article, use WSL2. In an administrator PowerShell https://learn.microsoft.com/en-us/powershell/ window: wsl --install Restart 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. Hermes also has an official native Windows installer. If you prefer PowerShell rather than WSL: iex irm https://hermes-agent.nousresearch.com/install.ps1 Review 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. For 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. Open Hermes: hermes Replace MY WEBSITE with your site and give Hermes this prompt: Install gcloud and connect Google Search Console for MY WEBSITE using a service account. Add its email in GSC through browser control, or give me the email to add myself. Use read-only access, ask me to approve permissions, and test the connection. Hermes 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. Keep 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. You 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. The 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: Adapt the SEO and Search Console skills from https://github.com/nowork-studio/notfair-plugin for Hermes. Use my gcloud service account instead of the hosted connector, name them notfair- , and keep Google access read-only. Show the changes and test results before installing. Hermes 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: Install the reviewed skills. The 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. Voltti'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. In 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. These 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. Each 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. DEV 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. The 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. /notfair-content-writer https://straffesites.com https://straffesites.com Write an English article about Astro versus WordPress for small business websites. /en/blog/astro-vs-wordpress No dedicated Astro-versus-WordPress article was found in the inspected content inventory or site search. Related coverage already exists: This draft keeps its focus on small-business platform selection rather than repeating those implementation guides. The 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. Relevant existing queries include: | Existing destination | Recorded query | Clicks | Impressions | |---|---|---|---| | Headless CMS article | what is a headless cms | 0 | 106 | | WordPress maintenance article | wordpress development and maintenance | 0 | 182 | | Astro glossary entry | astro framework | 0 | 11 | These 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. The first five returned results included: | Result | Format and emphasis | Editorial response | |---|---|---| | 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. | | 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. | | 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. | | 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. | | 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. | Technical 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. Astro 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. This 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. Contents WordPress 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. Astro 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. | Decision | Astro, starting with static pages | Conventional WordPress | |---|---|---| | Who changes content? | A developer, or editors using a separately configured CMS | Editors using the built-in dashboard | | How do visitors receive pages? | Prebuilt HTML for static routes; server rendering where configured | Generated pages or cached responses, depending on the setup | | How are features added? | Components, integrations, external services, or custom code | Core features, plugins, external services, or custom code | | What needs maintenance? | Dependencies, build and deployment workflow, hosting, accounts, and integrations | Core, themes, plugins, hosting, database, accounts, and integrations | | Where does it fit well? | Content-focused sites with deliberate control over the frontend | Sites that benefit from an established editor and plugin workflow | Neither column describes a maintenance-free product. Compare the complete setup the client will receive, including the editing interface and support arrangement. Before 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. Watch 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. WordPress 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. An 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. Straffe 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. If 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. Astro'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. That 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. WordPress 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. Compare 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. Check 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. Google 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. The acceptance criterion should be a usable, measured website, not the framework name on the proposal. WordPress 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. Test 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. A 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. A 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. Compare 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. A 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. For 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. The 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. 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. Astro 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. This 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. It 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. Keep 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. Choose 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. Consider 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. Astro 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. Now 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. Change 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. Use 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. A 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. If 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. Avoid these common shortcuts: Before 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. 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. 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. 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. 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. Image 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. astro-vs-wordpress-publishing-workflows.webp website-editor-acceptance-test.webp astro-wordpress-page-delivery.webp website-maintenance-responsibilities.webp The following draft JSON-LD parses successfully, and all four FAQ questions and answers match the article. Publication-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. 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. { "@context": "https://schema.org", "@graph": { "@type": "BlogPosting", "headline": "Astro vs WordPress: choose for the person editing", "description": "Astro vs WordPress for small business websites: compare editing, speed, maintenance, and integrations. Use a practical checklist to choose your setup.", "inLanguage": "en-US", "about": { "@type": "Thing", "name": "Astro" }, { "@type": "Thing", "name": "WordPress" } }, { "@type": "FAQPage", "inLanguage": "en-US", "mainEntity": { "@type": "Question", "name": "Is Astro better than WordPress for a small business?", "acceptedAnswer": { "@type": "Answer", "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." } }, { "@type": "Question", "name": "Can a nontechnical owner update an Astro website?", "acceptedAnswer": { "@type": "Answer", "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." } }, { "@type": "Question", "name": "Does switching to Astro improve SEO automatically?", "acceptedAnswer": { "@type": "Answer", "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." } }, { "@type": "Question", "name": "Can Astro use WordPress as its CMS?", "acceptedAnswer": { "@type": "Answer", "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." } } } } | Destination | Anchor used | Purpose | |---|---|---| | 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. | | WordPress maintenance https://straffesites.com/en/blog/wordpress-maintenance | WordPress maintenance | Keep detailed maintenance coverage on its existing page. | | 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. | The 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. These are recommendations only; no links were added. This is the complete demonstration draft and writing package. Nothing has been published. This is writing output to review, not an approved article. A short follow-up narrows the same draft to developers maintaining the site: Focus on developers maintaining the site. Show me the outline first. Proposed title Astro vs WordPress: what developers maintain after launch Audience Developers responsible for small business websites after handover: content changes, dependency updates, forms, production failures, and eventual migration. Angle Compare 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. Outline Open with the recommendation: - Static Astro is a strong fit when the site mostly publishes content and its publishing workflow has a clear technical owner. - Conventional WordPress is often more practical when its editor and established plugins already meet the business's needs. - Keeping a working site is a valid outcome. Define the comparison: static-first Astro versus conventional WordPress with sensible caching and maintenance. Cover on-demand Astro and headless WordPress as separate configurations. Explain the request path briefly, then connect it to operational work: - Prebuilt Astro pages versus cached and uncached WordPress responses. - What removing a public PHP application and database removes from maintenance. - What remains: dependencies, deployment access, hosting, domains, and integrations. - How adding SSR changes the responsibilities again. Include one compact comparison table organized by maintenance task, not feature scores. Trace the same change through both setups: update a service description and replace its image. Cover: - WordPress editing, preview, publication, and cache invalidation. - Astro file changes or CMS updates, validation, build, and deployment. - Diagnosing “published in the editor, missing on the website.” - Who handles urgent corrections when the usual maintainer is unavailable. Treat the editor as part of the system the developer supports, not a separate convenience. Use two clearly labeled hypothetical incidents: - A WordPress plugin update breaks the contact form. - An Astro dependency update prevents deployment. Explain: - Staging, backups, dependency locks, and focused regression checks. - The difference between a failed build and a broken live deployment. - Why a code rollback does not necessarily reverse database changes. - What a recovery procedure must cover beyond “revert the commit.” Takeaway: define and test recovery for the actual deployment setup. Follow the business-critical path beyond the frontend: - Form submission, validation, spam protection, and delivery. - Embedded scheduling tools versus booking plugins or custom integrations. - Payments, webhooks, and external service failures where relevant. - Checks that prove an inquiry reached its destination. Show when replacing a working plugin creates more maintenance than it removes. Explain when Astro plus WordPress is justified. Cover the additional work: - API access and private previews. - Build triggers, publication delays, and failed updates. - Rendering blocks and features that previously depended on the theme. - Maintaining both WordPress and the Astro frontend. Keep this section short: an operational trade-off, not an integration tutorial. Apply the comparison to a hypothetical small service-business site. Change its requirements to show when the recommendation changes. End with a practical checklist: - Who edits, and how urgently? - Which integrations already work? - Who owns updates and recovery? - What can another developer take over? - Could the current site's problems be fixed without migrating? Include performance checks here: representative pages, real scripts and embeds, consistent test conditions, and no automatic SEO benefit. Essential editorial decisions An 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. The 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. /notfair-seo-page https://straffesites.com/en https://straffesites.com/en September 13, 2026 · GSC data: June 13–September 10, 2026 · 90 days, final data The 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. The 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. These are editorial assessments, not Google scores, PageSpeed measurements, or ranking predictions. GSC metrics and browser observations are identified separately. | Dimension | Score | Weight | Weighted | |---|---|---|---| | Search Intent Alignment | 8.0/10 | 20% | 1.600 | | E-E-A-T Signals | 7.5/10 | 20% | 1.500 | | Content Quality & Depth | 7.0/10 | 20% | 1.400 | | On-Page SEO | 8.5/10 | 15% | 1.275 | | Content Structure & UX | 8.0/10 | 15% | 1.200 | | Technical SEO | 8.5/10 | 10% | 0.850 | | Overall | | | 7.825 → 7.8 | | Dimension | What earns the score | What prevents a higher score | |---|---|---| | 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. | | 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. | | 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. | | 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. | | 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. | | 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. | No critical indexability blocker was found. The 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. 🟡 High Score impact: Potentially +0.5 in E-E-A-T and +0.5 in Content Quality. These are editorial estimates, not projected ranking gains. Current: “Our case sites reach a 98/100 median mobile PageSpeed score; the fastest loads in 0.9 seconds.” Fix: Add a nearby evidence link and state: Do not describe LCP as total page-load time if LCP is the underlying metric. A safe nonnumeric alternative, pending verification of those details: “Explore our case studies for monthly PageSpeed measurements and Search Console reporting.” 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. Score impact: Potentially +0.5 in Content Quality and +0.5 in the Trustworthiness subscore. Current heading: “We build with Astro — the Core Web Vitals leader in the latest HTTP Archive comparison” Current explanation: “In July 2026, 69% of measured mobile Astro sites had good Core Web Vitals, compared with 49% for WordPress and 33% for Next.js.” 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%. Suggested heading: “Astro leads this Core Web Vitals comparison” Suggested explanation: “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.” Keep 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. 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. 🟢 Medium Score impact: Potentially +0.5 in Search Intent Alignment and +0.3 in On-Page SEO. Current title: “Straffe Sites — rock-solid websites that load fast” Current H1: “A rock-solid site that loads fast” Test this title rather than assuming the existing one is underperforming: “Fast websites for small businesses | Straffe Sites” The proposed title is 50 characters. Keep the distinctive H1 if desired, but make the first sentence more explicit: “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.” Why: The current meta description already identifies the audience. Bringing that clarity into the title or opening sentence helps qualified visitors recognize the fit. GSC does not show a proven CTR problem here. This is a relevance hypothesis, not a fix justified by a statistically reliable CTR deficit. Score impact: Potentially +0.5 in Content Quality. Current timeline answer: “It varies by project. Because you work directly with the developer, communication is quick. After our first conversation, you’ll get a realistic schedule.” Explain the factors that determine the schedule without inventing a delivery promise: “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.” Review 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. 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. | Signal | Score | Evidence | |---|---|---| | 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. | | 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. | | 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. | | 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. | 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. The page displays “4.9/5 on Google” and “26 reviews.” These are observed page claims, not independently verified review metrics from this audit. Target keyword: “Fast websites for small businesses” is an inferred commercial theme, not an established high-volume query for this URL. Actual leading disclosed GSC query: “fast sites,” with 3 clicks and 17 impressions. Intent type: Commercial service selection and branded navigation. Content format match: Yes for the commercial theme; uncertain for the ambiguous query “fast sites.” Two searches were used to avoid judging intent from the homepage alone. | Search | Observed result sample | Interpretation | |---|---|---| | 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. | | 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. | These are current search-tool results, not a controlled Google rank-tracking study. Geography, device, and personalization were not matched to the historical GSC impressions. 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. | Feature | Optimized? | Fix | |---|---|---| | Featured snippet | Not established | No featured-snippet ownership was confirmed. Do not add a long informational section solely to chase one. | | 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. | | 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. | | Image results | Basic preparation present | Descriptive alt text and WebP assets exist. Image-search visibility was not measured. | | Element | Current | Status | Recommendation | |---|---|---|---| | 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. | | 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. | | H1 | “A rock-solid site that loads fast” | One H1; clear benefit | Clarify the service and audience in the adjacent introduction. | | Canonical | https://straffesites.com/en | Correct | Google-selected and user-declared canonicals agree. | | Robots metadata | No robots meta tag; no X-Robots-Tag in the checked response | No exclusion detected | An explicit index,follow tag is unnecessary. | | 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. | | Twitter Card | summary large image , title, description, and image | Complete | No urgent change. | | Language | HTML lang="en" | Appropriate | Continue using US English consistently. | | Hreflang | nl , en , and x-default | Present on the audited page | Reciprocal annotations on the Dutch page were outside this page-only audit. | Sitewide title and description uniqueness was not tested. The main content has one H1 and a consistent H2 → H3 hierarchy. H1: A rock-solid site that loads fast H2: We build with Astro — the Core Web Vitals leader in the latest HTTP Archive comparison H2: One team, everything for your site H3: Web development H3: Custom features & integrations H3: Website maintenance H3: Technical partner H3: AI design to website H2: Work with real personality H3: Verhuurwinkel.nl H3: Straffe Sites H3: Voltti.ai H3: Gitaarlessen Boeckx H3: 2140 Boxing Training H3: Figur H3: New Impact H3: Roulez Roulez H3: sympl H3: ZET H3: HWV Facilities H3: CLW Antwerpen H2: How we work together H3: Introduction H3: Design H3: Build H3: Launch & support H2: No agency. Just a senior team H2: Keep reading H3: 34 linked article titles H2: Frequently asked questions H2: Terms H3: CMS H3: Responsive web design H3: Core Web Vitals H3: SEO H3: Web hosting H3: Website maintenance H2: Ready for a rock-solid site? The 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. Navigation and contact-interface headings also exist outside