القائمة
Build SEO-optimized pages at scale using templates and data (directories, comparisons, locations, integrations)
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Design static ad creatives for social media and display advertising campaigns.
Source and evaluate candidates with job analysis, search strategies, specific candidate profiles, and outreach templates.
Draft emails, manage calendar scheduling, prepare meeting agendas, and organize productivity
Create brand identity kits with color palettes, typography, logo concepts, and brand guidelines.
Perform competitive market analysis with feature comparisons, positioning, and strategic recommendations.
Create social media posts, newsletters, and marketing content calibrated to your voice and platform.
| name | programmatic-seo |
| description | Build SEO-optimized pages at scale using templates and data (directories, comparisons, locations, integrations) |
Build SEO-optimized pages at scale using templates and data. Create page generators that target keyword patterns and produce unique, valuable content for each variation.
yoursite.com/templates/resume/ not templates.yoursite.com/resume/When building programmatic SEO for the user's own company, you will not have access to their internal data (customer stories, case studies, testimonials, product metrics, pricing, team bios, etc.). Do not fabricate this information.
Before generating any company-specific content, ask the user for:
If the user hasn't provided this data, default to safe content patterns:
webSearch)webFetch on their domain)[INSERT: customer testimonial] or [INSERT: case study metrics]webSearch)Never generate: fake customer quotes, fabricated ROI numbers, invented case studies, made-up testimonials, or fictional company metrics. These damage trust and can create legal liability.
For generic/research topics (e.g., "[city] cost of living", "[tool A] vs [tool B]", glossary terms), use webSearch to gather real data and cite sources.
| Playbook | URL pattern | Who does it | Scale |
|---|---|---|---|
| Integrations | /apps/[A]/integrations/[B] | Zapier — ~56k pages, 5.8M+ monthly organic visits, ranks for 1.3M keywords. Proprietary data (triggers/templates per app pair) no one else can replicate. | N² combinations |
| Conversions | /currency-converter/[from]-to-[to]-rate | Wise — 8.5M pages across locale subfolders, 60M+ monthly visits. Live exchange-rate data + fee calculators = unique value per page. | N² × locales |
| Locations | /Restaurants-[city], /[cuisine]-Restaurants-[city], /Restaurants-[neighborhood] | Tripadvisor — 700M+ pages, 226M+ monthly visits. UGC reviews keep pages fresh; layered matrix (city × cuisine × neighborhood). | city × category × modifier |
| Data profiles | /[city-slug] | Nomad List — cost-of-living, internet speed, safety scores per city. Pages are pure data tables — minimal prose, high value. | N entities |
| Comparisons | /[A]-vs-[B], /alternatives/[A] | G2, Capterra — "vs" pages + "alternatives" pages, populated by user reviews. | N² / 2 |
| Templates | /templates/[type] | Canva, Notion — each template is a landing page. | N types |
| Glossary | /learn/[term] | Ahrefs, HubSpot — definition pages cluster topical authority. | N terms |
| Personas | /[product]-for-[audience] | "CRM for real estate agents" | N × M |
The test: If your data doesn't meaningfully change between page variations, don't build it. Zapier works because Slack+Asana genuinely differs from Slack+Trello. "Plumber in Austin" vs "Plumber in Dallas" with identical boilerplate = thin content penalty.
Layer playbooks for long-tail: Tripadvisor's "Best Italian Restaurants in Chinatown NYC" = curation × cuisine × neighborhood.
Page structure:
Ensuring uniqueness — critical to avoid thin content penalties:
Hub and spoke model:
Every page must be reachable from the main site. Include XML sitemap and breadcrumbs with structured data.
Rendering strategy decision:
| Page count | Data freshness | Strategy |
|---|---|---|
| <1,000 | Rarely changes | SSG — pre-render everything at build |
| 1,000-100,000 | Changes daily/weekly | ISR — pre-render popular subset, generate rest on-demand + cache |
| 100,000+ or live data | Real-time (prices, rates) | ISR with short revalidate or SSR |
SSG is fastest but build time scales linearly — 50k pages can mean 30+ min builds. ISR is the pSEO sweet spot: instant deploys, pages generate on first request then cache.
Next.js App Router pattern (app/[category]/[slug]/page.tsx):
// Pre-render popular combos at build, generate rest on-demand
export async function generateStaticParams() {
const popular = await db.query('SELECT slug FROM entities ORDER BY search_volume DESC LIMIT 500');
return popular.map(e => ({ slug: e.slug }));
// Return [] to skip build-time generation entirely — all pages ISR-on-demand
}
export const dynamicParams = true; // allow slugs NOT in the list above (generate + cache on first hit)
export const revalidate = 3600; // re-generate page at most once/hour when requested
export async function generateMetadata({ params }) {
const { slug } = await params;
const entity = await getEntity(slug);
return {
title: `${entity.name} — ${entity.category} | Brand`,
description: entity.summary,
alternates: { canonical: `https://site.com/${entity.category}/${slug}` },
};
}
export default async function Page({ params }) {
const { slug } = await params;
const entity = await getEntity(slug);
if (!entity) notFound(); // 404 — don't serve thin pages for bad slugs
// ... render template with entity data
}
Critical ISR rules: generateStaticParams is NOT re-run on revalidation. Must return an array (even []) or the route becomes fully dynamic. Set dynamicParams = false only if you want 404s for anything not pre-generated. fetch() calls inside generateStaticParams are automatically deduplicated across layouts/pages.
For nested routes (/apps/[appA]/integrations/[appB]): child generateStaticParams receives parent params — generate appB list per appA rather than the full N² matrix upfront.
Astro alternative (better for content-heavy, less-interactive pages):
// src/pages/[category]/[slug].astro
export async function getStaticPaths() {
const entities = await loadEntities();
return entities.map(e => ({ params: { category: e.cat, slug: e.slug }, props: { entity: e } }));
}
Astro ships zero JS by default — better Core Web Vitals for pure content pages. No native ISR; use on-demand rendering + CDN cache headers (Cache-Control: s-maxage=3600, stale-while-revalidate).
Sitemaps at scale: Google's limit is 50,000 URLs per sitemap file. Use next-sitemap (Next.js) or custom generation to shard into sitemap-1.xml, sitemap-2.xml... referenced by a sitemap index. For ISR sites, generate sitemaps server-side from the DB, not at build time. Warning: Google will NOT index all pages immediately — indexation at scale takes weeks/months. Prioritize high-volume slugs in the first sitemap.
Track: indexation rate, rankings by page type, traffic, engagement metrics, conversion rate
Watch for: thin content warnings, ranking drops, manual actions, crawl errors
Deliver both a strategy document and the actual implementation: