SEO for a tourist-pass platform that lives in JavaScript
Istanbul Welcome Card sells the city in a few taps — passes, museum tickets, Bosphorus cruises, airport transfers, tours — under the promise see more, pay less. But it is a client-rendered single-page app, the kind of site search engines have to work hardest to read, sitting on top of a deep, high-intent commercial catalogue. Logic Grid Studio ran the SEO: making the JavaScript platform crawlable and indexable, and tuning the catalogue so it shows up for the Istanbul-travel searches that actually turn into bookings.
The situation
Istanbul Welcome Card is a tourist-pass and booking platform built on a simple pitch — see more, pay less — and a genuinely deep catalogue behind it. There are cards and passes (Go Pass, Premium, Classic, Deluxe, the Istanbul Museum Pass), combos, public-transport passes for one to seven days, museum tickets and tours for Topkapi, Hagia Sophia, the Basilica Cistern and Dolmabahce, Bosphorus cruises, airport transfers from both airports, experiences and nightlife, workshops and walking tours — a full marketplace of things to book before and during a trip, well-reviewed across hundreds of ratings. The catch is how it is built: it is a client-rendered single-page application, the kind of JavaScript site where the content only appears after the browser runs the app. That is exactly the kind of site search engines have the hardest time reading — and for a commercial platform whose every page is a thing someone is actively searching to buy, being hard to read in search is the same as being hard to sell.
Why they came to us
SEO for a platform like this is not a content-tweak; it is technical, on-page and architectural at once, and the technical part comes first because of how the site is built. A client-rendered single-page app hides its catalogue behind JavaScript: if a search engine cannot reliably render and index those product pages, none of the on-page or content work matters, because there is nothing for it to rank. On top of that sits the commercial reality — every category is a high-intent, transactional search (Istanbul museum pass, skip-the-line Hagia Sophia, Bosphorus dinner cruise) where the competition is fierce and the visitor is ready to book — so the pages have to be both readable by a crawler and tuned to match exactly what a traveller is typing. And the catalogue is wide enough that it needs an architecture, not just good individual pages. Istanbul Welcome Card needed a partner who could take all of that on together — the rendering and crawlability problem, the commercial on-page problem and the catalogue architecture — rather than a content SEO who would optimize pages a search engine could not even see.
Constraints
The defining constraint was the build: a client-rendered JavaScript single-page application, where the catalogue is painted by the browser rather than served as ready HTML. Everything downstream depended on making that reliably crawlable and indexable, in place, without rebuilding the platform the business runs on. The work also had to respect commercial intent end to end — this is a booking platform, so SEO that brings the wrong traffic or buries the bookable pages is worse than useless; the pages that rank had to be the pages a ready-to-buy traveller actually wants. The catalogue is broad — ten distinct booking families, from passes and museum tickets to cruises, transfers, nightlife and workshops — so the optimization had to hold across all of them and keep them from competing with one another in search. And it had to run on the live platform, multi-currency and multi-language as it already was, preserving the product catalogue, the URLs and the bookings that were already coming through.
What we owned
Logic Grid Studio owned the SEO of the platform end to end. The first and hardest part was technical: making a client-rendered, JavaScript single-page application crawlable and indexable, so that search engines can actually reach, render and understand the catalogue instead of seeing an empty shell — the foundation everything else stands on. On top of that we owned the on-page optimization for commercial intent: tuning each booking family — passes, museum tickets and tours, Bosphorus cruises, airport transfers, experiences, workshops, walking tours — so its pages line up with the high-intent, transactional searches a traveller actually makes, the queries that end in a booking rather than just a read. And we owned the catalogue architecture: structuring and internally linking ten distinct booking families so they reinforce rather than cannibalize each other in search, and so the platform reads to a search engine as one coherent, crawlable tree of products. All of it was done on the existing live platform — multi-currency, multi-language, fully booking-capable — with the catalogue and the URLs preserved.

Our approach
We started where the site is hardest to see — the rendering. Because the catalogue lives inside a client-rendered single-page app, the first job was to make sure search engines can reliably render and index the product pages, so that the on-page and architectural work has something real to land on; on a JavaScript platform, crawlability is not a finishing touch, it is the foundation. With the catalogue made readable, we worked the commercial layer: every booking family is a transactional search with a buyer at the other end, so we tuned the on-page signals to match the exact intent behind queries like an Istanbul museum pass or a skip-the-line ticket, lining the right page up with the right search. Then we structured the catalogue as an architecture rather than a pile of products — internally linking the ten booking families so authority flows sensibly and they stop competing with each other for the same terms — which is what the information-architecture view of the platform makes concrete. Throughout, we optimized the live platform in place: it is a working, well-reviewed booking business with real URLs and real revenue, so the discipline was to make what existed findable and sellable, not to rebuild it.
The outcome
Istanbul Welcome Card went from a JavaScript platform that search engines struggled to read into a catalogue built to be crawled, indexed and found for the searches that matter. The hardest barrier — a client-rendered single-page app that hid its products behind JavaScript — was addressed first, so the platform is now reachable and understandable by search engines instead of presenting them an empty shell. On top of that foundation, the on-page work lines each booking family up with the high-intent, transactional searches a traveller actually makes, and the catalogue architecture connects ten booking families into one coherent, crawlable tree where they reinforce rather than cannibalize each other. For a platform whose every page is a thing someone is actively trying to buy, that is the difference that counts: the products are now positioned to be found by the travellers already searching to book them — and all of it was done on the live, multi-currency, multi-language platform, with the catalogue and the revenue it was already earning left intact.
Let's scope your next system together.

