Corporate website and catalogue

The corporate website is not a separate world; it is the system's outward-facing side. The product data, documents and contact forms on the site are fed from the system's own records.

Catalogue

Products are presented in a family → series → model hierarchy. Each model's technical specifications come from measurable fields (chapter 17) — which is why the comparison tables and filters really work.

Specifications shared across a series are gathered in a separate table. For a specification to count as shared in a series it must either be present in every member, or in at least two and at least half of them; those below that are not listed, and a badge says how many members it covers. Saying in how many models something is available, instead of "available on some models", changes the reader's decision.

Quote basket

Visitors put the products they are interested in into a basket; the basket is not a shopping cart but a quote list. It sits in the header as a badge, opens a drawer from the side when clicked, and the full list is shown on a separate page. From there the contact form opens in one click, with the products already filled in.

The drawer is deliberately a review step: it holds no form and no send button. The request is made on the full page.

Document centre

Datasheets, user manuals, software, EDS/ESI description files and firmware files are published here. Some files are too large to keep in the system (gigabytes); for those the record stays in the system and the bytes arrive through a redirect.

The content of published files is checked regularly: a link working does not prove that it delivers the right file. A record found unusable is not deleted but archived.

Selection guide

The visitor enters their need (load, speed, cycle) and motor suggestions come out. The engine is a pure calculation layer with two rules:

• The safety margin is written on the page; there is no hidden factor.
• Peak torque is deliberately not used, and if a value cannot be read the suggestion is refused — not guessed.

Languages

The site is published in Turkish and English. The language selector is in the top bar of every page; the chosen language is remembered on later visits too.

AI visibility

Some visitors no longer open the site at all: they ask an assistant their question and read the answer there. Whether your product appears in that answer depends not on how beautiful the page is but on whether it is published in a form a machine can read. The site has three separate surfaces for this.

llms.txt and llms-full.txt

Two Markdown files are published at the root of the domain:

Both are generated from the same catalogue the pages read. A hand-written summary silently goes stale the day a series is published and teaches the assistant a catalogue that no longer exists; that is worse than having no file at all.

Structured data with a single identity

Every page carries a schema.org graph. The important part is this: the company, the site and the catalogue are each defined with an @id, and pages refer to that identity.

Repeated company blocks without an identity are, for a parser, not the same company but an unknown number of companies with the same name; a single identity makes every piece of information on the page attach to the same company.

On product pages the technical specifications are published as additionalProperty — exactly the rows the page prints, not a separate copy. That is what an assistant needs to be able to answer "which drive takes 400 V three-phase".

A robots.txt open to answer engines

robots.txt calls more than twenty AI crawlers by name and allows them. A plain User-agent: * looks sufficient, but many crawlers read only the group that names them — and that group is also where we point to the address of llms.txt.

The same file closes stock core paths that do not belong to the site (/jobs, /events, /slides, /profile). They are removed from the sitemap too: a sitemap suggesting a non-existent job-posting page wastes crawl budget and makes an assistant summarising the site say "this company has a careers page".

Telling the search engine about a change: IndexNow

There are two ways for a search engine to learn that a page has changed: its crawler coming by again one day, or the site telling it. The second is the IndexNow protocol, and both sites do it: when a published product, series, news item or page changes, its address is written to a queue, and a scheduled job running every ten minutes sends the queue to api.indexnow.org. Bing, Yandex, Naver and Seznam read this protocol; so do ChatGPT search and Copilot through Bing's index. Google does not, and the handbook does not pass over that in silence.

Sending is not done inside the transaction that writes the record. If the network call were there, saving a product would depend on api.indexnow.org answering. A rejected batch stays in the queue, its reason is written and it is retried on the next run; a submission that silently disappears cannot be told apart from a working one from the inside.

Share cards

The card that appears when a product page's link is pasted into LinkedIn, WhatsApp or an e-mail comes from the og:* and twitter:* tags. Every page publishes a card carrying its own title, description and — on a product page — the product's photo. The values are the page's own <title> and meta description; since card and page are not written separately, they cannot drift apart.

What works has been measured

Three separate measurements published in 2026 (SE Ranking over 300 thousand domains, Ahrefs server logs of 137 thousand domains, the Princeton GEO study) say the same thing:

• llms.txt shows no measurable relationship with how often a site is cited; 97 percent of the files were never requested. The file is kept because it is cheap and useful for agents; but visibility is not expected from it.
• What really decides is third-party mentions: YouTube titles and transcripts, industry directories, review sites, LinkedIn. These cannot be written onto the site; the team does them.
• Self-contained answer blocks of 130–170 words carrying figures are what gets quoted per page; keyword stuffing does nothing.

That is why the site's machine surface invests in schema, answer blocks and IndexNow; llms.txt is an extra, not the foundation.

Motion

The pages have scroll-linked motion: cards rise as they enter the view, the hero background slides against the scroll, a reading-progress line runs under the header, and buttons lean a few pixels towards the pointer. Three rules apply: only opacity and transform move (layout never shifts), everything sits behind the prefers-reduced-motion query, and scroll-linked animation is layered with @supports — a browser that does not support it gets the earlier reveal-on-view.

Site accounts

Visitors can open an account. Three things are set up deliberately:

• Verification — an account is not fully enabled until its address is verified.
• Proof of consent — what the person consented to, and when, is recorded.
• Sign-up rate limit — against automated sign-up attacks.

portware.io: pricing and a self-service demo

portware.io sells the product; two of its pages serve sales directly.

Pricing (/pricing, /fiyatlar) explains the licence model: 10 USD per user per month, invoiced for one year at purchase, and the licence is perpetual; updates are an optional per-company package, custom development is priced per project, and hosting is rented from PORTWARE or installed on the customer's own server. The calculator on the page works out the first invoice from the number of users.

Demo (/demo) opens a PORTWARE database of their own for the visitor for 30 days: all applications, full rights, sample data, up to 50 users. The path:

1. Company name, full name, work e-mail, mobile phone and country. Disposable domains and domains that receive no mail are refused; personal mailboxes (gmail…) are accepted but flagged. For now only Türkiye, the Middle East and Europe: the chosen country, the phone's country and the connection's country are checked.
2. The link in the e-mail, then the SMS code sent to the phone. Both are required.
3. For a verified request a portal account is opened on portware.io (/my/demos); you follow your demo's status from there.
4. Your database is prepared and the login details arrive by e-mail.
5. Reminders 7 days and 1 day before the end; on day 30 the demo is frozen: the data is kept, and instead of the login a screen leading to the licence page appears.

A demo's duration can be extended; when moving to a licence, the demo database can be carried over as it is.

The ERP side of changes on the site

Removing a product from the site does not delete it, it archives it (chapter 4). Removal runs through a single field, and the lists, the product page, the sitemap, the selection guide and the price map are affected at the same time.