Content Governance

Every page on the site enters a quarterly review cycle. The cycle aligns with calendar quarters: January, April, July, October. Each review must be logged with date and reviewer initials.

Quarterly Review Schedule

Per-Page Review Checklist

• All statistics and percentages are still accurate and sourced
• External links are not broken or redirected
• JSON-LD dateModified matches the actual last edit date
• OG title and description still reflect page content
• No deprecated schema types or properties used
• Page renders correctly on mobile (test at 375px viewport)
• Byline author is still accurate and links to a valid profile
• Review result is logged: page URL, reviewer, date, pass/fail, notes

Schema Freshness Check

During every quarterly review, run these schema-specific checks across all pages:

• Validate all JSON-LD blocks with the Google Rich Results Test (search.google.com/test/rich-results)
• Confirm dateModified on every page matches the last meaningful content edit (not cosmetic CSS changes)
• Check Schema.org changelog for newly deprecated properties or types
• Verify the Organization schema on the homepage still references correct sameAs URLs (LinkedIn, social profiles)
• Ensure BreadcrumbList on every page has correct hierarchy and no orphan pages
• Cross-reference @id references between pages to confirm they resolve correctly in the site-wide graph

When to Update dateModified

Update the dateModified field in JSON-LD when any of these occur:

• Factual content is added, removed, or corrected (statistics, claims, pricing)
• A new section or substantial paragraph is added to the page
• An author byline changes or a new co-author is added
• Structured data types or properties are added or changed
• The page title or meta description is rewritten for SEO reasons

Do not update dateModified for:

• Purely cosmetic CSS adjustments (spacing, color tweaks, font changes)
• Fixing a typo that does not change meaning
• Updating analytics scripts or tracking pixels
• Minification or build-tool changes

When to Add New Schema Types

Evaluate adding a new schema type when:

Schema Implementation Procedure

1. Draft the JSON-LD block in a text editor. Reference Schema.org documentation for required and recommended properties.
2. Validate before deployment using Google Rich Results Test and the Schema.org Validator (validator.schema.org).
3. Ensure @id consistency. New entities must use a predictable URL-fragment pattern (e.g., https://easyhotelrfp.com/page#entity) and cross-reference existing IDs for publisher, isPartOf, author.
4. Deploy and re-validate in production. Run the Rich Results Test again against the live URL within 1 hour of deploy.
5. Request re-indexing in Google Search Console and Bing Webmaster Tools if the page already had a previous schema version.
6. Log the change. Record: page URL, schema type added, date, who deployed, validation result (pass/warnings).

From Draft to Published

Every blog post follows this exact pipeline. No step may be skipped.

1. Draft. Author writes in a local HTML file following the site template. All claims must include inline source references. No placeholder text or TBD sections may remain.
2. Fact-check. A second person (or the author after a 24-hour gap) verifies every statistic, link, and named entity against primary sources per the Editorial Policy.
3. Schema authoring. Add BlogPosting JSON-LD with: headline, datePublished, dateModified, author (linked Person), publisher (linked Organization), image, description, and mainEntityOfPage.
4. OG and meta tags. Add og:title, og:description, og:image (1200x630 minimum), og:url, og:type=article, and twitter:card=summary_large_image. Test the OG image renders correctly at target size.
5. Byline and author link. Insert the visible author byline in the HTML with a link to the author section on the About page. Verify the Person schema @id in the post matches the About page @id.
6. Internal linking. Add at least one link to a related blog post and one link to the product or glossary. Verify no orphan pages are created.
7. Mobile and accessibility check. Preview the page at 375px viewport. Verify all images have alt attributes. Run a quick Lighthouse accessibility audit (target 90+).
8. Sitemap update. Add the new URL to sitemap.xml with the correct lastmod date. Verify the sitemap validates (no duplicate URLs, correct XML structure).
9. Deploy. Push to Cloudflare Pages. Confirm the live URL returns 200 and content matches staging.
10. Post-deploy validation. Within 1 hour of going live:
    • Run Google Rich Results Test against the live URL
    • Submit the URL in Google Search Console for indexing
    • Submit the URL in Bing Webmaster Tools
    • Test OG unfurling on LinkedIn, Twitter/X, and Slack
    • Verify the new page appears in the sitemap at the submitted URL
11. Distribution. Share on LinkedIn (company page + personal profiles), MailerLite subscriber segment if relevant, and any applicable community channels.

Blog Post Update Procedure

When updating an existing blog post (correcting data, adding a section, refreshing statistics):

• Update the visible "Last updated" date in the HTML
• Update dateModified in the BlogPosting JSON-LD to match
• Update lastmod for that URL in sitemap.xml
• Re-run the Rich Results Test post-deploy
• Log the update: URL, what changed, date, who made the change

Generative Engine Optimization (GEO) ensures easyhotelrfp.com content is cited, surfaced, and accurately represented by AI systems including ChatGPT, Perplexity, Gemini, Claude, and Microsoft Copilot. This routine runs on the first week of every month.

4a. Monthly Prompt Testing

Maintain and execute a bank of test prompts across multiple AI platforms. The prompt bank lives in the GEO tracking spreadsheet.

4b. AI Referral Tracking in Analytics

Monitor traffic from AI systems using GA4 segments configured for AI referral sources:

• Check the "AI Referral Traffic" GA4 segment weekly (configured per the Analytics Intelligence Layer)
• Track sessions from known AI referral domains: chat.openai.com, perplexity.ai, gemini.google.com, claude.ai, copilot.microsoft.com, bing.com/chat
• Record monthly totals: sessions, pages per session, bounce rate, top landing pages from AI referrals
• Compare to organic search traffic trends — if AI referral is growing while organic is flat, this validates GEO investment
• Flag any AI referral source that drops to zero (may indicate a bot-blocking issue or a platform change)

4c. Bot Log Review

Review server and CDN logs for AI crawler activity to ensure our content is being indexed by generative AI systems:

• Check Cloudflare analytics for requests from known AI user agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Bingbot (for Copilot), Amazonbot, FacebookBot
• Verify robots.txt still explicitly allows GPTBot, ClaudeBot, PerplexityBot, and other target crawlers
• Confirm llms.txt and /.well-known/llms.json are still accessible (200 response, correct content)
• Check crawl frequency trends: compare this month to last month. A sudden drop in crawl frequency may signal a technical issue
• Verify no Cloudflare firewall rules or rate limits are inadvertently blocking AI crawlers
• If a new major AI crawler appears in the logs that is not in robots.txt, evaluate and add an explicit Allow rule

4d. Monthly GEO Action Items

After completing sections 4a through 4c, produce a summary with these deliverables:

1. Updated prompt testing results added to the GEO tracking sheet
2. AI referral traffic summary (total sessions, trend direction, top pages)
3. Bot crawl frequency summary (crawls per crawler, trend direction)
4. List of action items: content to update, new pages to create, schema to add, robots.txt or llms.txt changes needed
5. Priority ranking of action items (high / medium / low) based on citation impact potential

This summary is reviewed by the content owner before any changes are implemented.