A site that gets found, not one that looks finished
Under2 builds websites for businesses that sell travel. Every one of them is judged on the same thing: whether a stranger on a phone in another time zone can find it, read it, and reach a booking without giving up halfway.
Four kinds of site, four different jobs
An operator site, a DMC site, a destination site and a MICE site look almost identical in a design file and behave nothing alike once live. What separates them is who arrives, what they already know, and what they may do next.
Tour operator site
Sells departures. Every page ends in a date, a price and a way to hold a seat. Judged in bookings, not in visits.
DMC site
Sells to agents and partners, not the public. Needs credentials, sample programmes, ground capability and a short route to a human. A public checkout button is a mistake.
Destination site
Answers questions asked before anyone is ready to buy: when to go, how long, how to get there. It earns search traffic and hands it downstream.
MICE site
Sells capability to a corporate buyer comparing three suppliers against a deadline. Capacities, transfers and a proposal they can forward matter more than photography.
We have built all four inside our own group. The work page lists them and says plainly that those brands are ours, not third-party clients.
Why the sites we build carry everything themselves
Almost everything we deliver is static: pages are generated once, then served as plain files, with nothing assembled while the visitor waits. That is not a preference, it is three commercial arguments.
Speed on a phone in Europe, not speed on a laptop in your office
The person deciding whether to book your trek is often on a phone on a train, on two bars of signal. Every external thing a page reaches for is another lookup and another chance to stall: a font service, a tag manager, a stylesheet on a CDN. We serve fonts, styles and images from your own domain, and ship no third-party scripts unless you ask for one and accept the cost.
A page that renders in under a second on a mid-range phone converts better than one that takes four, and ranks better against slower competitors.
Hosting that does not get more expensive when you succeed
A static site is files. It runs on the smallest shared plan a host offers and does not fall over when a newsletter goes out. No process pool to exhaust, no database limit to hit, so in high season, when a dynamic site needs a bigger server, this one needs nothing.
Nothing breaks at three in the morning because a plugin updated
The most common way a travel website dies is not an attack, it is an update. A plugin ships a version, the automatic update runs, the enquiry form stops submitting, and nobody notices until Monday, when someone asks why leads dropped. A site with no plugins has no such Monday, and no admin login to attack either.
Forms still have to do something. Ours write the submission to a log file on your own server first, then send it to Lark and to email through Mailgun. That order is deliberate: if an outside service is down, the enquiry is yours.
Three branches of URL, and why mixing them costs you traffic
Every site we build has three branches, and a page belongs to exactly one.
| Branch | What the page does | What the reader is doing |
|---|---|---|
| Buy | A product with a date and a price — a tour, a package, a departure | Ready to commit, comparing two or three options |
| Place | A destination, a region, a venue city | Deciding where and when, not yet who to buy from |
| Understand | A guide, a comparison, a practical answer | Learning, and forming a view about who knows the subject |
The failure we are called in to fix is a site where the three are mixed. A destination page that also sells three packages. A tour page padded with two thousand words of regional history. A blog post repeating the tour page it links to. Each competes with the others for the same query, and the search engine picks one — usually not the one you would have chosen.
Split, every page has one job and one target query. The place page earns traffic and links down. The buy page stays short and commercial. The understand page catches the people who are not ready and keeps them on your domain.
If you cannot say in one sentence what a page should rank for and what it wants the reader to do next, it is two pages.
Structured data generated from the page, not typed beside it
Search engines read a tour page as a product: name, price, currency, duration, itinerary, availability. We generate that markup from the same source as the visible page, so the two cannot drift apart. Marked-up prices that no longer match the page are worse than none.
- Tour pages carry trip and offer markup, including the day-by-day itinerary
- Destination pages carry destination markup with region and coordinates
- Every page carries a breadcrumb trail, so the URL branch is legible to a crawler
- Guides carry question markup built from the questions on the page, not from a keyword list
Who writes the words
This decides the timeline more often than any technical question does. Three arrangements work and one does not.
- You write it. Fastest and cheapest, and it usually reads best, because you know why the boat leaves at six.
- You give us the raw material and we write it: interview notes, old brochures, the existing site, the answers you already type into emails all day. Most clients choose this.
- We write it from research alone. Workable for destination and guide pages, weakest for anything about your own operation, and we say so before quoting.
What does not work is starting the build and deciding later. A site full of placeholder text stays ninety per cent finished for six months. We ask for the content plan before the first template is cut, because a stalled website project has stalled here, not on code.
How long it takes and what actually slows it down
| Phase | Typical | What stretches it |
|---|---|---|
| Structure and content plan | 1 week | An undecided product list, nobody owning the copy |
| Templates and build | 2 - 4 weeks | Number of languages, custom booking behaviour |
| Content and images loaded | 1 - 2 weeks | Photography that does not exist yet |
| Review, redirects, go-live | 1 week | Old URLs nobody mapped |
Four to eight weeks from signed scope to live is realistic for an operator or DMC site when the content exists. Ranges are on the pricing page, and the reasoning behind what a travel website should cost is in the cost guide.
The two things that reliably add a month are photography and redirects from an old site. Neither is a development task, and both are found late.
When you should not hire us for a website
Three situations where we are the wrong choice, said in the first call.
- You want a brochure site with no booking, no enquiry handling and no search intent behind it. A design studio will do it better and for less.
- You need pages that change several times a day — live seat counts across a hundred products, hourly prices. That is work for a platform such as izBooking, not for generated files.
- You want everyone in the office editing anything in a visual editor with no review. We hand over a workflow your team runs, not a free-for-all, because that is how the URL structure above dies inside a fortnight.
If what you need is the booking layer rather than the site, start at booking integration. If the question is an app, read the app page first — the honest answer there is often no.
Send us the site you have now
A URL, what you sell, and which pages you think should be earning traffic. You get a written assessment and a range.
What travel operators ask us most
Can you improve our existing site instead of replacing it?
Often yes, and it is usually the cheaper useful step. If the site can be edited at template level we can fix structure, speed and the booking path without a rebuild.
If it sits on a locked platform that will not allow those changes, we will tell you that rather than sell a workaround that breaks at the next update.
Do we get a way to edit the site ourselves?
Yes. Content lives in structured files your team edits, and the site is rebuilt from them, so a mistake is visible and reversible rather than live instantly.
For teams that want a full visual editor we will connect one, on the condition that page structure and URLs stay under review.
Can the site run in more than one language?
Yes, and travel sites usually should. Each language gets its own URLs and its own translated content, cross-linked so a search engine knows they are the same page in two languages.
Machine translation left unchecked is worse than one good language, so we plan who reviews each language before the second one is added.
What happens to our search rankings when we move?
A mapped redirect from every old URL to its new equivalent is part of the build, not an extra. Rankings usually wobble for a few weeks and then settle.
The dangerous case is an old site whose URLs nobody has a list of. We crawl it and build that list before cutover, which is why the go-live week exists.
Read next
Tell us what you are trying to run
What you sell, what you use today, and what is breaking. You get a written answer with an approach and a price range - not a brochure.