How did we build our new website? A technical behind-the-scenes tour.

Our old website looked good, but it was one long page. It explained what we do, yet it could not answer a visitor's concrete question, such as "Can I get a cash report out of Netsis?" or "What should a website for an underfloor heating company look like?", with a dedicated page. That is exactly what search engines and AI assistants look for too: pages with their own address that give a clear answer to a clear question.

We summed up the goal of the new site in three sentences: every service, product, industry and case study gets its own page; every page describes itself correctly to both people and machines; and the site is a live example of everything we recommend to our clients. Below we walk through, step by step, how we reached that goal.

The new site in numbers

Architecture: no database, no plugins, no framework

Our first decision was not to install a content management system. The pages of a corporate website do not change often, and when they do, you need to know who changed what and when. So we kept each page as a single Markdown file, and all content lives under version control (git). Every edit is a record; undoing it is one command.

The engine that renders the pages is a lean PHP 8.3 application of about 1,300 lines:

• Single entry point: The server routes every address that is not a file to the application, which matches the address to a file in the content folder. The address /hizmetler/seo-ve-geo is rendered from the hizmetler/seo-ve-geo content file.
• Meaningful addresses without extensions: No .html or .php; reading the address tells you what the page is about. Addresses with a trailing slash (/) are permanently redirected to a single form.
• Front matter: At the top of each file are the page title, the search engine description, the intro sentence, the sort order and the page type. For blog posts, the date, category and related pages are here as well.
• A small markup language: Alongside headings, lists, tables and links, there are a few structures we added ourselves: lines starting with ?? are frequently asked questions and are reported to search engines as FAQ; !! is a highlighted box; [[children]] lays out the section's subpages as cards; [[tool:raporkur]] embeds an interactive tool in the page.

Having no database shrinks the attack surface and the maintenance burden considerably. Having no plugins removes the "an update came out and the site broke" problem. We discussed which websites this approach suits in our article on choosing an admin panel.

Content architecture: every paragraph has a page

We built the site's skeleton around the questions a visitor might ask:

1. Services: Each service page is a summary. Every main heading on it links to a separate subpage that goes deeper into that topic. For example, the "site in 10 days" paragraph on the corporate website page has its own page.
2. Products: Every feature and every ready-made report of IMFLEXI and READERP is a separate page. So someone searching for an "accounts receivable aging report" lands directly on that page.
3. Industries: For each of the 16 industries, how that industry's customers search, what the website needs to include and notes on regulations.
4. Case studies: For each project, what the site does, how it was structured and an analysis table, with the companies' own logos and real screenshots.
5. Blog: Guide articles in ten categories; each article links to the related service and industry pages.

To keep this many pages consistent, we prepared a writing guide: language and tone (plain, like a consultant, without exaggeration), the figures we may use, what we do not write (prices, unverifiable claims) and SEO rules. We used AI-assisted tools at the drafting stage; we checked every page against this guide, real data and our own experience, and removed every sentence we could not verify. We explain how we strike this balance in our article on content creation with AI.

Design: a visual language born from our logo

We derived the design from our logo: blue curves, an orange corner and navy text. On a white background we used soft color gradients, boxless lists and plenty of white space. Instead of our own slogans, the opening screen shows real screenshots of websites we have built.

• A single font family, hosted on our own server; no external font requests.
• CSS variables for the color and sizing system; a single stylesheet, no off-the-shelf design framework.
• Reduced motion preference: Visitors who turn down animations in their operating system do not see sliding and fading effects.
• Mobile and tablet: The menu, the assistant window and the tools are laid out separately for narrow screens. On tablets we use the browser's visible viewport information so that windows do not spill off the screen when the keyboard opens.

Speed: never loading what is not needed

The secret of a fast website is usually not adding something, but not adding it. The stylesheet is about 64 KB and the main script 16 KB; compressed, only a fraction of that is downloaded. No framework, no jQuery, no heavy library.

• Images load only as they approach the screen; screenshots are compressed JPEGs.
• The scripts for interactive tools load only on the page where the tool is.
• The search index is fetched in the background when the browser is idle, not while the page is opening.
• Server-side page rendering takes milliseconds; the first response of the home page is about 25 ms.

We covered Google's speed metrics in detail in our Core Web Vitals guide.

SEO: every page also describes itself to machines

Every page goes through the same checklist when it is rendered:

