Apex or www for your event website? Choose one canonical host

Choose the host before configuring redirects

The apex is example.org; www.example.org is a subdomain. Both can present the same event brand. Write down one public choice for invitations, QR codes, ticket emails, social profiles and the site’s own links. If a live event already has printed material and backlinks, treat a change of primary host as a migration rather than a cosmetic edit. Ask the web host which names it supports, how it attaches HTTPS certificates and whether it can redirect the alternate name.[1]

A practical reason to prefer www is that it is a subdomain and can use a conventional CNAME when a host supplies one. At the apex, ordinary CNAME records are prohibited, so the DNS provider may need an A/AAAA record, supported alias or CNAME flattening. This is a provider capability question, not an SEO score. If the host handles the apex cleanly and that shorter URL suits printed promotion, the apex is equally reasonable.[4][5]

Give both hostnames a complete route

Set DNS so both names reach a service that can answer HTTPS for each. Add both names to the hosting or redirect provider and confirm certificate coverage. DNS aliasing alone does not change the address bar or declare a search canonical. At the alternate host, configure an HTTP permanent redirect—usually 301 or 308—to the chosen host at the matching path and query string when relevant. Avoid sending every old article or event path to the home page.[2][4]

For example, if www.example.org is primary, https://example.org/events/autumn should lead directly to https://www.example.org/events/autumn. The alternate host needs a valid certificate too, so the browser can establish HTTPS before it receives the redirect. Test a deep event link and a ticketing link as well as the home page. If ticket checkout lives on a third-party domain, document that boundary instead of rewriting its URLs blindly.

Align search and publication signals

Use the chosen host consistently in internal links, XML sitemap entries, structured data, sharing links and each page’s canonical URL. Google treats a redirect as a strong canonical signal, but its systems may choose a different canonical when signals conflict; rel=canonical and sitemap entries are supporting signals. Never assume that adding a canonical tag substitutes for a usable redirect for people following the other host.[3][2]

Check localized event paths separately. A Spanish default page at / and an English page at /en may have their own canonical URLs and language annotations; do not send every alternate-host path to one language’s home page. Keep the same path and locale when redirecting between hosts unless there is a deliberate page-level migration.

Verify the entire redirect path

Record the four starting forms—http and https for both apex and www—and follow each to its final HTTPS URL. Check the response status, any extra hops, preserved path, certificate and displayed event content. A redirect loop or stale vendor target must be fixed before launch. In Google Search Console, inspect a representative page after publication; indexing and canonical selection are not instantaneous guarantees.[2][3]

The worksheet below turns the decision into an owner-assigned launch check. It keeps the DNS choice, HTTP redirect, certificate and content checks in one place, which is useful when an agency, ticketing provider and domain administrator have separate responsibilities.

Download the apex-versus-www decision and verification sheet (Markdown, English)