Standard WordPress Development Checklist

Overview

This checklist was created in response to process gaps identified during the ^[1] web project post-mortem. The absence of a formal development standard led to inconsistent site structure, difficult developer handoffs, and rework. The goal is to ensure any developer — new or returning — can build or inherit a WordPress site with consistent quality and minimal friction.

"A lot of us have our checklist in our brain. We just know what we need to do." — Melissa Cusumano, VCEDC Post-Mortem

The intent is to externalize that institutional knowledge into a shared, living document.

Pre-Development: Asset & Requirement Collection

Before any design or development begins, confirm the following with the client and account manager:

[ ] All copy is finalized and delivered in a single, authoritative source (not spread across emails, Word docs, Excel files, and old websites)
[ ] All photography/imagery is provided by the client, or explicit written approval is given to use stock or AI-generated images
[ ] Client has confirmed whether their area, brand, or subject matter requires location-specific or proprietary photography
[ ] Preferred form tool is confirmed: Gravity Forms, WPForms, native CRM forms, or other
[ ] CRM platform is identified (e.g., Kit, HubSpot, Mailchimp) and integration requirements are documented
[ ] Event plugin (if needed) is selected and its limitations are communicated to the client — especially around registration and CRM integration
[ ] Page structure and content types are agreed upon (see Content Architecture section below)

Lesson from VCEDC: Stock photos and AI-generated images were rejected late in the project because the client wanted imagery specific to the "Northwoods" region. The client's preference for their own photography was not surfaced until well into development. Collecting assets and confirming image policy upfront would have prevented significant rework.

Content Architecture

Correct content type selection prevents structural rework and ensures scalability.

[ ] News / Blog content → built as WordPress Posts, not individual Pages
Posts support categories, tags, archives, and RSS feeds
Pages are for static, non-recurring content only
[ ] Events → use a dedicated event plugin with confirmed CRM integration capability
Free event plugins (e.g., The Events Calendar free tier) may lack registration and CRM integration
If CRM integration is required, use Gravity Forms embedded via shortcode rather than the plugin's native ticket add-on
[ ] Custom post types are documented if used
[ ] Navigation structure is reviewed and approved before build begins

Lesson from VCEDC: The previous developer built news/blog content as individual pages rather than posts, requiring Isahaque to restructure the site after handoff. See ^[2] for context.

Form Strategy

[ ] Identify all forms needed on the site (contact, registration, subscription, etc.)
[ ] Confirm each form's purpose and ensure forms are not reused across different intents (e.g., a general email subscription form must not double as an event registration form)
[ ] For event registration with CRM integration:
Create a unique Gravity Form per event
Create a unique tag in Kit (or equivalent CRM) per event to track registrations separately
Embed the form via shortcode in the event page template's designated content area
Document the shortcode workflow for the client — they will need to manually add the correct shortcode when creating new event posts
[ ] Form naming convention in Gravity Forms should be descriptive: e.g., Event Registration – Business Taxes and Loans 2026
[ ] Test each form end-to-end: submission → CRM tag applied → confirmation received

Lesson from VCEDC: The event plugin's free ticket add-on does not integrate with Kit CRM. Gravity Forms was chosen as the integration layer. Each event requires its own form and CRM tag. Tracy (client) was trained to add the shortcode manually per event post. See ^[3].

Plugin Selection & Limitations

[ ] Before recommending a plugin, confirm whether the free tier supports all required features
[ ] If a plugin limitation affects a client-facing feature (e.g., no registration on free event plugin), communicate this to the client explicitly and in writing before build
[ ] Document all active plugins and their purpose in the project handoff notes
[ ] Confirm the developer is proficient in the chosen page builder (e.g., Elementor, Bricks) before assigning them to a project

Developer Handoff Checklist

When transitioning a site between developers:

[ ] All plugins are documented with name, version, and purpose
[ ] Page builder used is noted
[ ] Custom theme or child theme is identified
[ ] Form IDs and CRM integration mappings are documented
[ ] Any non-standard structural decisions are explained (e.g., "events use Gravity Forms shortcode, not plugin-native registration")
[ ] Staging vs. production environment is clearly labeled
[ ] Client contacts and their technical comfort level are noted (e.g., "Tracy manages event posts; needs simple shortcode instructions")

Pre-Launch QA

[ ] All pages render correctly on mobile and desktop
[ ] All forms submit successfully and trigger correct CRM actions
[ ] Blog/news archive and single post templates are functioning
[ ] Event pages display correctly with registration form embedded
[ ] Navigation links are accurate
[ ] No placeholder content (Lorem Ipsum, stock images pending approval) remains
[ ] Client has reviewed and signed off on final content

^[4]
^[5]
^[3]
^[6]