A wedding musician site only works if couples can find it. The previous page had no meta description, no Open Graph tags, no canonical, and no structured data. To Google it was a name and a phone number floating in an empty room. The first decision was to treat SEO and schema as the foundation of the build rather than a pass at the end.
The homepage carries seventeen JSON-LD blocks. Each one answers a specific question Google asks when it tries to understand a local service business. LocalBusiness and MusicGroup establish the dual identity, a service business that also performs as an artist. Person ties Julie to her ISNI, MusicBrainz, Spotify, and Apple Music identifiers so search engines treat her as the same entity across the open web. Eight separate Service entries describe what she actually offers, from solo ceremony violin to the Soul Shades duo to beat licensing. Event entries cover fourteen confirmed upcoming bookings with town-level locations and performer references. Review entries carry ten verbatim five-star testimonials with an AggregateRating derived from the actual count, never fabricated. FAQPage covers the eight questions that come up in every booking call. VideoObject entries surface the five performance clips for Google video search.
The site also runs sixteen regional and venue-specific pages (NYC, Long Island, Westchester, Hudson Valley, Northern NJ, Central NJ, Fairfield County, plus ten featured venues like Oheka Castle and Tappan Hill Mansion). Each one has its own canonical, its own H1 keyed to the search query a couple would actually type, and its own internal link path back to the homepage and the booking form. The homepage links out to all of them through a Featured Venues block, so authority flows downstream and a couple searching for a specific venue lands directly on the matching page.
One thing I refused to do, fabricate review counts. The AggregateRating block is built from the ten Review entries that actually exist on the page, with the rating math done by hand. If the count is ten, the JSON says ten. The Google Business Profile review count gets added later when there is real data to point at. Schema markup is a contract with Google and once you break it with fake numbers you lose the rich result, sometimes permanently.
The hardest part of booking a wedding musician is the music decisions. Couples land on a violinist's site, fall in love with the idea, then realize they have to pick a processional, a recessional, a unity moment song, and a first dance before they can even ask for a quote. Most sites push that decision off to email, which means days of back and forth before Julie can give a number. The decision here was to let couples build the ceremony before they ever send the inquiry.
The repertoire page at /wedding-ceremony-songs/ lets a couple pick a song for each ceremony moment from a list of 200+ tracks Julie actually plays. They can also add custom songs that fall outside the repertoire, with a clear note about the lead time and the fee. The full draft saves to localStorage under one namespaced key. When the couple opens the inquiry form on any page, a banner appears with a summary of what they picked and a checkbox asking if they want to attach the draft to this inquiry. Default is on.
/wedding-ceremony-songs/ and selects songs for processional, recessional, unity, first dance, parent dances. Each pick saves to localStorage under julieschatz.ceremony.v1.MutationObserver watches the drawer for the .active class. When it appears, the draft is read from localStorage and rendered inline as a summary banner.ceremony_selections field before the form handler reads FormData. Order matters here, capture phase runs before the bubble-phase hardened-form handler.MutationObserver watches for the success state replacing the form. Validation errors, disposable email rejection, and network failures all leave the draft intact so the couple does not lose their work.The point of the cross-page state is the asymmetry of effort. A couple spending fifteen minutes on the repertoire page has invested in the booking. The form should reflect that investment, not ask them to start over. The point of the conditional clear is trust. If a couple's submission bounces because of a network blip, their selections need to be there when they retry. Anything else feels like the site does not respect the time they put in.
A smaller decision sits inside this flow. The inquiry form is hardened against bots: a honeypot field, a four-second time-trap, a disposable-email blocklist of seventy domains, a minimum message length, and Formspree as the actual transport. None of that was the interesting work. The interesting work was figuring out how to wire it together without breaking the legitimate path. The disposable-email check exempts privacy-focused providers like Proton and Tutanota because real couples use those. The time-trap is set to four seconds because under that is bot territory but above that is plausible human behavior. Every gate has a calibration choice behind it.
Two weeks is short for a site this layered. The reason it worked is that I treated SEO, schema, and the booking flow as the same problem. A couple finds Julie through search, lands on a page that loads fast and tells Google what it is, builds their ceremony, and submits an inquiry with the picks already attached. Each step removes friction from the one before it. The editorial design language sits on top of all of that, but the design only gets to do its job because the foundation underneath it is doing its job too.
Visit the live site ↗