• Unique title and description: Titles stay within 65 characters and descriptions within 160; no duplicate titles.
• Canonical address: Every page has a single, permanent address.
• Structured data (Schema.org): Organization and local business information (address, phone, opening hours, founders, areas of expertise), breadcrumb, page, service, blog post and frequently asked questions. Details are in our Schema.org article.
• Sitemap: Generated automatically, with the real last-updated date of each address.
• Permanent redirects: Old site addresses redirect to their new equivalents with a 301, so value earned in search is not lost. We shared the checklist for this in our article on website redesign without traffic loss.
• Internal link network: Every page links to 3-6 related pages. An audit script that runs after every change looks for broken links, missing descriptions, duplicate titles and pages that are too short.

AI search (GEO): for ChatGPT, Gemini and Perplexity

Many people now ask their questions to an AI assistant rather than Google. Assistants compile their answers from sources that are clear, structured and trustworthy. So we prepared the site for these readers as well:

• llms.txt: A short summary of our company, its key facts and an annotated list of all pages. We explained honestly what it is and what its limits are in our llms.txt article.
• llms-full.txt: The entire content of the site in a single plain text file.
• A Markdown version of every page: Adding .md to the end of any address returns the page's plain text. So that search engines do not treat these versions as duplicate content, they are closed to indexing and point to the main page.
• An open door for AI crawlers: Our robots.txt file allows crawlers such as GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot and Google-Extended to read the content. We discussed the pros and cons of this decision in our article on AI bots and robots.txt.
• Entity consistency: The company name, address, phone number, founders and product descriptions are identical on every page and in every file. AI systems do not trust contradictory information.
• IndexNow: We can notify Bing of new or updated pages instantly; the Bing index is one of the sources behind many AI search tools.

A sharing image for every page

The image that appears when you share a page on WhatsApp or LinkedIn is called an OG image. On the old site every page used the same image. On the new site, each page's image is generated automatically on the server with the page's title, section and description; case study pages also include a screenshot of the site. The images are cached and refresh on their own when the content changes.

A small technical note: on the first try, the image library on the server drew Turkish characters as empty boxes. We solved it by converting the text into character codes. It was one more reminder that Turkish letters such as the dotless i, the s with a cedilla and the soft g need to be tested in every environment.

Tools for visitors: showing instead of telling

• READERP report builder: You can build your own ERP report in two minutes by dragging and dropping cash, receivables, revenue, stock and payroll blocks. The report you build goes to the contact form or the assistant with one click.
• IMFLEXI needs basket: You add e-commerce features to a basket. When you click "buy", what opens is not a card payment form but a short, fun brief that helps us get to know you.
• Smart search: Opens on every page with Ctrl+K (⌘K on a Mac) or the "/" key. It works regardless of Turkish characters (typing a word without its Turkish accents still finds the correctly spelled word), recognizes synonyms, and if it cannot find something, offers to pass the question to the assistant.
• Globya assistant: AI-powered and online 24/7. The "ask the assistant" links on pages open the assistant and send a ready-made question on that page's topic.
• Little surprises: A five-game arcade at the very bottom of the page, a hidden keyboard code and a few surprising touches. We leave it to you to find them all.

Measurement: seeing what works

We kept our existing analytics tool (Microsoft Clarity) and added meaningful events on top of it: phone and email clicks, form starts and submissions, which page the assistant was opened from, tool usage, searches and visits to case study sites. That way we can see which pages actually bring in business. Measurement runs only if the visitor has given cookie consent; without consent, no data is sent.

KVKK and security

• Cookie consent: Analytics loads only with explicit consent, and the reject option carries equal weight.
• Forms: A privacy notice link and a separate consent checkbox, bot protection (an invisible honeypot field, a timing check and verification) and a submission rate limit.
• Security headers: Content Security Policy (CSP), HSTS, and protection against framing and MIME type sniffing.
• Internal folders closed to the outside: Content sources and application files cannot be opened directly by address.

We describe how we see KVKK (Türkiye's Personal Data Protection Law) on our approach to KVKK page.

The switch: in one step, with nothing broken

We first prepared the new site for launch at a separate address, kept it closed to search engines and reviewed each section as a team as it was completed. When it was ready, we made the switch in one step:

1. The root address was pointed to the new site; the customer portal, client panel, admin panel and API were left untouched.
2. Old addresses were permanently redirected to their new equivalents.
3. The old site was not deleted; it was moved to a password-protected address, closed to search engines, that only our team can access.
4. The sitemap, robots.txt and llms.txt were refreshed.

We tested every step with an automated browser, taking screenshots at desktop, tablet and phone sizes. We applied to our own site the same method we recommend to our clients: "prepare without touching the current site, then switch in one step when ready."

What comes next

The site is not a finished job; it is a living resource. We will keep adding new case studies, new guide articles and updates to our products. We will look at the measurement data to see which pages need to explain things better.

If you are considering a similar redesign for your own site, take a look at our corporate website and SEO and GEO pages, or request a free preliminary analysis directly.