What a small nonprofit website needs before launch.

Explain the mission, who benefits, and where the work happens in plain language. Publish the organization’s approved name, leadership or team information, and a contact route someone actually monitors. State service hours, a public address or service area where appropriate, and how visitors can ask about access needs.

Use approved program evidence, reports, and photographs with permission. Date information that can become stale and distinguish delivered work from future plans. Do not publish participant details or private donor information to make an impact page look more convincing.

What about 501(c)(3) website requirements? A launch checklist does not establish legal compliance. IRS public-disclosure guidance explains requirements to make certain annual returns and exemption applications available for public inspection and copying. Have the person responsible for your filings confirm which documents and disclosure rules apply, then decide how the website will help people find the approved information or request it.

Ready when: Mission, program evidence, organization details, contact routes, and approved transparency information are current and assigned to an owner.

For each program, record its name, purpose, audience, location or delivery format, availability, and next step. Include eligibility and costs when they apply and are approved. If a program is not accepting inquiries, say so. Give staff a way to retire an old date without leaving a broken page.

The Domino Affect public site organizes its work into three program areas: youth cohorts, re-entry bags, and family and community support. Those are concrete starting points for page structure, rather than one broad paragraph about impact.

Ready when: Every published program has current details, an approved owner, and a clear next step.

Ask only for what staff need for the first conversation. Separate an expression of interest from placement, screening, or a confirmed shift. Agree where submissions arrive, who responds, and how that person records the next step. If nobody can cover the inbox during leave, the process is unfinished.

Before launch, use an agreed test submission to check receipt and confirmation. Review the error state as well: a visitor should know when a form did not send and have a practical alternate contact. Do not assume that a successful button click means staff received anything.

Ready when: A volunteer test inquiry reaches the right owner and has a defined follow-up process.

For each current event, check the date, start and end time, time zone when relevant, location or online format, audience, cost, registration deadline, and access information. Explain whether someone must register and what happens next. Put important details in page text instead of only on a flyer.

Test registration with the approved tool and confirm who handles questions, changes, or cancellations. After an event, remove obsolete signup prompts and retain useful summaries or photographs only with permission.

Ready when: Event details and registration work, questions have an owner, and past events no longer invite obsolete signups.

Use a narrow screen to find a program, reach contact information, follow the donation link, and start a volunteer or event inquiry. Check that navigation opens, text is readable, buttons are easy to select, and forms do not hide behind the keyboard. Repeat the essential path on the external giving or registration page.

Look for slow or oversized photographs, content that jumps while loading, horizontal scrolling, and documents that are difficult to read on a phone. Test form errors and the success message, not just the first screen. Keep an alternate contact route available if a tool fails.

Ready when: The main visitor tasks, external destinations, form errors, and confirmations work on narrow screens.

Inventory forms, analytics, embedded media, donation tools, and email subscriptions. For each, identify the information collected, where it goes, who can access it, and how long it is kept. Keep sensitive participant stories and case information out of a general website inquiry.

Write privacy information that describes the tools and behavior in use. Decide how consent choices work before adding optional tracking or embeds. The organization should approve the collection and retention decisions, including any requirements specific to its services and audience.

Ready when: Forms, tracking, embeds, access, retention, and privacy copy have been reviewed together.

Record who controls the domain, code, hosting, content, and connected accounts. Keep renewal and recovery contacts current. Make sure the organization can obtain an export or handoff when needed, and agree which ongoing tasks belong to the care provider.

Confirm permission for photographs, logos, quotes, and participant stories before publishing. Identify who approves corrections and removal requests. Keep the approved originals and the source of important claims together so the next staff member does not have to reconstruct them.

Ready when: Domain, code, content, assets, renewals, and access responsibilities are documented.

Assign a person to check program availability, event dates, contact details, donation destinations, and important forms. Review time-sensitive information when it changes and agree a recurring review for the rest. Record the review date and unresolved problems so the work survives staff changes.

Agree who manages hosting, software updates where applicable, monitoring, account recovery, domain renewal, and backups or recovery arrangements. Separate routine content changes from new features and clarify how staff request help. Ongoing care should have a defined scope and budget, rather than being assumed to come with the build.

Ready when: Content reviews, technical care, renewals, recovery arrangements, and support requests have named owners and an agreed budget.

Before changing the domain, review the agreed pages, redirects, links, forms, mobile layout, account access, and search settings. Identify who approves launch and who can restore the prior version. Record what remains open and whether it prevents the public site from working.

After launch, check the live domain and the important visitor paths again. Give the team a short handoff with editing instructions, support contact, renewals, routine care, and the next review date. Launch is complete when the public paths work and the responsibilities are understood.

Ready when: Launch approval, live checks, handoff, support, renewals, and the next review have named owners.