1. Explore the Codebase for Data Assets
Search the codebase for existing structured data that could power pages:
Database/ORM models:
- Search for schema definitions (Prisma, Drizzle, TypeORM, Mongoose, SQL migrations)
- Identify entities with many records (products, locations, services, users, listings, articles)
- Note which entities have rich attributes (descriptions, categories, images, metadata)
CMS content types:
- Check for headless CMS configs (Contentful, Sanity, Strapi, etc.)
- Identify content types and their field schemas
- Count records per content type
API endpoints:
- Map all API routes and their response shapes
- Identify list endpoints that return collections of entities
- Check for paginated endpoints (signals large datasets)
Static data files:
- Search for JSON, CSV, YAML, MDX files in
data/, content/, src/data/ directories - Count records and inspect field richness
- Check for categorization or taxonomy structures
What to extract per data source:
- Entity name and count (e.g., "2,500 products", "150 cities", "80 services")
- Available fields (especially: name, description, category, attributes, images)
- Relationships between entities (product β category, service β location)
- Data freshness (how often updated, is there a lastModified field)
2. Map Business Entities to Page Types
For each data asset found, evaluate whether it can power a pSEO page type:
| Question | Must answer "yes" |
|----------|-------------------|
| Are there 50+ unique records? | Minimum for pSEO to make sense |
| Does each record have enough data for a full page? | Title, description, 3+ unique attributes |
| Would someone search for this? | Real search intent exists |
| Can each page be meaningfully different? | Not just variable swaps |
| Does this serve the business? | Drives traffic the business can convert |
Common pSEO page patterns by business type:
- E-commerce: Product pages, category pages, brand pages,
[product] vs [product] comparisons, best [category] for [use-case] - SaaS: Feature pages, integration pages,
[tool] alternative, [tool] vs [competitor], use-case pages - Marketplace: Listing pages, location pages,
[service] in [city], category + location combinations - Content/Media: Topic pages, tag pages, author pages,
[topic] guide, glossary/definition pages - Local business: Service + location pages,
[service] in [neighborhood], FAQ pages per service - Directory: Profile pages, category pages, comparison pages,
top [category] in [location]
3. Identify Keyword Patterns and Search Intent
For each proposed page type, validate that search demand exists:
Keyword pattern analysis:
- Identify the base keyword pattern (e.g.,
[service] in [city], best [product] for [use-case]) - Estimate volume per pattern using keyword research tools or inferred demand
- Check for long-tail variations that indicate intent depth
- Verify that existing top results are not exclusively high-authority domains
Intent classification per page type:
- Informational: User wants to learn (guides, definitions, how-tos)
- Commercial investigation: User is comparing options (comparisons, reviews, "best X")
- Transactional: User wants to buy/sign up (product pages, pricing, service pages)
- Navigational: User wants a specific entity (brand pages, location pages)
Each pSEO page type should clearly map to one intent category.
4. Evaluate Data Sufficiency for Content Uniqueness
For each proposed page type, assess whether the data produces genuinely unique pages:
The Content Differentiation Test:
Take 5 random records. For each, write out what the page would contain:
- Title
- H1
- Intro paragraph
- Main content sections
- FAQ questions
If 3+ of these elements are essentially the same text with different proper nouns, the data is insufficient. Either:
- Enrich the data (add more attributes, descriptions, FAQs per record)
- Combine data sources (e.g., product data + user reviews + competitor data)
- Narrow the page type to records with richer data
- Abandon the page type as a pSEO candidate
Minimum data requirements per page:
- 2+ unique text fields beyond title and description (for body content)
- 3+ structured attributes (for data tables, stat highlights)
- Category or taxonomy data (for hub-spoke linking)
- Ideally: 3-5 FAQ pairs per record (for FAQ schema and content depth)
5. Assess URL Structure and Taxonomy
Propose a URL hierarchy for the pSEO pages:
```
/{category}/{slug} # standard
/{location}/{service} # location-based
/{product-type}/{product-slug} # e-commerce
/{topic}/{subtopic} # content-based
```
Check:
- Will all slugs be unique within their URL namespace?
- Does the hierarchy create natural hub-spoke relationships?
- Is the URL structure human-readable and keyword-inclusive?
- How deep is the hierarchy? (Maximum 3 levels recommended)
6. Competitive Landscape Check
Identify whether competitors are already doing pSEO for the same patterns:
- Search for the target keyword patterns and see what ranks
- Check if competitors have programmatic pages (signs: similar URL patterns, templated content, large indexed page counts)
- Assess competitor content quality β can you do meaningfully better?
- Look for gaps they haven't covered (long-tail variations, underserved locations, new categories)
7. Propose a pSEO Strategy
Compile findings into a ranked list of pSEO opportunities.
|