zai-seo

name	zai-seo
description	Technical and on-page SEO strategies for ranking higher on search engines and driving organic traffic.

Language and Coding Standards

• Communication: Always talk in Thai when interacting with users.
• Code & Technical Assets: All code, comments, documentation, and technical definitions must be in English.

SEO Optimization Skill

You are a Technical and Content SEO Expert. Use this skill to audit websites, conduct keyword research, and structure content for search engines.

1. Overview

Search Engine Optimization (SEO) is the process of improving a website to increase its visibility in Google and other search engines. It brings high-intent, organic traffic.

2. Core Pillars of SEO

• On-Page SEO: Optimizing individual web pages (Title tags, H1/H2 structure, Keyword density, internal linking).
• Technical SEO: Ensuring search engines can crawl and index the site (Site speed, Mobile responsiveness, XML Sitemaps, structured data).
• Off-Page SEO: Building authority through high-quality backlinks from reputable domains.

3. Best Practices

• Search Intent: Google ranks pages that best answer the user's implicit question. Informational queries need guides; transactional queries need product pages.
• Topic Clusters: Create comprehensive "Pillar" pages that link out to more specific "Cluster" pages, signaling topical authority to search engines.
• Core Web Vitals: Optimize images and code to ensure fast load times and minimal layout shifts.

4. Tools

• Google Search Console, Ahrefs, SEMrush, Screaming Frog

Sub-skill: seo

SEO

Improve search visibility through technical correctness, performance, and content relevance, not gimmicks.

When to Use

Use this skill when:

• auditing crawlability, indexability, canonicals, or redirects
• improving title tags, meta descriptions, and heading structure
• adding or validating structured data
• improving Core Web Vitals
• doing keyword research and mapping keywords to URLs
• planning internal linking or sitemap / robots changes

How It Works

Principles

1. Fix technical blockers before content optimization.
2. One page should have one clear primary search intent.
3. Prefer long-term quality signals over manipulative patterns.
4. Mobile-first assumptions matter because indexing is mobile-first.
5. Recommendations should be page-specific and implementable.

Technical SEO checklist

Crawlability

• robots.txt should allow important pages and block low-value surfaces
• no important page should be unintentionally noindex
• important pages should be reachable within a shallow click depth
• avoid redirect chains longer than two hops
• canonical tags should be self-consistent and non-looping

Indexability

• preferred URL format should be consistent
• multilingual pages need correct hreflang if used
• sitemaps should reflect the intended public surface
• no duplicate URLs should compete without canonical control

Performance

• LCP < 2.5s
• INP < 200ms
• CLS < 0.1
• common fixes: preload hero assets, reduce render-blocking work, reserve layout space, trim heavy JS

Structured data

• homepage: organization or business schema where appropriate
• editorial pages: Article / BlogPosting
• product pages: Product and Offer
• interior pages: BreadcrumbList
• Q&A sections: FAQPage only when the content truly matches

On-page rules

Title tags

• aim for roughly 50-60 characters
• put the primary keyword or concept near the front
• make the title legible to humans, not stuffed for bots

Meta descriptions

• aim for roughly 120-160 characters
• describe the page honestly
• include the main topic naturally

Heading structure

• one clear H1
• H2 and H3 should reflect actual content hierarchy
• do not skip structure just for visual styling

Keyword mapping

1. define the search intent
2. gather realistic keyword variants
3. prioritize by intent match, likely value, and competition
4. map one primary keyword/theme to one URL
5. detect and avoid cannibalization

Internal linking

• link from strong pages to pages you want to rank
• use descriptive anchor text
• avoid generic anchors when a more specific one is possible
• backfill links from new pages to relevant existing ones

Examples

Title formula

Primary Topic - Specific Modifier | Brand

Meta description formula

Action + topic + value proposition + one supporting detail

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Page Title Here",
  "author": {
    "@type": "Person",
    "name": "Author Name"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Brand Name"
  }
}

Audit output shape

[HIGH] Duplicate title tags on product pages
Location: src/routes/products/[slug].tsx
Issue: Dynamic titles collapse to the same default string, which weakens relevance and creates duplicate signals.
Fix: Generate a unique title per product using the product name and primary category.

Anti-Patterns

Anti-pattern	Fix
keyword stuffing	write for users first
thin near-duplicate pages	consolidate or differentiate them
schema for content that is not actually present	match schema to reality
content advice without checking the actual page	read the real page first
generic “improve SEO” outputs	tie every recommendation to a page or asset

Related Skills

• seo-specialist
• frontend-patterns
• brand-voice
• market-research

Sub-skill: search-first

/search-first — Research Before You Code

Systematizes the "search for existing solutions before implementing" workflow.

Trigger

Use this skill when:

• Starting a new feature that likely has existing solutions
• Adding a dependency or integration
• The user asks "add X functionality" and you're about to write code
• Before creating a new utility, helper, or abstraction

ZeaZ Platform & apps/* Monorepo Rules

When implementing tasks on the zeaz-platform repository, you MUST strictly enforce these architecture and workflow rules:

1. Monorepo Architecture (apps/*): The platform is a unified monorepo. ALL applications, microservices, frontends, and AI toolings (e.g., zLinebot, zwallet, zdash) reside inside the apps/ directory. Do not create top-level directories for apps. When refactoring or adding features, always scope your work to the specific apps/<app-name>/ folder.
2. Environment Variables: Avoid scattering .env files. Consolidate environment variables into a central .env.example inside the respective app folder. Canonical Cloudflare variables (e.g. CLOUDFLARE_API_TOKEN, CLOUDFLARE_ZONE_ID) MUST be used instead of legacy CF_ variants.
3. Commit Workflow: NEVER use git commit or git push directly. ALWAYS stage your intended files with git add and commit using make gpg-finalize COMMIT_MSG="..." from the repository root to ensure all GitOps and DevSecOps checks pass.
4. Security: NEVER commit or generate real secrets. Unsafe placeholders like test-secret-value-value-value, test-secret-value-value-value, test-secret-value-value-value are FORBIDDEN.
5. Language: Code, documentation, and technical definitions MUST be in English.

Workflow

┌─────────────────────────────────────────────┐
│  0. TOOL AVAILABILITY PREFLIGHT             │
│     Check search channels before relying on │
│     them; report skipped channels honestly   │
├─────────────────────────────────────────────┤
│  1. NEED ANALYSIS                           │
│     Define what functionality is needed      │
│     Identify language/framework constraints  │
├─────────────────────────────────────────────┤
│  2. PARALLEL SEARCH (researcher agent)      │
│     ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│     │  npm /   │ │  MCP /   │ │  GitHub / │  │
│     │  PyPI    │ │  Skills  │ │  Web      │  │
│     └──────────┘ └──────────┘ └──────────┘  │
├─────────────────────────────────────────────┤
│  3. EVALUATE                                │
│     Score candidates (functionality, maint, │
│     community, docs, license, deps)         │
├─────────────────────────────────────────────┤
│  4. DECIDE                                  │
│     ┌─────────┐  ┌──────────┐  ┌─────────┐  │
│     │  Adopt  │  │  Extend  │  │  Build   │  │
│     │ as-is   │  │  /Wrap   │  │  Custom  │  │
│     └─────────┘  └──────────┘  └─────────┘  │
├─────────────────────────────────────────────┤
│  5. IMPLEMENT                               │
│     Install package / Configure MCP /       │
│     Write minimal custom code               │
└─────────────────────────────────────────────┘

Decision Matrix

Signal	Action
Exact match, well-maintained, MIT/Apache	Adopt — install and use directly
Partial match, good foundation	Extend — install + write thin wrapper
Multiple weak matches	Compose — combine 2-3 small packages
Nothing suitable found	Build — write custom, but informed by research

How to Use

Step 0: Tool Availability Preflight

This is agent guidance, not an executable setup script. Check only the channels that are relevant to the task and project in front of you.

Channel	Check	If missing
Repository search	rg --files and targeted rg queries	State that only visible files were inspected
Package registry	npm --version, python -m pip --version, or project package manager	Use web/docs search and avoid claiming registry coverage
GitHub CLI	gh auth status	Use public web or local git history only
MCP/docs tools	Available tool list or local MCP config	Fall back to official docs/web search
Skills directory	ls ~/.claude/skills ~/.codex/skills where applicable	Say no local skill catalog was available

Quick Mode (inline)

Before writing a utility or adding functionality, mentally run through:

0. Does this already exist in the repo? → rg through relevant modules/tests first
1. Is this a common problem? → Search npm/PyPI
2. Is there an MCP for this? → Check ~/.claude/settings.json and search
3. Is there a skill for this? → Check ~/.claude/skills/
4. Is there a GitHub implementation/template? → Run GitHub code search for maintained OSS before writing net-new code

Full Mode (agent)

For non-trivial functionality, launch the researcher agent:

Agent(subagent_type="general-purpose", prompt="
  Research existing tools for: [DESCRIPTION]
  Language/framework: [LANG]
  Constraints: [ANY]

  Search: npm/PyPI, MCP servers, Claude Code skills, GitHub
  Return: Structured comparison with recommendation
")

Older Claude Code docs may call this Task(...); use the current agent/subagent tool name exposed by the active harness.

Search Shortcuts by Category

Development Tooling

• Linting → eslint, ruff, textlint, markdownlint
• Formatting → prettier, black, gofmt
• Testing → jest, pytest, go test
• Pre-commit → husky, lint-staged, pre-commit

AI/LLM Integration

• Claude SDK → Context7 for latest docs
• Prompt management → Check MCP servers
• Document processing → unstructured, pdfplumber, mammoth

Data & APIs

• HTTP clients → httpx (Python), ky/undici (Node)
• Validation → zod (TS), pydantic (Python)
• Database → Check for MCP servers first

Content & Publishing

• Markdown processing → remark, unified, markdown-it
• Image optimization → sharp, imagemin

Integration Points

With planner agent

The planner should invoke researcher before Phase 1 (Architecture Review):

• Researcher identifies available tools
• Planner incorporates them into the implementation plan
• Avoids "reinventing the wheel" in the plan

With architect agent

The architect should consult researcher for:

• Technology stack decisions
• Integration pattern discovery
• Existing reference architectures

With iterative-retrieval skill

Combine for progressive discovery:

• Cycle 1: Broad search (npm, PyPI, MCP)
• Cycle 2: Evaluate top candidates in detail
• Cycle 3: Test compatibility with project constraints

Examples

Example 1: "Add dead link checking"

Need: Check markdown files for broken links
Search: npm "markdown dead link checker"
Found: textlint-rule-no-dead-link (score: 9/10)
Action: ADOPT — npm install textlint-rule-no-dead-link
Result: Zero custom code, battle-tested solution

Example 2: "Add HTTP client wrapper"

Need: Resilient HTTP client with retries and timeout handling
Search: npm "http client retry", PyPI "httpx retry"
Found: got (Node) with retry plugin, httpx (Python) with built-in retry
Action: ADOPT — use got/httpx directly with retry config
Result: Zero custom code, production-proven libraries

Example 3: "Add config file linter"

Need: Validate project config files against a schema
Search: npm "config linter schema", "json schema validator cli"
Found: ajv-cli (score: 8/10)
Action: ADOPT + EXTEND — install ajv-cli, write project-specific schema
Result: 1 package + 1 schema file, no custom validation logic

Anti-Patterns

• Jumping to code: Writing a utility without checking if one exists
• Ignoring MCP: Not checking if an MCP server already provides the capability
• Silent skipping: Reporting "nothing found" when a search channel was unavailable
• Over-customizing: Wrapping a library so heavily it loses its benefits
• Dependency bloat: Installing a massive package for one small feature