Proposal
Rebuild raleighmasjid.org
A comprehensive plan for redesigning, rebuilding, and relaunching IAR's web presence — grounded in user experience research, technical audits, and community needs assessment.
Why rebuild — the 30-second version
The IAR website has grown by accretion over many years with no information architecture, no audience model, and no content lifecycle. Every committee and program added pages as needed, and Elementor made creation easy but maintenance impossible. The result: 34% of all pages are junk (drafts, duplicates, dead links, outdated events), the homepage takes 5–6 seconds to load on mobile, and the navigation categories don't match how anyone actually thinks.
The deeper problem is that the site treats all visitors the same — and serves most of them poorly as a result. Sisters looking for women's programs must hunt through a generic list. Youth and parents cannot find age-appropriate activities without guessing which nav category to try. Non-Muslims and new Muslims encounter insider terminology with no welcome or guidance. Someone in crisis — a death in the family, a question about their faith — cannot find a clear path to the right person.
This proposal moves IAR to an audience-targeting model: the site recognizes that different people come with fundamentally different needs and surfaces the right content for each segment. The homepage routes three priority audiences — congregants, newcomers, and visitors — through distinct pathways. A "Find Your Community" page lets anyone browse by who they are (youth, sisters, young professionals, seniors, new Muslims) and what they're looking for (education, social, sports, volunteering). Every service page ends with a standardized intake form that acknowledges the request immediately and tracks it to resolution. The site becomes IAR's most professional point of contact with its community.
What this proposal covers
Design
Audience model, design principles, information architecture, homepage design, page-by-page architecture, and search strategy
Infrastructure
Technical stack recommendation, content governance model, and Skyward Blue CRM integration specifications
Execution
Content migration plan, phased timeline with month-level milestones, resource requirements, and risk analysis
Assessment
The case for rebuilding
Three independent audits — a URL and cleanup analysis of all 347 pages, a full site performance and UX review, and user-journey testing across multiple audience segments — converge on the same conclusion.
Current state by the numbers
Root causes — not symptoms
Problem 1
No audience model
The site is built for one user: the existing Muslim community member who already knows IAR. Non-Muslims searching "mosque near me" land on prayer times and insider terminology with no welcome. Sisters looking for programs designed for them must dig through a generic programs list. Youth and parents cannot easily find what's available for their age group. A person ready to take their shahadah cannot figure out how. Someone with a question about Islam has no clear path to a human being. The site doesn't recognize that different people come with fundamentally different needs.
Problem 2
No information architecture
Six top-level nav items with dozens of links. "Services" vs. "Resources" is a distinction that doesn't exist in any user's mental model. "Schedule a Tour" is buried under Services next to "Divorce" and "Cemetery." "What is Islam?" lives under Resources. 17 service tiles on the homepage overwhelm instead of guide. Navigation was organized around IAR's internal org chart, not around what visitors come to do.
Problem 3
No content lifecycle
46 publicly accessible draft/test pages. 13 outdated event pages (Ramadan 2023, Eid copies, 2024 RSVPs). "Facilities" link pointing to a 2018 renovation fundraising post. "Official Statements" page with a single undated entry. FAQ referencing "the Islamic Center of Raleigh" — an outdated name. No page has an assigned owner or review date. Content is created and never maintained.
Problem 4
Elementor as architectural dead end
Elementor + 4 add-on plugins (ElementsKit, Essential Addons, Qi Addons, GutenKit) = 92 CSS files and 57 JavaScript files loaded on every page. 3,300+ Elementor references in page source. Each plugin loads its assets on every page regardless of whether its features are used. This is the root cause of 5–6 second load times. The server itself responds in 144ms — the performance problem is entirely front-end bloat that cannot be fixed within Elementor's architecture.
Problem 5
Elementor divestment — ethical procurement
Elementor is developed by an Israeli company. In alignment with IAR's values and the community's expectations regarding ethical procurement, this proposal recommends complete divestment from Elementor and all associated add-on products. The rebuild provides the natural opportunity: rather than migrating Elementor-built pages to the new site, the custom theme eliminates the dependency entirely. This is both a technical improvement (resolving the performance problem) and an alignment of IAR's digital infrastructure with the community's principles.
Problem 6
65 plugins with overdue updates — confirmed active security vulnerabilities
65 WordPress plugins have pending updates that have not been applied, with some overdue by more than a year. This is not a theoretical risk — it is an active one. On April 21, 2026, IAR's Wordfence security scanner flagged 6 new security vulnerabilities in a single scan, on top of 64 existing unresolved issues. Among the new findings: both Elementor and Elementor Pro have known vulnerabilities rated 6.4/10 (Medium). Two other plugins — including one handling site accessibility and one handling email delivery — have vulnerabilities rated 7.2 and 7.5 out of 10 (High severity). These are not edge cases; these are published, known exploits that attackers actively scan for. The 64 previously identified issues remain unresolved because updating any single plugin risks breaking the Elementor dependency chain. The site cannot be safely patched. Every day it runs in this state, it is exposed. The rebuild eliminates this condition entirely by reducing the plugin count from 65+ to a maximum of 5–6, each actively maintained and independently updatable.
User-journey failures
User-journey testing across multiple site sections revealed consistent patterns: informational content exists but action pathways are missing. People can read about a topic but cannot easily take the next step.
Failed journey
Ready Convert
The shahadah page explains the concept but provides no actionable next step. No "ready to take your shahadah? Contact us here." No form, no phone number, no email. The user must independently discover that the Visit Request Form has a shahadah option buried in a dropdown.
Failed journey
Question Asker
No "Contact Us" or "Ask a Question" section on key landing pages. The outreach email address is only visible within the Visit page content. A person looking to ask a question has no clear path to a human being.
Failed journey
Parent Seeking Youth Programs
Youth programs exist but are not surfaced by audience. A parent must browse the full events list or guess which navigation category contains youth-specific content. No "Youth & Families" landing page. No way to filter "show me what's available for my teenager."
Failed journey
Sister Looking for Women's Programs
Sisters' halaqahs, social gatherings, and support programs exist — but there's no sisters-specific landing page or filtered view. A woman new to IAR cannot easily answer "what does this masjid offer me?" without scrolling through the entire programs list and hoping she finds the right tags.
Additional technical findings
Missing SEO fundamentals
Multiple landing pages have broken or missing title tags, no meta descriptions, and no og:description. Individual content pages lack structured data. This directly impacts discoverability — people searching for "mosque near me," "Islamic school Raleigh," or "learn about Islam" may not find IAR.
Images unoptimized
Images served at natural dimensions larger than display size (e.g., 800px image displayed at 359px). No WebP format usage. Many announcement images are WhatsApp-sourced flyers with text baked into images — inaccessible to screen readers and difficult to read on mobile.
Accessibility gaps
Large number of homepage images missing alt text — including the site logo and all news/announcement images. Heading hierarchy inconsistent. Color contrast unverified against WCAG 2.1 AA. Keyboard navigation for dropdown menus untested.
No caching headers
HTTP response headers lack explicit Cache-Control directives. Repeat visitors re-download all CSS, JavaScript, and images on every visit. Cloudflare CDN is in place but its caching features are not fully configured.
Design
Audience model
Eight distinct audiences use raleighmasjid.org. The current site serves one of them well. The rebuild must serve all eight without creating an overwhelming experience for any.
The audiences — ordered by how poorly the current site serves them
Worst served
1. Non-Muslim visitors
Arrives via Google ("mosque near me," "learn about Islam Raleigh"). Needs to feel immediately welcomed. Currently gets: prayer times, community announcements, Islamic terminology — a visual language for insiders. No path from the homepage to a welcome experience without already knowing where to look.
Worst served
2. New Muslims + those new to IAR
Looking for how to take shahadah, what happens after, how to pray, how to find community. Or: a Muslim who moved to the area and needs to orient. IAR has convert care resources, prayer guides, and new Muslim programming — but none of it has a web presence. The shahadah page is an informational dead-end with no contact pathway. A new Muslim looking for help finds articles but no way to connect with a person.
Underserved
3. Prospective volunteers
"Volunteer & Engagement" is under "Resources" (not intuitive). No description of what volunteering at IAR looks like, the four volunteer tracks, time commitments, or intake pathway. Skyward Blue forms not linked.
Underserved
4. Organizations planning group visits
Schools, churches, interfaith groups, professionals. Funneled to a generic "Schedule a Tour" form under Services. No tailored content for different group types. No information about what a visit includes or how to customize for their audience.
Partially served
5. Community members needing specific services
Marriage, funeral, zakat, fiqh, room reservation, school enrollment. Content mostly exists but is hard to find. "Services" vs. "Resources" confusion. "Facilities" link leads to a 2018 post. Marriage under "Services" but Matrimonial elsewhere.
Partially served
6. Regular attendees checking in
Prayer times, events, announcements. This is who the current site serves best — and it still takes 5–6 seconds to load. 17-tile services grid is overwhelming. WhatsApp image flyers are hard to read on mobile and inaccessible to screen readers.
Partially served
7. Audience-specific community segments
Youth and parents, college and young professionals, sisters, seniors, special needs. Programs exist for each but are not surfaced by audience. No dedicated landing pages. No way to browse "What does IAR offer me?"
Partially served
8. People seeking spiritual guidance from Imams
Need a clear, direct pathway to speak with an Imam. Currently requires navigating to "Fiqh/Religious Inquiry" under Services — not intuitive when the need is pastoral care or personal guidance.
Homepage priority segmentation
Homepage priority 1
Muslim congregants (Group 6)
Highest volume. Served through prayer times widget, quick-access tiles, and event listings — not a section "about" them. They route themselves.
Homepage priority 2
"New here?" (Groups 2 + partial 5)
New Muslims, Muslims new to IAR, people who just moved. Dedicated lane with warm, action-oriented tone. Links to shahadah pathway, prayer app, Guide connection, and orientation.
Homepage priority 3
Non-Muslim visitors (Group 1)
Visually distinct lane. Exploratory tone — curiosity, welcome, low-pressure. Links to visit planning, learning about Islam, group visits, and asking questions.
Groups 3 (volunteers), 4 (group visits), 5 (services), 7 (audience segments), and 8 (Imam guidance) are served through navigation, search, quick-access tiles, and a "Find Your Community" categorized browse page. "Speak with an Imam" gets a quick-access tile on the homepage given the urgency of the need when it arises. Staff access (internal information behind login) is a footer-level link for users with IAR Google Workspace accounts.
Design
Design principles
Six non-negotiable principles. Every design and content decision gets tested against these.
Principle 1
Many doors, one building
The site recognizes that every audience segment — congregants, sisters, youth, parents, new Muslims, non-Muslim visitors, volunteers, people seeking services — comes with different needs. Each gets a clear pathway to the content that matters to them: audience-specific landing pages, filtered program views, tailored welcome experiences. But it's one site, one building. The pathways are welcoming doors into a shared space, not a fragmented collection of microsites.
Principle 2
Task-based navigation, not org-chart navigation
Nobody comes to a website looking for "Resources." They come to do something: schedule a tour, find prayer times, learn about Islam, register their kid for school, plan a funeral. Navigation is organized around what people do, not how IAR organizes its committees. "Services" and "Resources" as categories are eliminated.
Principle 3
Every journey ends with a human
Every major content section ends with a clear call to action that connects the visitor to a person — a form, a phone number, an email, or a walk-in invitation. Information without a next step is a missed opportunity. Forms feed into Skyward Blue with source tagging so no inquiry gets lost.
Principle 4
Search is a first-class navigation tool
For a site with IAR's breadth of content, search is how 30–40% of users navigate. The search experience must understand user intent, handle English and transliterated Arabic synonyms ("Jummah" / "Jumuah" / "Friday prayer"), and surface results with snippets and section context. Not a fallback — a primary navigation method.
Principle 5
Content has owners and expiration dates
Every page has an assigned content owner and a review cycle. Event pages auto-archive. Seasonal content uses permanent URLs updated annually. Drafts are never publicly accessible. This is primarily a governance requirement — but the technical platform must enforce it.
Principle 6
Performance is a feature
Under 2 seconds to interactive on a mobile connection. The majority of IAR's community accesses the site on phones. A 5–6 second load time loses people — especially first-time visitors with zero loyalty to wait. This requirement rules out Elementor and most heavy page builders.
Design
Information architecture
Six top-level navigation items plus two utility items (Donate, Search). Down from six items that each tried to do too much.
Top-level navigation
Key structural changes
| Current | New | Rationale |
|---|---|---|
| "Services" vs. "Resources" | "Visit Us" + "Our Services" + items redistributed | Eliminates ambiguity. Visitor/outreach content gets its own front door. Membership, volunteering, Waqf move to "Get Involved" under About IAR. |
| "Schedule a Tour" under Services | "Visit Us" is top-level nav | A tour is a newcomer's entry point. Burying it under "Services" next to "Divorce" is architecturally hostile to the audience IAR most needs to welcome. |
| "What is Islam?" under Resources | "Learn About Islam" under Visit Us | If you're asking "What is Islam?" you are a visitor. That content belongs in the visitor pathway. |
| No shahadah action pathway | "Ready to Take Shahadah?" under Visit Us | Addresses the critical gap from user-journey testing. Converts an informational dead-end to an actionable pathway with staff contact. |
| No new Muslim landing page | "New Muslim Resources" under Visit Us | Web presence for new Muslim support: prayer guides, educational resources, community connection, and relevant programs — all in one place. |
| Volunteering, Membership scattered | "Get Involved" under About IAR | Single entry point for deepening engagement: volunteer tracks with Skyward Blue intake, membership, Waqf/endowment. |
| Annual event pages (/ramadan-23, /eid-3) | Permanent URLs: /ramadan, /eid | One URL per recurring event, updated annually. Eliminates accumulation of outdated pages and preserves SEO authority. |
Design
Homepage design
The homepage is the routing mechanism. Its job is to get each person to the right place in one move — not to display everything the site contains.
Content zones — top to bottom
Zone 1 — Header
Navigation + Prayer Times + Search + Donate
Compact, fast-loading header. Prayer times display next prayer name + adhan time + iqamah time as a persistent badge. Search icon opens full-width overlay with suggested queries and synonym handling. Donate always visible. On mobile: hamburger menu, prayer time remains visible.
Zone 2 — Hero
Welcome statement with two clear pathways
Single high-quality photograph. Not a rotating carousel. Two call-to-action cards: "I'm part of the IAR community" (scrolls to quick access) and "I'm visiting or learning about Islam" (links to Visit Us). Two seconds to scan. Costs nothing for the person who knows where they're going.
Zone 3 — Prayer times strip
Full day's schedule — adhan and iqamah for each prayer
Active/next prayer highlighted. Each prayer shows adhan time and iqamah time. Link to full schedule with Jummah sessions. Dark background to visually anchor this as a persistent utility element.
Zone 4 — Quick access tiles
8 task tiles for the regular community
Events & Programs, Marriage & Nikah, Speak with an Imam, Schools, Hajj & Umrah, Room Reservation, Social Services, Contact Us. Each tile is a verb phrase, not a category noun. "Speak with an Imam" addresses Group 8 at the tile level.
Zone 5 — "New Here?" lane
For new Muslims and Muslims new to IAR
Brand gold accent. Action-oriented links: "I just took my shahadah — what now?", "I'm new to the area," "Learn to pray," "Connect with someone." Distinct visual identity from the non-Muslim lane.
Zone 6 — "Curious about Islam?" lane
For non-Muslim visitors
Brand green accent. Exploratory, low-pressure tone: "Plan a visit," "Learn about Islam," "Bring your school or organization," "Ask a question." Visually distinct from the "New Here?" lane to signal different needs and emotional states.
Zone 7 — Find Your Community
Categorized browse cards for audience segments
Cards for Youth & Families, College & YP, Sisters, Seniors, Special Needs, and "All Programs." Each links to a categorized browse page — not a filter form. Users browse by who they are and what they're looking for. Overlapping interests supported (a young woman browses both YP and Sisters).
Zone 8 — What's Happening
Next 4–5 upcoming events, text-based
Not a carousel. Not WhatsApp image flyers. Clean list: date, title, description, category tag, registration link. Text content — accessible, fast, mobile-friendly. "View full calendar" link.
Zone 9 — Get Involved
Volunteer, Donate, Membership
Three visually distinct cards. Volunteer links to Get Involved page with track descriptions. Donate links to giving page. Membership links to membership info and signup.
Zone 10 — Footer
Contact, locations, social, verse, feedback, staff portal
Quranic verse section (keep the existing "Become a Part of Something More" element — one of the best design elements on the current site). Both campus addresses, phone, email, office hours. Social media icons (once — not duplicated). "Share Feedback" link — persistent, always-accessible community feedback channel. Staff portal link (deprioritized, for Google Workspace account holders). Privacy policy.
Design
Page architecture
Each top-level section's purpose, content structure, and key design decisions.
Visit Us
The newcomer and non-Muslim front door
Two-column layout splitting "New Here?" and "Explore Islam" pathways side by side. Left column is exploratory — plan a visit, learn about Islam, group visits, ask a question. Right column is action-oriented — shahadah pathway, new Muslim resources, prayer guide, community connection. Bottom: contact form feeding to Skyward Blue. The Learn About Islam subsection houses the existing Islamic education knowledge base content with corrected SEO (proper title tags, meta descriptions, structured data).
Programs & Events
Dual-filter categorized browsing
Two filter dimensions at the top: "Browse by Community" (Youth, College/YP, Sisters, Seniors, New Muslims, Special Needs) and "Browse by Type" (Educational, Religious, Social, Sports, Volunteer, Community). Both are multi-select tag rows, not dropdown forms. Below: chronological event listing with date, title, description, and category tags. Featured section: Ramadan Hub, Eid Celebrations, and Weekly Programs as permanent-URL destinations. Time-based filtering (this week, this month) added in production.
Our Services
Three organized groups
Religious Services (Marriage, Divorce, Funeral, Hajj, Speak with an Imam, Matrimonial). Community Services (Social Services, Counseling, Special Needs). Facilities & Operations (Room Reservation, Kitchen, Letter Request). Jummah schedule displayed here with session times and languages. Each service card links to a dedicated page with full information, forms, and contact details.
Schools
Three school cards with external links
Al-Iman School (Pre-K – 8th, 2 campuses), An-Noor Quran Academy (Grades 3–8, Quran memorization), Al-Furqan Weekend School (K–12, weekends). Each card has a brief description, grade range badges, and links to the school's external website. No duplicated content — schools maintain their own sites.
About IAR
Sidebar-navigated scrollable page with seven sections
Our Story, Our Locations (both campuses with maps and contact), Leadership (Imams, Shura, Board, Administration), Get Involved (volunteer tracks, donate, membership, Waqf), Careers (with posting dates), Contact Us (general form + outreach email), Publications & Reports (constitution, bylaws, annual reports, official statements). Sticky sidebar navigation allows jumping between sections.
Design
Search strategy
Search is a first-class navigation tool — not a fallback for when the nav fails.
Requirements
Synonym & transliteration handling
"Jummah," "Jumuah," "Jumma," "Friday prayer," and "jumu'ah" must all resolve to the same content. Similarly: "masjid" / "mosque," "nikah" / "marriage," "janazah" / "funeral," "zakat" / "charity." Requires a custom synonym dictionary mapping Islamic terminology, transliterations, and English equivalents.
Intent-aware result ranking
"Prayer" surfaces prayer times first (highest intent), then prayer programs, then educational content about salah. "Visit" surfaces tour scheduling first. Requires result boosting and weighting, not just keyword matching.
Scoped suggestions with snippets
As the user types, dropdown suggests matching pages with title, snippet, and section label ("Visit Us," "Services," etc.). The knowledge base search in the Islamic education section does this well — extend site-wide.
Mobile-first design
Full-width overlay, large touch targets, keyboard-friendly, results visible without scrolling past input. Suggested queries visible on open (e.g., "Prayer Times," "Jummah," "Marriage," "Visit the Mosque").
Implementation options
| Option | Pros | Cons | Fit |
|---|---|---|---|
| Algolia | Fast, synonym support, custom ranking, excellent API, free tier covers IAR's volume | External dependency, requires indexing pipeline, learning curve | Best fit if team can handle setup |
| SearchWP | Stays in WordPress ecosystem, custom weighting, synonym dictionary, easy admin | Not as fast as Algolia, limited suggestions without add-ons | Good fit if staying on WordPress |
| Typesense | Open source, self-hostable, fast, synonym support, typo tolerance | Requires server setup and maintenance | Good fit if team has backend skills |
Design
AI assistant
A persistent, AI-powered chatbot on every page that answers community questions instantly — using IAR's own content as its knowledge base.
Why this matters
Traditional search returns a list of pages and asks the user to find the answer themselves. The AI assistant gives them the answer directly — synthesized from IAR's own content, formatted for readability, and linked to the source page for deeper detail. For a site serving audiences with widely different levels of familiarity (a longtime community member vs. someone who's never been to a mosque), this is the difference between "here are 8 results for 'prayer'" and "Here are today's prayer times — Asr is at 4:45 PM, iqamah at 5:15 PM."
The assistant also handles the natural language questions that structured navigation can't: "Can I just show up for Friday prayer or do I need to register?" or "My grandmother passed away — what do I do?" or "I took my shahadah last week and don't know how to pray." These are real questions from real people, and the assistant routes them to the right answer (or the right human) immediately.
How it works
Layer 1 — Knowledge base
Retrieval-augmented generation (RAG) over IAR's site content
Every page on raleighmasjid.org is indexed and embedded into a vector database. When a user asks a question, the system retrieves the most relevant content from IAR's own pages, then generates a natural-language answer grounded in that content. The assistant never fabricates information — every answer is sourced from IAR's published content, and the source page is linked in every response.
Layer 2 — Structured data
Real-time prayer times, events, and service information
For high-frequency queries (prayer times, Jummah schedule, upcoming events), the assistant pulls from structured data sources — the prayer times API, the events calendar, and service page metadata — not just page text. This ensures answers are current, precise, and formatted (times in a table, not buried in a paragraph).
Layer 3 — Handoff to humans
When the assistant can't answer, it connects to a person
If the question requires personal guidance, a judgment call, or information not on the website, the assistant doesn't guess. It says: "This is something I'd want to connect you with a person for. Would you like to submit this as a question to our outreach team?" and offers the intake form — pre-populated with the user's question. This bridges the chatbot to the centralized intake system so nothing gets lost.
Layer 4 — Source transparency
Every answer links to the page it came from
The assistant is not a replacement for the website — it's an accelerant. Every response includes a "Source: [page name]" link so the user can visit the full page for more detail. This builds trust (the user can verify the answer), drives engagement with the actual content, and prevents the chatbot from becoming a black box.
Common query patterns
| User asks | Assistant responds with | Source |
|---|---|---|
| "What time is Maghrib today?" | Today's full prayer schedule with adhan and iqamah times, Maghrib highlighted | Prayer Times |
| "How do I schedule a nikah?" | Step-by-step process, requirements, timeline, and link to the Marriage Services request form | Services → Marriage |
| "I want to visit the mosque" | What to expect, dress guidance, parking, and link to the Visit Request form | Visit Us → Plan Your Visit |
| "My mother passed away" | Immediate guidance on janazah process at IAR, phone number for urgent contact, and link to Funeral & Cemetery page | Services → Funeral |
| "I just became Muslim, now what?" | Welcome message, immediate next steps, link to New Muslim Resources, and offer to connect with a Guide | Visit Us → New Muslim Resources |
| "What youth programs do you have?" | List of current youth programs with schedules, and link to filtered Programs & Events page | Programs → Youth |
| "What does Islam say about X?" | Summary from knowledge base articles if available; if not, offer to route question to Imam's office | Visit Us → Learn About Islam |
| "I want to volunteer" | Description of volunteer tracks, time commitments, and link to the volunteer intake form | About → Get Involved |
Relationship to other site features
Chatbot vs. search overlay
Both remain available. They serve different modes: search is for browsing and scanning (the user has a general topic), the chatbot is for asking and receiving (the user has a specific question). Many users will never use search — they'll go straight to the chatbot. Others prefer search. Neither is deprecated.
Chatbot → centralized intake
When the chatbot can't answer or the user needs to take action (schedule a visit, submit a request, ask the Imam), it hands off to the relevant intake form — pre-populated with context. The chatbot is the front end; the intake system is the back end. They're connected, not separate.
Technical implementation
AI backend
An LLM API (e.g., Claude, GPT) with retrieval-augmented generation. The site's content is indexed into a vector store (e.g., Pinecone, Weaviate, or a simpler solution like Supabase pgvector). User queries retrieve relevant content chunks, which are passed to the LLM with a system prompt constraining answers to IAR's published information.
Frontend widget
Lightweight JavaScript widget embedded on every page. Floating action button in bottom right, expandable chat panel. Suggested queries on open. Streaming responses for perceived speed. Mobile-optimized (full-width panel on small screens). Can be built as a standalone component or via a chatbot platform (e.g., Voiceflow, Botpress, or custom).
Content indexing
Automated pipeline that re-indexes the site content whenever pages are published or updated. Structured data (prayer times, events) pulled from APIs or database queries at request time, not from indexed page text. Index refreshes should be near-real-time for events and prayer times.
Cost
LLM API costs are usage-based. For a community site with moderate traffic, expect $50–200/month depending on query volume. Vector database hosting is minimal ($0–20/month at IAR's scale). A managed chatbot platform adds $50–300/month but reduces development effort.
Phasing
Infrastructure
Technical stack
The current stack — WordPress + Elementor + 4 add-ons + 14+ plugins — is the root cause of performance problems.
Recommendation
WordPress itself isn't the problem — Elementor-as-architecture is. A properly built custom theme with locked templates that prevent layout drift, the block editor for content, and disciplined plugin management gets 80% of the performance benefit of a headless build at a fraction of the ongoing maintenance complexity. If IAR has access to a developer comfortable with Next.js or Astro who is committed long-term, a headless CMS approach (WordPress for content management, static frontend for delivery) is technically superior. But a sophisticated stack nobody can maintain is worse than a simpler stack used correctly.
Non-negotiable technical requirements
Sub-2s load time
Homepage fully interactive in under 2 seconds on 4G mobile. This is the ceiling, not a target.
WebP images enforced
All images served in WebP, auto-resized to display dimensions. No 800px images displayed at 359px.
WCAG 2.1 AA
Alt text on every image. Proper heading hierarchy. Keyboard navigation. Color contrast verified. Screen reader tested.
Mobile-first responsive
Designed for phones first, scaled up for desktop. Mobile is the primary experience.
SEO foundations
Every page: proper title, meta description, Open Graph tags, structured data (Organization, FAQPage, Event).
CRM integration
All forms feed into Skyward Blue with source tagging. Stable, permanent form URLs.
Plugin budget (maximum 5–6)
| Function | Recommended | Replaces |
|---|---|---|
| SEO | Yoast SEO or Rank Math | Manual meta tags |
| Forms | Gravity Forms or WPForms | Multiple form plugins |
| Caching | WP Rocket or W3 Total Cache | None (currently missing) |
| Events calendar | The Events Calendar or custom post type | Existing events system |
| Search | SearchWP or Algolia plugin | WordPress default search |
| Image optimization | ShortPixel or Imagify | Manual (currently not done) |
Staging environment
The new site should be built on a staging environment — a complete parallel copy of the site at a staging URL. The live site remains untouched during the build. When ready, staging pushes to production in one operation. This requires a managed WordPress host that supports native staging (WP Engine, Kinsta, SiteGround GrowBig+, Flywheel). If IAR's current host does not support staging, migrating to a host that does should be the first step of the rebuild.
Infrastructure
Content governance
This section is more important than the technical stack. The current site's problems are 30% technical and 70% organizational.
Every page has an owner
Literally every page in the CMS is assigned to a person (not a committee). That person is responsible for accuracy. A page with no owner doesn't go live. When that person leaves their role, ownership transfers explicitly. The CMS displays owner and last-reviewed date in the admin interface.
Quarterly content review cycle
High-traffic pages (homepage, prayer times, services): monthly. Informational pages (About, knowledge base): quarterly. Event pages: automatically flagged 7 days after event date. CMS sends automated reminders to page owners. A page that misses two review cycles gets flagged for the web administrator.
No drafts are ever publicly accessible
CMS configuration enforces that draft, pending, and private pages cannot be accessed by the public. No exceptions. Eliminates the 46 publicly accessible draft/test pages identified in the audit.
Permanent URLs for recurring events
Ramadan lives at /ramadan. Eid lives at /eid. Page updated annually; URL never changes. No /ramadan-23, /eid-5. Hard rule enforced editorially.
Image standards enforced at upload
No WhatsApp flyers as announcements. Every announcement is text content with optional supporting image. Images require alt text at upload (CMS blocks publishing without it). Maximum upload dimensions enforced. WebP conversion automatic.
Infrastructure
Skyward Blue CRM integration
The website and CRM are two halves of the same system. Every form creates or updates a record in Skyward Blue with source tagging.
| Website form | CRM action | Follow-up trigger |
|---|---|---|
| Visit request (tours) | Create contact + opportunity with source "website-visit-request" | Department coordinator notified within 24 hours |
| "Ask a Question" | Create contact + inquiry with source "website-question" | Routed to outreach team; fiqh questions routed to Imam |
| Shahadah interest | Create contact + opportunity type "shahadah-interest" | Content lead + department coordinator notified immediately |
| Volunteer intake | Create contact + volunteer record with track preference, source "website-volunteer" | Department coordinator adds to onboarding queue |
| Group visit booking | Create org contact + visit opportunity with group type tag | Department coordinator notified; presenter assignment triggered |
| General contact | Create contact + inquiry with routing tag | Routed to appropriate department |
| Event registration | Create/update contact + event attendance record | Confirmation email; post-event follow-up sequence |
Infrastructure
Event management workflow
A single intake form starts the process. Once approved, events flow to the website automatically — no separate manual entry, no bottleneck waiting on one person to create a page.
The current problem
Today, getting an event onto raleighmasjid.org requires a chain of human handoffs: someone decides to hold an event, they communicate it (email, Slack, conversation), someone with website access creates the page or calendar listing manually, and someone has to remember to remove or update it after the event passes. Every link in that chain is a person — and when any one of them is busy, traveling, or forgets, the website is either missing an event that's happening or displaying an event that already happened. The 13 outdated event pages identified in the site audit are the predictable outcome of this process.
Proposed workflow
Step 1 — Submit
Internal event request form
Any authorized IAR person — committee chair, program coordinator, staff member, or approved partner — submits an event through a single internal form. This is not a public-facing form; it's behind a login or accessed via a shared internal link. The form captures all the data the website needs in one pass, eliminating the need for anyone to re-enter information later.
Step 2 — Review
Event enters approval queue
Submitted events land in a review queue visible to designated approvers. The approver sees the full event details and can approve, request changes (returned to submitter with notes), or reject. No event reaches the website without explicit approval. The review queue can live in Skyward Blue (preferred, keeps everything in one system) or as a WordPress editorial workflow (draft → pending review → published).
Step 3 — Approve
Approver confirms → event status changes to "approved"
One click. The approver doesn't need to create a page, write a description, or do any web work. They're confirming that the event is real, the details are correct, and it should appear on the website. The event data was already entered completely in Step 1.
Step 4 — Auto-publish
Approved events appear on the website automatically
Upon approval, the event is published to the Programs & Events calendar on raleighmasjid.org. It appears in the correct audience and category filters based on the tags set during submission. If the event has a registration link, it's live. If it was flagged for homepage "What's Happening," it appears there. No one touches the website. The data flows from the approved record to the frontend.
Step 5 — Auto-archive
Past events are automatically removed from active display
Events disappear from the public calendar and homepage after their end date passes. They're not deleted — they move to an archived state, accessible for reporting and historical reference, but no longer visible to site visitors. No one needs to remember to clean up. This is what eliminates the 13+ outdated event pages the audit identified.
Event data schema — captured once at submission
| Field | Type | Notes |
|---|---|---|
| Event title | Text | How it appears on the calendar and website |
| Date & time | Date/time picker | Start and end. Support for multi-day and recurring events. |
| Location | Dropdown + text | Pre-populated IAR locations (Main Hall, Gym, Sisters' Hall, Page Campus, etc.) or custom entry for off-site |
| Description | Rich text | 2–4 sentence public description. This is what appears on the website — no rewriting needed downstream. |
| Community tags | Multi-select | Youth, College/YP, Sisters, Seniors, New Muslims, Special Needs, General Community. Drives the "Browse by Community" filters. |
| Category tags | Multi-select | Educational, Religious, Social, Sports, Volunteer, Community Event. Drives "Browse by Type" filters. |
| Registration link | URL (optional) | External registration (Eventbrite, Google Form, Skyward Blue) or "No registration required" |
| Contact person | Dropdown | Pre-populated staff/committee contacts. Displayed on the event page for questions. |
| Submitting committee | Dropdown | For tracking which committee/department submitted. Used for reporting, not displayed publicly. |
| Flyer / image | File upload (optional) | Optional supporting image. Not the primary content — the text fields above are what appears on the site. Image is supplementary. |
| Featured on homepage? | Checkbox | Whether this event should appear in the "What's Happening" homepage section. Approver can override. |
| Recurrence | Dropdown | One-time, weekly, biweekly, monthly, annual. Recurring events auto-generate future instances. |
Approval authority
Routine events
Weekly programs, halaqahs, recurring youth nights, study circles, committee meetings. These follow an established pattern and have standing approval. They can be entered once as recurring events and only need re-approval if the details change. Approver: department head or program coordinator with publishing rights.
New or special events
New programs, one-time events, external partnerships, fundraisers, events requiring facility reservation or significant promotion. These require explicit review. Approver: designated staff member (CEO, department head, or operations manager) depending on event scope. Facility reservation confirmation should be a prerequisite for approval.
Recurring event handling
Recurring events (weekly halaqahs, monthly YP dinners, biweekly sisters' circles) are entered once with a recurrence pattern. The system auto-generates future instances. If a single instance needs to be cancelled or modified (e.g., "no basketball night this week due to Eid"), the submitter updates that specific instance — the rest of the series remains unchanged. Seasonal programs like Ramadan taraweeh are entered as a date-range series and auto-archive when the range ends.
Integration points
Website (WordPress)
Approved events are published as WordPress event posts using The Events Calendar or a custom post type with the audience/category taxonomy. The homepage "What's Happening" section pulls the next 4–5 approved events ordered by date. The Programs & Events page displays all events with tag-based filtering. Past events are automatically excluded from public queries.
Skyward Blue CRM
Event records are created in Skyward Blue upon approval — enabling registration tracking, attendance logging, and post-event follow-up. Event registrations from the website form flow into Skyward Blue contact records with the event as the source. Post-event: automated follow-up sequences can be triggered (thank you email, feedback survey, next event invitation).
Technical implementation options
| Approach | How it works | Pros / Cons |
|---|---|---|
| WordPress-native workflow | Events are custom post types in WordPress. Submitters use a front-end form (Gravity Forms or custom) that creates a draft event post. Approvers review in the WordPress admin dashboard and click "Publish." Skyward Blue syncs via webhook or API on publish. | Pro: Everything in one system. Simple for approvers who already use WordPress. Con: Requires submitters to use a WordPress-connected form. Reporting limited to WordPress. |
| Skyward Blue as system of record | Events are submitted and approved entirely within Skyward Blue. On approval, an API call or webhook pushes the event data to WordPress, which creates the published event post automatically. Website is a display layer only — all event management happens in CRM. | Pro: Single system of record. Registration, attendance, and follow-up all in one place. Better reporting. Con: Requires Skyward Blue → WordPress integration development. More complex initial build. |
| Hybrid | Submission happens in Skyward Blue (captures contact and committee data). On approval, event data syncs to WordPress for publishing. Registration flows back to Skyward Blue. Each system does what it's best at. | Pro: Best of both — CRM for people/data, WordPress for publishing. Con: Two-way sync adds complexity. Need to define which system is authoritative for edits. |
What this eliminates
No more forgotten events
If it's approved, it's on the site. No one needs to remember to "also update the website."
No more stale event pages
Auto-archive after event date. No more Ramadan 2023 pages lingering for years.
No more data re-entry
Description, time, location, tags — entered once by the person who knows. Not retyped by a webmaster who's guessing.
No single-person bottleneck
Multiple people can submit. Multiple approvers can be designated. No one person holds the keys to the calendar.
No inconsistent tagging
Community and category tags are dropdown selections, not free-text. The "Browse by Community" filters work because the taxonomy is enforced at submission.
No WhatsApp flyer dependency
Events are text content with optional supporting images. Accessibility, searchability, and mobile readability are built in.
Infrastructure
Centralized intake & feedback
Every request the community makes to IAR — from a room reservation to a fiqh question to a complaint — should enter through a consistent, professional interface, receive an immediate acknowledgment, and be tracked to resolution.
The problem this solves
With thousands of community members, IAR is vulnerable to misinformation and misinterpretation when processes are informal, inconsistent, or invisible. Today, different services have different intake methods — some have web forms, some accept emails, some require a phone call, some happen through a conversation in the hallway. When a request enters through an informal channel, there is no acknowledgment, no tracking, and no accountability. The community member doesn't know if their request was received, who is handling it, or when to expect a response. When responsiveness lapses — and it does, as it does in most nonprofit organizations — trust erodes. People fill the silence with assumptions.
A centralized, standardized intake system doesn't just solve a logistics problem. It signals that IAR is a mature, professional institution that takes every community member's needs seriously. When someone submits a request and immediately receives "We received your request for X. You'll hear back within Y days from Z department" — that is a trust-building moment, even before anyone does any work.
Architecture: centralized request system
How it works
The website is IAR's intake system — not a directory of phone numbers to try
Every service page on the website ends with a standardized request or inquiry form. All forms feed into Skyward Blue with consistent fields, routing rules, and automated acknowledgments. The community member's experience is always the same: submit → acknowledge → route → respond. Behind the scenes, each request type routes to the right department with the right SLA.
Layer 1 — Standardized intake forms
Consistent form structure across all services
Every request form on the site uses a shared structure: name, contact information, request type (dropdown with the specific service pre-selected based on the page they're on), message/details, and a submit button. The community member doesn't need to figure out who to email or which number to call. They fill out the form on the relevant service page. If they can't find the right page, the general "Contact Us" form routes their request based on the type they select.
Layer 2 — Immediate automated acknowledgment
Every submission receives a response within seconds
Upon form submission, the community member receives an automated email acknowledging their request with: a reference number, a confirmation of what they requested, the department that will handle it, and the expected response timeframe. This is not optional. It is the single most important trust-building moment in the entire interaction. The person knows their request didn't go into a void.
Layer 3 — Routing and assignment
Requests automatically route to the responsible party
Each request type has a predefined routing rule in Skyward Blue. Marriage inquiries go to the Marriage Services coordinator. Fiqh questions go to the Imams' office. Room reservations go to Facilities. Outreach inquiries go to the Department coordinator. Routing is automatic — no one needs to read and forward emails. The responsible party sees the request in their Skyward Blue queue with all the details already captured.
Layer 4 — Response time commitments
Published SLAs by request type
Each request type has a published expected response time — visible on the website and included in the acknowledgment email. These are commitments, not aspirations. If a request exceeds its response window, Skyward Blue escalates to a supervisor or department head. The community knows what to expect; staff knows they're accountable.
Layer 5 — Escalation on non-response
Nothing falls through the cracks
Skyward Blue flags any request that passes its SLA without a response logged. The escalation goes to the department head or a designated operations manager. This is the accountability mechanism that prevents the system from degrading. It doesn't require anyone to check manually — the CRM does the tracking automatically.
Request types and response commitments
| Request type | Routes to | Response commitment |
|---|---|---|
| Visit / tour request | Department coordinator | 48 hours |
| Group visit booking | Department coordinator | 48 hours |
| Shahadah interest | Content lead | 24 hours |
| General Islam question | Outreach team | 3 business days |
| Fiqh / religious inquiry | Imams' office | 5 business days |
| Marriage / nikah request | Marriage Services | 3 business days |
| Funeral / janazah (urgent) | Operations + Imam | Same day |
| Room reservation | Facilities | 3 business days |
| Social services / welfare | Social Services | 3 business days |
| Counseling referral | Counseling coordinator | 3 business days |
| Letter request | Administration | 5 business days |
| Volunteer interest | Department coordinator | 5 business days |
| Career / job inquiry | HR / Administration | 5 business days |
| General question / other | Main office → triaged | 3 business days |
| Feedback / suggestion | See feedback section below | Acknowledged immediately; reviewed monthly |
Evergreen feedback mechanism
Separate from service requests, the community needs a persistent, always-available way to provide feedback — praise, complaints, suggestions, or concerns — that is not tied to a specific transaction or event. This is the "I need to tell someone at IAR about something" channel.
Where it lives on the site
A "Share Feedback" link in the site footer — visible on every page, always accessible. Links to a dedicated feedback page with a simple form: name (optional — anonymous feedback allowed), contact info (optional), feedback type (suggestion, concern, compliment, question), and a free-text message. Keeping the name optional is important: some concerns won't be shared if attribution is required.
What happens with submissions
Every submission receives an automated acknowledgment: "Thank you for your feedback. It has been received and will be reviewed by IAR leadership." Feedback routes to a designated inbox or Skyward Blue queue reviewed by a senior staff member on a defined cadence — weekly or monthly depending on volume. Feedback that requires action is triaged and routed. Feedback that is informational is logged and included in periodic leadership reports.
Feedback that requires a response
If the person provided contact information and the feedback is a complaint or question, it should be triaged and responded to within the general inquiry SLA (3 business days). The response doesn't need to solve the problem — it needs to acknowledge the concern and describe what will happen next. "We received your feedback about X. We've shared it with the relevant department and they will follow up by Y."
Feedback that is informational
Suggestions, compliments, and anonymous feedback that doesn't require a direct response are still valuable. They are logged in Skyward Blue and included in a monthly summary reviewed by leadership. Patterns matter: if five people independently submit feedback about the same issue, that's a signal even if no individual submission demands a response.
Closing the loop publicly
Consider a periodic "You spoke, we listened" update — in the newsletter, on the website, or at a town hall — that summarizes community feedback themes and what IAR did about them. This completes the trust cycle: the community sees that their feedback isn't just collected but acted upon. Even acknowledging "We've heard concerns about X and are working on it" builds credibility.
Why centralization matters beyond efficiency
Prevents misinformation
When processes are visible and documented on the website, the community has a single source of truth. "Here's how to request a nikah. Here's the timeline. Here's what to expect." No more conflicting secondhand information.
Prevents lost requests
An email to a personal inbox can be missed. A voicemail can be forgotten. A hallway conversation was never recorded. A Skyward Blue ticket with an SLA and escalation trigger cannot be silently dropped.
Enables measurement
When every request is tracked, IAR can measure: How many requests of each type per month? What's the average response time? Where are the bottlenecks? Which departments need more capacity? You can't improve what you don't measure.
Signals professionalism
A consistent, polished intake experience tells the community: this is an institution that takes your needs seriously. The automated acknowledgment alone — "We received your request" — sets IAR apart from the nonprofit norm of silence.
Protects staff
When there is no system, the burden falls on whichever individual the community member happens to reach. That person becomes the bottleneck, the scapegoat, and the single point of failure. A system distributes the load and makes responsiveness an organizational capability, not a personal one.
Builds institutional memory
When a staff member leaves, their email inbox and personal knowledge leave with them. A CRM retains every interaction, every request, every resolution. The next person picks up without the community experiencing a gap.
Execution
Migration plan
A rebuild doesn't mean starting from zero content. Here's the triage.
Keep & migrate
Content that works
Ramadan Hub (restructure under /ramadan). Waqf/Endowment page. Special Needs Services. Shura page. Membership page. Marriage, Divorce, Cemetery, Social Services pages. Islamic education knowledge base articles. Fiqh database. "Become a Part of Something More" footer verse element.
Rewrite
Content that needs rethinking
Homepage. About/Our Story. FAQ (fix org name references, verify prayer times). Careers (add posting dates). Official Statements (expand or fold into About). Facilities (replace 2018 post with actual facilities info). Programs section (restructure by audience and type). All event pages (create permanent URLs).
Delete
103+ pages
All 46 draft/test pages. All 20 dead/error pages. All 13 outdated event pages. All 24 sparse/utility pages (move digital signage pages to non-public status if still needed). All Elementor-numbered pages. All copy/staging/duplicate pages.
New content to create
| Page | Owner | Priority |
|---|---|---|
| "Plan Your Visit" — what to expect, tailored for individuals | Content lead | Launch |
| "Group Visits" — tailored for schools, churches, organizations | Content lead | Launch |
| "Ready to Take Shahadah?" — actionable pathway with contact | Content lead | Launch |
| "New Muslim Resources" — prayer app, guides, programs | Content lead | Launch |
| "Ask a Question" — contact form for Islam/IAR questions | Content lead | Launch |
| "Get Involved" — volunteer tracks, membership, Waqf | Content lead | Launch |
| "Find Your Community" browse page — audience-categorized | Content lead + web team | Launch |
| Visitor walkthrough video page | Content lead + media volunteers | Post-launch |
| Community partnership pages | Content lead | Post-launch Q4 |
URL redirect strategy
Every page that is being kept but moved to a new URL path requires a 301 redirect from old to new. This preserves Google page authority and prevents broken bookmarks/links. The redirect map is a spreadsheet: old URL in column A, new URL in column B — built before the swap, not after. Pages being deleted should return proper 410 (Gone) responses, not 404, to signal search engines the removal is intentional.
Execution
Timeline
Five phases from immediate cleanup through launch and post-launch enhancement. This project should begin as soon as possible — the site degrades further every day it operates without accountable ownership.
| Task | Owner | Effort |
|---|---|---|
| Delete 46 draft/test pages | Web team | 2 hours |
| Delete 20 dead/error pages | Web team | 1 hour |
| Delete 13 outdated event pages | Web team | 1 hour |
| Fix "Facilities" link (remove or point to correct page) | Web team | 15 min |
| Fix Islamic education landing page title tag | Content lead | 5 min |
| Add meta description to Islamic education landing page | Content lead | 10 min |
| Fix 17 critical broken outbound links | Web team | 3 hours |
| Review and hide 24 sparse/utility pages (set to noindex or private) | Web team | 2 hours |
| Task | Owner | Effort |
|---|---|---|
| Present proposal to web working group and CEO | Content lead | Presentation + discussion |
| Secure alignment on IA, audience model, and "many doors, one building" approach | Web working group | 1–2 meetings |
| Identify or procure hosting with staging support | Web team | 1 week |
| Select and contract developer/agency (if external) | Web working group | 2–3 weeks |
| Write "Plan Your Visit" page content | Content lead | 4 hours |
| Write "Group Visits" page content | Content lead | 4 hours |
| Write "Ready to Take Shahadah?" page content | Content lead | 3 hours |
| Write "New Muslim Resources" page content | Content lead | 3 hours |
| Write "Get Involved" page content (all volunteer tracks) | Content lead | 4 hours |
| Draft content owner assignments for all pages | Content lead + web team | 2 hours |
| Build URL redirect map (old → new) | Web team | 4 hours |
| Build Islamic search synonym dictionary | Content lead | 3 hours |
| Define event submission form fields, approval authorities, and recurring event inventory | Content lead + program coordinators | 4 hours |
| Catalog all current recurring programs with frequency, audience, and category tags | Content lead | 3 hours |
| Map all request types, current intake methods, and responsible parties; define SLA targets per request type | Content lead + department heads | 4 hours |
| Draft automated acknowledgment email templates for each request type | Content lead | 3 hours |
| Task | Owner | Effort |
|---|---|---|
| Set up staging environment | Developer | 1 day |
| Build custom WordPress theme (header, footer, page templates) | Developer | 3–4 weeks |
| Implement prayer times display (adhan + iqamah, auto-highlight) | Developer | 1 week |
| Implement search (synonym dictionary, intent ranking, suggestions) | Developer | 1–2 weeks |
| Set up events calendar with audience/type taxonomy filters | Developer | 1 week |
| Build event submission form and approval workflow (submit → review → approve → auto-publish) | Developer + content lead | 1 week |
| Configure auto-archive for past events | Developer | 2 days |
| Enter recurring events (weekly programs, halaqahs, youth nights) into system | Web team + program coordinators | 1 day |
| Build and connect all Skyward Blue forms with source tagging | Developer + content lead | 1 week |
| Migrate "keep" content to new templates | Web team + content lead | 2 weeks |
| Build new content pages from Phase 2 drafts | Web team | 1 week |
| Configure image optimization pipeline (WebP, resize, alt text enforcement) | Developer | 2 days |
| Implement SEO (titles, meta, OG tags, structured data) | Developer | 3 days |
| Configure caching (page cache, browser cache headers, Cloudflare) | Developer | 1 day |
| Accessibility audit and fixes | Developer + QA | 1 week |
| Mobile testing (iPhone, Android, iPad) | QA | 3 days |
| Cross-browser testing (Chrome, Safari, Firefox, Edge) | QA | 2 days |
| Performance testing (target: sub-2s on 4G mobile) | Developer | 2 days |
| Build standardized service request forms with routing rules and auto-acknowledgment | Developer + content lead | 1 week |
| Build feedback form and page; configure routing and acknowledgment | Developer | 2 days |
| Add "Share Feedback" link to site footer | Developer | 1 hour |
| End-to-end form testing with Skyward Blue | Content lead + department coordinator | 1 day |
| Task | Owner | Effort |
|---|---|---|
| Final stakeholder review on staging | Web working group | 1 meeting |
| Push staging to production | Developer | 1 hour |
| Activate 301 redirects (old URLs → new URLs) | Developer | 1 hour |
| Verify all forms are live and feeding to Skyward Blue | Content lead | 2 hours |
| Submit updated sitemap to Google Search Console | Developer | 15 min |
| Monitor for 404s and broken links (first 2 weeks) | Web team | Ongoing |
| Confirm content owners for every page; set review calendar | Content lead + web team | 2 hours |
| Train committee chairs and program coordinators on event submission form | Content lead + web team | 2 hours |
| Test full event workflow end-to-end: submit → approve → verify on site → verify auto-archive | Content lead | 1 hour |
| Announce to community (email, social, Jummah) | Communications | 1 day |
| Enhancement | Owner | Priority |
|---|---|---|
| Visitor walkthrough video production and page | Content lead + media volunteers | Q4 |
| AI assistant: index site content into vector store, build RAG pipeline, deploy chatbot widget | Developer | Q4 |
| AI assistant: configure guardrails, test common query patterns, set up human handoff to intake forms | Developer + content lead | Q4 |
| Community partnership pages | Content lead | Q4 |
| Skyward Blue ↔ WordPress event sync (bidirectional: CRM as system of record) | Developer + CRM team | Q4+ |
| SLA tracking and automated escalation for overdue requests in Skyward Blue | Content lead + CRM team | Q4 |
| Expand standardized intake forms to all remaining service types | Web team + department heads | Q4 |
| First "You spoke, we listened" feedback summary (newsletter or website) | Content lead | Q1 2027 |
| Multimedia resources for knowledge base (video, audio) | Media volunteers | Q4+ |
| Convert stories / testimonials section | Content lead | Q1 2027 |
| Glossary of Islamic terms | Content lead | Q1 2027 |
| Analytics review and navigation optimization | Web team | Monthly |
| First quarterly content review cycle | All content owners | Q4 |
Execution
Committee content development plan
IAR operates on a five-pillar model with ~25 committees. Each committee or service group is a content stakeholder whose programs, services, and audience-facing information must be represented on the new site. This section defines the engagement model, content priorities, and specific milestones each committee chair must participate in.
Core principle
The web team builds the house — committees furnish their rooms
The web team owns the site architecture, design system, templates, and governance. Committees own the accuracy and completeness of their content. Each committee chair is responsible for providing, reviewing, and maintaining the content for their area. The web team does not write committee content — they provide the structure, templates, and support to make it easy for committees to contribute effectively.
Engagement model
Each committee goes through a structured content development process with the web team. The process is the same regardless of committee size or priority — what changes is the sequence and the depth of content expected at launch vs. post-launch.
Step 1 — Content audit meeting
30-minute meeting with the web team to review: what the committee currently has on the site, what's accurate, what's outdated, and what's missing. The web team brings the audit data; the committee chair brings institutional knowledge of what they actually offer.
Step 2 — Content brief
The web team provides a content brief: a template showing exactly what's needed for the committee's section. Page title, description, services/programs list, contact information, intake forms needed, and any audience tags. The committee chair fills in the content — they don't have to design anything.
Step 3 — Review and publish
The web team builds the page from the brief. The committee chair reviews for accuracy. One round of revisions. Published. The committee chair is now the page owner responsible for ongoing accuracy per the content governance model.
Step 4 — Event and program integration
The committee chair (or designated coordinator) is trained on the event submission workflow. Recurring programs are entered once. Future events follow the submit → approve → auto-publish process. No more asking someone to "update the website."
Priority tiers — based on community impact
Tier 1 — Launch-critical (content required before go-live)
| Committee / Body | Pillar | Why Tier 1 | Key content needed | Chair milestone |
|---|---|---|---|---|
| Al-Iman School | Institutes | Hundreds of families; daily engagement; primary driver of website traffic from parents | School overview, enrollment info, campus descriptions, contact. Links to external school site. | Content brief completed by end of Phase 2 |
| Al-Furqan Weekend School | Institutes | Largest weekend program; hundreds of K–12 families | Program description, schedule, enrollment, contact. Links to external site. | Content brief completed by end of Phase 2 |
| An-Noor Quran Academy | Institutes | Quran memorization school; dedicated parent community | Program description, enrollment, contact. Links to external site. | Content brief completed by end of Phase 2 |
| Women's Committee | Community | Serves ~50% of the community; currently no dedicated web presence despite active programming | Sisters landing page, program listings, halaqah schedules, contact, community resources | Content audit meeting in Phase 2. Content brief completed by mid-Phase 3. |
| Youth Committee | Community | One of the largest and fastest-growing segments; parents actively search for youth programming | Youth landing page, program listings by age group, sports schedule, teen events, parent resources | Content audit meeting in Phase 2. Content brief completed by mid-Phase 3. |
| Cemetery & Burial | Services | Crisis service — when a family needs this, they need it immediately. No room for confusion or outdated info. | What to do when someone passes, janazah process at IAR, cemetery information, contact for immediate assistance | Content audit meeting in Phase 2. Content reviewed for accuracy by Phase 3. |
| Social & Welfare | Services | Serves the most vulnerable community members; time-sensitive requests; high trust requirement | Services available, eligibility guidance, how to request help, contact, intake form with SLA | Content audit meeting in Phase 2. Intake form spec finalized by Phase 2. |
| Dawah & Outreach | Services | Gateway for every newcomer, non-Muslim visitor, and new Muslim. Front door of the website for non-community audiences. | Visit Us section content, Islamic education knowledge base, shahadah pathway, new Muslim resources, group visit info, ask-a-question form | Content production in Phase 2 (several pages). Review and iteration through Phase 3. |
| Fundraising | Administration | Revenue-critical; donation pages are high-traffic; seasonal campaigns (Ramadan, year-end) drive significant giving | Donate page, campaign pages, Waqf/endowment, giving options, tax receipt info | Content audit meeting in Phase 2. Donation page spec finalized by mid-Phase 3. |
Tier 2 — High priority (target for launch, can extend to first month post-launch)
| Committee / Body | Pillar | Why Tier 2 | Key content needed | Chair milestone |
|---|---|---|---|---|
| Education Committee | Services | Broad programming (halaqahs, seminars, Quran classes) serving multiple audience segments | Program descriptions, schedules, registration links, audience tags | Content audit meeting in Phase 3. Brief completed by end of Phase 3. |
| Health & Wellness | Services | Counseling referrals, mental health resources — sensitive and high-trust content | Services overview, referral process, contact, confidentiality assurance | Content audit meeting in Phase 3. Content reviewed for sensitivity. |
| Sports & Recreation | Community | Youth basketball, fitness programs, community engagement — high participation | Programs, schedules, registration, facility info | Content brief completed by end of Phase 3. |
| Older Adult Community | Community | Growing segment; dedicated programming; accessibility considerations | Programs, schedule, accessibility info, contact | Content brief completed by end of Phase 3. |
| Volunteer Committee | Community | Cross-cutting — supports all pillars. Get Involved page is a key conversion point. | Volunteer tracks, time commitments, intake form, benefits of volunteering | Content brief completed by Phase 2 (feeds Get Involved page). |
| Al-Maidah Kitchen | Institutes | Daily food service; event catering; high community visibility | Menu/services, catering request process, hours, contact | Content brief completed by end of Phase 3. |
| Endowment (Waqf) | Institutes | Existing page is one of the best on the site — migrate and update data | Endowment overview, giving options, financial report links, impact data | Review existing page content for currency. Update financial figures. |
| Events Committee | Operations | Manages logistics for all major events. Key user of the event submission workflow. | Event submission process documentation, contact. Primary user of new workflow. | Trained on event submission workflow by Phase 4. Enter all recurring events into system. |
Tier 3 — Post-launch (Q4 2026 and beyond)
| Committee / Body | Pillar | Content needed | Chair milestone |
|---|---|---|---|
| Membership & Elections | Administration | Membership page update (already exists and works), election information when applicable | Review existing membership content. Update as needed post-launch. |
| Finance | Administration | Financial transparency page, annual report links, budget summaries | Provide updated financial report for Publications section. |
| IT Services | Operations | Internal-facing; minimal public content. Staff portal resources. | Participate in technical requirements discussions as needed. |
| Marketing | Operations | Internal processes. Supports content production across committees. | Align on brand guidelines, photo standards, and announcement workflow. |
| Public Relations | Operations | Press and media resources, official statements, external communications | Provide press/media contact info and any existing press resources. |
| Facility Maintenance | Operations | Room reservation process (already in services). Facility info for both campuses. | Review room reservation and facility content for accuracy. |
| Safety & Security | Operations | Emergency procedures (may be internal only). Public safety info if applicable. | Determine what, if anything, should be public-facing. |
| Cleaning Crew | Operations | No public-facing content needed. | None. |
| Legal Advisory | Administration | No public-facing content needed. | Available for legal review of site content if requested. |
| Planning & Construction | Administration | Facility development updates as projects arise. No standing content. | Provide updates when active projects exist. |
| Strategic Planning | Administration | Internal. May inform Publications section (strategic plan documents). | None for website purposes. |
| Page Road | Institutes | Campus landing page with programs, location, and contact | Content brief completed Q4. |
Administration team milestones
Beyond individual committees, the Administration team and pillar directors have cross-cutting responsibilities in the rebuild:
| Role | Milestone | When |
|---|---|---|
| CEO | Approve information architecture and homepage design. Final sign-off on launch. | Phase 2 (approval), Phase 4 (launch sign-off) |
| Community Pillar Director | Coordinate content audit meetings for Women, Youth, Older Adult, Sports, and Volunteer committees. Ensure all community-facing content briefs are complete by mid-Phase 3. | Phases 2–3 |
| Institutes Director | Coordinate with school chairs to ensure school descriptions and links are current. Review Endowment page financials. Confirm Al-Maidah Kitchen and Page Road content. | Phase 2 (schools), Phase 3 (others) |
| Secretary | Provide current governance documents (constitution, bylaws) for Publications section. Verify Shura and Board member listings. | Phase 3 |
| Treasurer | Provide current financial report data for Endowment and Publications pages. Confirm donation page payment processing details. | Phase 3 |
| IT Services Chair | Technical liaison for hosting, DNS, and staging environment setup. Staff portal requirements. | Phase 2 (environment), ongoing |
Execution
Resource requirements
What this project needs in terms of people, skills, and estimated effort. Engineering estimates are based on independent technical review.
Phased engineering effort
| Phase | Scope | Est. Hours |
|---|---|---|
| Pre-Phase — Planning & Technical Alignment | Technical planning, environment setup, architecture validation, initial stakeholder coordination | 30–50 |
| Phase 1 — Design Implementation | Core templates: homepage, key landing pages, reusable layout components | 60–100 |
| Phase 2 — Core Development | Custom WordPress theme (non-Elementor), component architecture, performance optimization | 140–220 |
| Phase 3 — Content Migration (Selective) | Migration of prioritized content per keep/rewrite/remove framework. High-value pages for launch. | 60–120 |
| Phase 4 — Integrations & Workflows | Forms, CRM integration, event management workflow, centralized intake system | 50–100 |
| Phase 5 — QA, Launch & Deployment | Staging validation, issue resolution, coordinated deployment to production | 30–60 |
| Phase 6 — Project Coordination | Stakeholder communication, reviews, approvals, release coordination throughout lifecycle | 40–80 |
| Total Estimated Effort | Core website launch | 400–730 hours |
Roles required
Core — required
WordPress Developer
Builds custom theme, implements search, configures forms, handles performance optimization, accessibility, and launch. Must be comfortable building without Elementor — custom theme with Gutenberg block templates. No Elementor code, templates, or plugins will be present in the new site.
Primary effort: ~290–500 hours (Phases 1–5)
Core — required
Content Lead / Content lead
Writes all new page content (Visit Us section, Get Involved, shahadah pathway, new Muslim resources). Manages content migration decisions. Builds synonym dictionary. Assigns content owners. Tests CRM integrations.
Est. 60–80 hours across all phases
Core — required
Project Coordinator / Web Working Group Lead
Manages approvals, coordinates between developer, content lead, and stakeholders. Tracks timeline. Facilitates working group meetings. Ensures cross-committee alignment on content.
Est. 40–80 hours (Phase 6 coordination)
Core — required
Web Team / Site Administrators
Execute Phase 1 cleanup. Assist with content migration. Handle ongoing page management. Execute URL redirects. Monitor post-launch.
Est. 30–50 hours across all phases
Recommended
UX/Visual Designer
Translates the information architecture and mockups into polished visual designs. Creates brand-consistent page layouts, icon sets, photography direction. If budget is limited, the developer can work from the interactive mockups directly.
Est. 40–60 hours in Phase 1
Recommended
QA / Testing Support
Mobile testing, cross-browser testing, accessibility audit, form testing. Can be the developer if budget is tight, but dedicated QA produces better results.
Est. 20–30 hours in Phase 5
Developer engagement — options comparison
Market context — what this project costs commercially
Current market data for custom WordPress development (2026 pricing, US-based vendors) breaks this project's scope into component costs:
| Component | Market rate (US) | IAR scope notes |
|---|---|---|
| Custom WordPress theme | $6,000 – $15,000 | Complex: 6+ templates, locked layouts, mobile-first, WCAG AA, sub-2s performance target. No page builder. |
| CRM integration (Skyward Blue) | $3,000 – $8,000 | Custom CRM (not Salesforce/HubSpot). Form routing, auto-acknowledgment, source tagging, SLA tracking. |
| Event workflow system | $3,000 – $6,000 | Submit → review → approve → auto-publish → auto-archive. Recurring events. Taxonomy-based filtering. |
| Search with synonym handling | $2,000 – $5,000 | Islamic transliteration dictionary, intent ranking, scoped suggestions. Algolia or SearchWP. |
| Content migration (selective) | $3,000 – $8,000 | 347-page audit. Keep/rewrite/delete triage. URL redirect map. Metadata preservation. |
| Forms + centralized intake | $2,000 – $4,000 | Standardized forms, department routing, auto-acknowledgment, SLA display. |
| SEO + structured data | $1,000 – $3,000 | Title/meta/OG on every page. Organization, Event, FAQPage schema. Sitemap. Search Console. |
| QA + testing | $2,000 – $4,000 | Cross-browser, mobile, accessibility audit, form testing, performance validation. |
| Project coordination | $3,000 – $6,000 | Stakeholder management, release coordination, committee engagement support. |
| Total commercial range | $25,000 – $59,000 | US-based agency or senior freelancer. This is the market rate for this scope. |
Recommended
Br. Sabeel Ahmed's team — $11,000 to $19,000
Br. Sabeel's company has provided a cost estimate of $11,000 to $19,000 for the full rebuild scope, with the range depending on actual hours used. This is 55–68% below the commercial market rate for a project of this complexity. IAR has already engaged his team as a vendor on website and technical updates, so there is an established working relationship, proven familiarity with the codebase, and an understanding of IAR's operational context.
| Est. cost | $11,000 – $19,000 (vs. $25,000–$59,000 commercial market rate — a savings of $14,000–$40,000) |
| Risk level | Low — Established relationship, proven capability, community alignment, and prior site familiarity reduce onboarding time and miscommunication risk. |
| Community fit | Strongest of any option — This is a team that understands the needs and sensitivities of our Muslim community. They know Islamic terminology, the content boundaries around theological topics, and IAR's organizational dynamics. No commercial vendor can replicate this without weeks of onboarding that adds both cost and risk of misunderstanding. |
| Timeline risk | Low — Paid engagement with defined scope creates accountability. Prior working relationship means fewer unknowns in communication patterns and expectations. |
| Maintenance | Ongoing relationship for post-launch support, updates, and Phase 5 enhancements. Continuity of knowledge — the team that built it maintains it. |
| Considerations | Formalize scope, milestones, and payment schedule based on this proposal. Ensure capacity alignment with IAR's target timeline. |
Alternative
Freelance WordPress developer (US market) — $20,000 to $35,000
Hiring a freelance developer from the open market. US-based freelancers with custom theme experience typically charge $75–$125/hour. At the estimated 300–400 hour focused scope, this produces the range below.
| Est. cost | $20,000 – $35,000 (1.8–3× Br. Sabeel's estimate) |
| Risk level | Medium — Quality is highly variable. Vetting takes time. No prior IAR context — significant onboarding required to understand the community, content sensitivities, and organizational dynamics. |
| Community fit | Weak — Islamic terminology, audience sensitivities, theological content boundaries, and organizational context must all be taught. Miscommunication risk is high on content-sensitive pages (shahadah pathway, Imam guidance, social services). |
| Timeline risk | Medium — Paid engagement creates accountability, but a new relationship has unknowns. Selection process itself adds 2–3 weeks. |
| Maintenance | Post-launch support depends on the freelancer's availability. No guarantee of long-term relationship. If unavailable, a new developer must learn the codebase from scratch. |
Alternative
WordPress agency (US-based) — $30,000 to $59,000
A professional web development agency handles design, development, QA, and project management as a package. Lower management burden on IAR but 3–5× the cost of Br. Sabeel's team.
| Est. cost | $30,000 – $59,000 (2.7–5.4× Br. Sabeel's estimate) |
| Risk level | Low-Medium — Professional processes, dedicated PM, and QA reduce technical risk. But agencies optimize for throughput, not community understanding. IAR becomes one client among many. |
| Community fit | None — No inherent understanding of the Muslim community context. Design instincts default to generic nonprofit templates. IAR would invest heavily in onboarding the agency on cultural and content sensitivities — and still risk getting something that doesn't feel authentically IAR. |
| Maintenance | Most agencies offer maintenance retainers ($500–$2,000/month). Professional but impersonal. Staff turnover means the person who built the site may not be the person maintaining it. |
High risk — not recommended
Community volunteer developer — $0
A skilled developer from the IAR community donates their time. Cost is zero, but the risks are substantial and well-documented in nonprofit technology projects.
| Est. cost | $0 (hosting and tools costs only) |
| Risk level | Very High — see below |
| Timeline risk | Very High — Volunteers have day jobs, families, and competing priorities. IAR has no contractual leverage to enforce deadlines. A 5-month project can easily stretch to 12–18 months. If the volunteer's life circumstances change mid-project, the work stalls with no recourse. |
| Maintenance | The most dangerous long-term risk. When the volunteer's availability decreases — and it will — the site has no maintainer. IAR is left with a codebase that only one person understands and that person is no longer available. This is how the current site got to its present state. |
| Accountability | A volunteer cannot be held to milestones, SLAs, or quality standards in the same way a paid resource can. Feedback feels like criticism of a gift. Scope conversations become awkward. |
| Burnout | A 400–730 hour project is 3–5 months of full-time work. No volunteer sustains that pace alongside their professional and personal obligations. |
Recommendation
Engagement model
Engage Br. Sabeel Ahmed's team — $11K–$19K vs. $25K–$59K market rate
At 55–68% below commercial market rates, with an established vendor relationship, proven technical capability, and an understanding of the Muslim community that no other option can match — this is the strongest choice across cost, risk, timeline, and cultural alignment. Formalize the engagement with a scope document based on this proposal, defined milestones, and a payment schedule tied to deliverables. Supplement with community volunteers for content production, testing, and subject matter review — but keep the engineering work on a paid, accountable track.
Other costs
| Item | Estimate | Frequency |
|---|---|---|
| Managed WordPress hosting (WP Engine, Kinsta, or similar) | $25–50/month | Ongoing |
| Search plugin or service (SearchWP or Algolia) | $0–100/year | Annual |
| SEO plugin (Yoast or Rank Math Pro) | $0–100/year | Annual |
| Image optimization service | $0–50/year | Annual |
| Forms plugin (Gravity Forms or WPForms) | $60–250/year | Annual |
| Professional photography (optional) | $500–1,500 | One-time |
| AI assistant — LLM API costs (Claude or GPT) | $50–200/month | Ongoing (usage-based) |
| AI assistant — vector database hosting | $0–20/month | Ongoing |
| AI assistant — chatbot platform (if using managed solution) | $50–300/month | Ongoing (optional — reduces dev effort) |
| AI assistant — initial development (RAG pipeline, widget, guardrails) | $3,000–8,000 | One-time (Phase 5) |
Execution
Risks & dependencies
What could slow, stall, or derail this project — and mitigations.
High risk
Organizational buy-in for "Visit Us" as a top-level nav item
This is a statement about IAR's identity — "this masjid is for everyone, not just the people already here." If leadership sees the site as primarily for the existing community, the architecture collapses. Mitigation: Frame as hospitality and audience service, not any single committee's agenda. Present audit data showing user-journey failures across multiple audience segments. Execute Phase 1 cleanup first to demonstrate credibility before proposing the rebuild.
High risk
Developer availability and capability
The build requires a developer comfortable with custom WordPress theme development without Elementor. If using a volunteer, their availability may be unpredictable. If hiring, the selection process can take weeks. Mitigation: Begin developer search in Phase 2 immediately after proposal approval. Have backup options identified. Use this proposal as the specification document.
Medium risk
Committee coordination on shared content
The new site requires a unified information architecture across all committees. If each committee insists on its own section with its own logic, the IA fragments. Mitigation: The web working group must establish and enforce a shared content model. This proposal provides the model — the working group's job is alignment, not redesign.
Medium risk
Content production timeline
Six new pages must be written before launch. The Content lead owns most of them. If competing priorities delay content, the build waits. Mitigation: Content production begins in Phase 2, in parallel with architecture approval — not sequentially after it.
Medium risk
Hosting environment unknown
The current hosting provider has not been confirmed. If it lacks staging support, migration to a better host adds time and cost. Mitigation: Identify current host immediately (check wp-admin → Tools → Site Health → Info → Server, or check billing records). Migrate to staging-capable host if needed as first Phase 2 task.
Lower risk
Content governance adoption
Rules without enforcement are decorative. If nobody does quarterly reviews, the governance model is theater. Mitigation: Assign a specific person (not a committee) as web content administrator with authority to flag or unpublish stale content. Build automated review reminders into the CMS.
Dependency
Skyward Blue CRM development
Website forms must integrate with Skyward Blue. If the CRM development team's timeline doesn't align with the site build, form integration may launch with placeholder behavior (email notifications) before full CRM connection. Mitigation: Share form specifications with the Skyward Blue team during Phase 2 so they can prepare endpoints.
Proposed project leadership
The website has no accountable owner today. This rebuild — and the site's ongoing health after launch — requires a defined leadership structure. We propose a three-person task force, supported by the current IAR website team:
| Name | Role | Responsibility |
|---|---|---|
| Ali Zelmat | Project Manager | Day-to-day execution. Owns timeline, committee content coordination, stakeholder communication. Accountable for the project's delivery and the site's ongoing content health post-launch. |
| Taani Elimam | IAR Leadership Representative | Represents IAR executive leadership on the task force. Ensures alignment with organizational priorities. Facilitates approvals from the web working group and CEO. Provides governance oversight throughout. |
| Sabeel Ahmed | Technical Lead | Leads the technical build through his development team, supported by and coordinating with the existing IAR website team. Owns architecture decisions, development quality, staging/production deployment, and post-launch technical maintenance. |
This task force is supported by the current IAR website team, who contribute institutional knowledge, content migration support, and ongoing site administration. The model ensures single-point accountability (PM), executive alignment (leadership representative), and technical ownership (technical lead) — the three elements the current site has lacked.
What this proposal needs from leadership
Approval to proceed
Alignment on the architecture, audience model, and "many doors, one building" approach.
Budget allocation
Development with Br. Sabeel's team (below market rate) plus managed hosting.
Endorse task force
Authorize the three-person leadership team with authority to coordinate across committees and make implementation decisions.
Authority for Phase 1
Permission to begin emergency cleanup immediately while the full proposal is reviewed.
Full proposal available at: raleighmasjid.org/wrp
Includes interactive homepage mockup, technical specifications, committee engagement plan, CRM integration specs, event management workflow, centralized intake system design, and AI assistant specifications.
Execution
Release governance & post-launch maintenance
How changes move from development to the live site — and how the site stays healthy after launch.
Release & deployment workflow
To ensure the rebuild process remains controlled and predictable, all changes follow a structured release workflow. No direct edits will be made to the live production site outside of this process.
Sandbox environment
Development occurs in a sandbox environment isolated from both staging and production. This is where the developer builds, experiments, and iterates without any risk to the live site or the review environment.
Staging environment
Completed work is promoted to staging for review and approval by stakeholders before deployment. Staging mirrors production as closely as possible. All forms, integrations, and user journeys are validated here.
Deployment checklist (every release)
Verified backups of the production environment
Ordered deployment steps — code changes, configuration updates, and content updates applied in sequence
Cache clearing and environment validation
Post-release testing of critical user journeys (prayer times, contact forms, event display, search)
Rollback plan prepared for each release — rapid recovery if unexpected issues arise
Each release has a defined scope and a designated owner responsible for coordination across technical and content stakeholders. Once a release is prepared, its scope is fixed to prevent last-minute additions that increase risk.
Stakeholder update workflow (post-launch)
After launch, requests for new content or site updates follow the same structured process established during the build. Committees and teams submit requests through the centralized intake system. Each request is reviewed by the content owner and, where necessary, validated by technical or UX stakeholders. Approved changes are scheduled into defined release cycles rather than deployed ad hoc. This replaces the current approach where anyone with admin access can edit the live site at any time.
Post-launch maintenance model
The long-term success of the website depends on how it is maintained after launch. A structured maintenance model ensures continued performance, security, and content quality.
Technical maintenance
Regular updates to WordPress core, plugins, and security components. Updates are grouped into scheduled release cycles rather than applied individually, reducing risk. Performance monitoring against the sub-2-second target. Security scanning and patching.
Content maintenance
Quarterly content review cycles (monthly for high-traffic pages). Automated expiration flags for event pages. Page ownership enforced — every page has a named person responsible. Content audits to identify drift from governance standards.
Analytics & optimization
Ongoing analytics review to understand user behavior — which pages are visited, where people drop off, what they search for, which community segments engage most. Navigation and content adjustments based on data, not assumptions.
Training & documentation
Documentation for internal teams on content editing workflows, the event submission process, the intake system, and the governance model. Training sessions for committee chairs and program coordinators on how to submit content through the structured process.