From a one-page profile to a bilingual corporate site

An agency's own website is the first test of what it promises clients. So our first case study is our own site: we applied the discipline we recommend to clients to ourselves first, and documented the reasoning behind every decision here.

The starting point

We had a single HTML file. The company description, service headings and contact details all lived on one page; there were no sub-pages. Turkish and English content sat at the same address, switched by JavaScript.

That structure had two concrete consequences:

• There was exactly one page for search engines to rank. Eight distinct services competed through a single URL, and none could go deep on its own subject.
• The English content was invisible. Text hidden by JavaScript at the same address is not a separate page to a search engine; the English version could not rank on its own.

What we did

We gave each service its own page. All eight services now sit at their own URL with their own title and description. The rankable surface went from one page to eight.

We built a content pipeline. Articles and services are generated from markdown files; a single command rebuilds the pages, the homepage cards and the sitemap together. The page shell is read from one source, so a single change propagates across all 28 pages at once.

We moved the two languages to separate URLs. Every page has its own Turkish and English address, linked by hreflang, with x-default pointing to Turkish. The English URLs are in English too — /en/services/artificial-intelligence, for instance.

We chose static generation deliberately. Had the content loaded via JavaScript in the browser, the link preview bots at WhatsApp and LinkedIn would see no title and no image; every shared link would appear as a bare URL. Each page ships with its own og: tags already in place.

We set up analytics without cookies. Visitor behaviour and real page speed are measured, but no cookies are used and no persistent identifier is stored. That removed the need for a cookie banner and a consent mechanism. Had we chosen a cookie-based tool, we would also have had to build a privacy notice, consent management and a legal basis for cross-border transfer — a burden that would have outweighed the need to measure.

We completed the technical side. Domain and SSL, security headers, sitemap, robots.txt, organization schema, search engine notifications and a Google Business Profile.

Three bugs found along the way

We document these because what deserves telling is not that a project had no bugs, but that the bugs were caught:

• Duplicate <!DOCTYPE> — the page generator was adding a tag the template already carried. Browsers use the first and ignore the second, so nothing visibly broke; it was invalid markup nonetheless.
• A canonical pointing at a redirect — the English homepage was written as /en/ while the server redirected that to /en. Every place we told search engines "this is the real address" pointed at a redirect. Caught before Google had crawled the English pages.
• Internal links were not being translated per language — a link from one English service page to another landed on the Turkish version. The page body was inserted after the shell was processed, so it escaped translation.

All three were caught in verification steps and fixed. Verification is part of the work; "appears to work" is not an adequate standard.

Results

To be straight about it: the site has only just launched. Traffic and ranking data have not accumulated yet — which is exactly why the measurement was set up. Real numbers will be added to this table over time; we will not put estimates here before those numbers exist.

Services used in this project

Web Design & Software · Digital Media, Advertising & Social