You register the trip once. Price, dates, itinerary and photos show up on the public site with nobody retyping anything, and the trip that has already come back goes offline on its own.
It is a real website, with its own address, that comes with OnWay and is served by the same records your team uses internally. It has a home page, a departures catalog, one sales page per trip, a landing page per destination, blog, gallery, testimonials, memories of past trips, contact, the referral program page and a trip preparation page for the passenger.
The difference from a site built outside is not the design: it is that this one reads your system. The price in the booking is the price on the page. The itinerary you built is the published itinerary. The site's second spreadsheet does not exist.
If your site is a separate place, you already know the three problems.
The group came back last week and the departure is still on the home page, indexed by Google, attracting people with nothing left to buy.
Someone adjusts the value in the system and forgets the site, or the other way around. The client shows up with a price the agency no longer charges.
Swapping a photo or publishing the new departure becomes a ticket to whoever built the site, and the departure goes live after the demand has already passed.
They come from the registered trip. They are read-only on the site, on purpose: there is no field to edit them there, precisely so two truths never exist.
Once the return date passes, the trip leaves the home page, the catalog, the destination landings, the sitemap and llms.txt, all at once. The cutoff is the return date, not the departure date, so the group still on the road does not vanish.
The trip that does not have a locked date yet remains published as a teaser of the next departure, instead of disappearing along with the expired ones.
Photos from completed trips become a memories section, which is social proof and indexable content at the same time.
As soon as the trip has a confirmed passenger and a locked date, its card and page get the confirmed departure badge. Seat counts are never published, neither full nor empty.
If your agency runs more than one brand, the storefront gathers the trips from all of them on the same site.
The site has an editing area with your team's sign-in, divided into three tabs.
Home title and subtitle, banner images, WhatsApp, Cadastur, CNPJ, the description Google shows and the agency's social media.
Theme, page address, public summary and description, highlights, what is included and what is not, photos and the publish button. Dates and price are not edited here, because they come from the system.
Title, address, summary, cover image, the markdown text, tags, author and the description for Google, with publishing controlled by you.
The site is born in Portuguese and can gain a Spanish version under the /es/ prefix. Seven fixed addresses already have that version: the home page, about, contact, privacy, terms, the departures catalog and the blog index. Each trip and each post gets the Spanish address when you fill in the translation, field by field, in the same editor.
The translation is done by hand, and that is a decision, not a deadline limitation: nothing automatic touches price, date or itinerary. The fields you can translate for a trip are name, theme, destination, summary, description, highlights, what is included, what is not included and the day-by-day itinerary, matched by day and never by list position.
And what happens when the translation does not exist: the /es/ address of that page returns 404, stays out of the sitemap and has no hreflang. Portuguese is never served under /es/. A trip with only the name translated and the body in Portuguese does not count as translated, because that is exactly what Google treats as a duplicated localized version: without name, summary and description in Spanish, the page is not born.
The hreflang is reciprocal, with self-reference and with x-default pointing to Portuguese, and the Spanish index is only announced to Google when it has at least one real item inside.
The sitemap is assembled on the fly from the published trips, posts and memories, so it never lags behind the site.
Travel agency, trip with offer and price, blog article, frequently asked questions and breadcrumb trail, all in JSON-LD.
Search robots and artificial intelligence ones are allowed in writing, and there is a text summary of the site for them.
Canonical address on every page and the right preview when the link is pasted on WhatsApp, Instagram or Facebook.
Each agency uses its own Analytics account and its own pixel, configured in the records.
Consent banner with Consent Mode v2: before acceptance, measurement runs without storing analytics or ad cookies, and only starts storing them when the visitor accepts.
The site has a contact form and, for sold-out trips, a waiting list with the trip already identified. Both have a bot trap: a hidden field that only an automatic form filler fills in, which causes the submission to be silently discarded. What arrives lands in a Site tab inside the CRM and goes to the pipeline with one click. Matching with an existing customer is done by phone number, never by name, so two people with the same name are not merged into a single record.
The newsletter is separate, with its own subscriber list.
So you can decide based on what exists, not on what would sound better.
There is no cart, checkout, or payment on the site. Every conversion path ends in a WhatsApp conversation, which is where excursion sales actually close today.
The site is born at an OnWay address. Pointing the domain you already bought is a setup we do, not a button in the panel.
Your agency's visual identity is put together with us during onboarding, not by a color picker inside the editor.
Two addresses live, served by the records each agency's team uses internally.
Curation of group trips departing from Porto Alegre. Catalog of departures, memories of past trips, and a blog.
A tour operator from the same family, with its own website and address, powered by the same system.
The agencies' profiles are in the footer of their websites, and are also included in the structured data that Google reads as the brand's official profiles.
It is where the lead that arrives through the site goes, with the pipeline and history of each person.
After the sale, the customer follows the trip, payments, and photos in their own portal.
The referral page on the site is the public front of the program that runs in the system.
It comes with it. It is not an outside-built site that talks to the system: it is served by the same records your team uses internally.
No. Price, dates and itinerary come from the registered trip and do not even appear as an editable field on the site, precisely so two truths never exist. What you write on the site is the sales copy: summary, description, highlights, what is included, what is not included and the photos.
It leaves the whole site on its own: home, catalog, destination landings, sitemap and the text file that artificial intelligences read. The cutoff is the return date, not the departure date, so the group still on the road stays published. A departure with date to be confirmed does not vanish: it stays live as the next departure.
Yes, under the address that starts with slash es. Seven fixed addresses already have that version: home, about, contact, privacy, terms, departures catalog and blog index. Each trip and each post gets the Spanish version when you fill in the translation in the editor.
No, and that is a project decision. Nothing automatic touches price, date or itinerary. The translation is filled in by hand, field by field, in the same editor.
The Spanish address of that trip returns 404, stays out of the sitemap and has no hreflang. Portuguese is never served under the Spanish prefix. A trip with only the name translated and the body in Portuguese does not count as translated: without name, summary and description in Spanish, the page is not born.
No. There is no cart, checkout or payment on the site. Every conversion path ends in a WhatsApp conversation, which is where excursion sales close today.
To a Site tab inside the CRM, from where it goes to the pipeline with one click. Matching with an existing customer is done by phone number, never by name, so two people with the same name are not merged into a single record.
Yes. The site is born at an OnWay address and pointing your domain is a setup we do during onboarding, not a button inside the panel.
Not through a theme picker. The agency's visual identity is put together with us during onboarding. What you change on your own, whenever you want, are the home images, the texts and the photos of each trip.
Bring two or three departures you are selling right now, and we will show you what they would look like published, with price, itinerary, and photos pulled from your records.
I want my agency's website Back to home