Web glossary

The words you will hear from any studio, ours included. Explained the way you would explain them to a friend: no jargon for its own sake, with an example where an example is honest. If a definition leaves you with a question, that is our failure — tell us and we will rewrite it.

Basics

Domain: The address people type into a browser.; A domain is olexastudio.com: the name people find you by. You rent it for a year or several and renew it each time; miss the renewal and the site disappears from the network even though the files are untouched. A domain is not tied to a contractor — it is registered to you and moves with you.
Hosting: The place where the site’s files actually live and its code runs.; The domain is the address; hosting is the building. Your site sits on someone else’s computer that runs around the clock and serves pages to whoever asks. It is also billed periodically — but unlike a domain, hosting can be swapped in one evening without visitors noticing.
Landing page: A single long page built around one action.; A landing page has no ten-section menu: it tells one story top to bottom and ends in one button — enquiry, call, purchase. It is built for a specific campaign or service. If you need a catalogue, a blog and several directions, that is a website, not a landing page.
Responsive design: The page rearranging itself for phone, tablet and laptop screens.; This is not a shrunken copy — blocks reorder, menus collapse, columns stack. Most visitors arrive on a phone, so that is where it must be checked, not on the developer’s large monitor. Responsiveness is not a paid extra: a page is either built this way or built badly.
Prototype: A black-and-white skeleton of the page, with no colours or images.; A prototype answers “what is on the page and in what order” before anyone argues about the shade of a button. Moving a block here costs a minute; in finished code it costs a day. That is why it comes before design, even though it looks unsellable.
UX and UI: UX is whether the path works; UI is how it looks.; UX is the route: how many steps to the cart, whether the next move is obvious. UI is the look: type, spacing, colour. Good UI on bad UX gives you a beautiful site nobody can use — the more expensive of the two mistakes.
Favicon: The small site icon on a browser tab and in bookmarks.; A detail you notice only when it is missing: without one, the tab looks foreign and gets lost among twenty others. iPhone needs a larger version separately, or “add to home screen” shows a grey square instead of your logo.
CMS (admin panel): The panel where you change text and images yourself, without a developer.; A CMS earns its place where content is alive: news, catalogue, prices. Where a page changes twice a year it only adds work and failure points — asking for an edit is cheaper. The question worth asking: what exactly will you be able to change yourself, and what will still need ordering.

Domain, DNS and certificates

DNS: The internet’s phone book: it turns a site name into a server address.; Computers speak in numbers, people in names; DNS translates between them. That is why changes here are not instant: providers and browsers keep the previous answer, so updates take anywhere from minutes to a day. It is also why a site move is planned rather than done at six on a Friday.
SSL certificate and HTTPS: The padlock in the address bar: it encrypts traffic between visitor and site.; Without a certificate the browser shows a “not secure” warning and half your visitors leave before the first screen. Certificates are free and renew automatically — but automation fails quietly: an expired certificate takes the whole site down even though the site itself is fine.
Subdomain: A separate section on the same domain: app.site.com.; A subdomain costs nothing and takes a minute to create. You use one when part of the project lives its own life: a client portal, a blog on another engine, a test copy. Search engines mostly treat a subdomain as a separate site, so moving pages there for SEO reasons is a bad idea.
CDN: A network of servers serving copies of the site closer to the visitor.; Your site sits in one place while visitors are spread worldwide; a CDN keeps copies in dozens of cities and serves the nearest one. It speeds loading and absorbs attacks and traffic spikes. The side effect: faults now have two places to hide — the server and the CDN.
Redirect 301 and 302: An automatic jump from an old address to a new one.; A 301 says “moved permanently” and passes the old address’s accumulated weight to the new one. A 302 says “temporarily” and passes nothing. Mixing them up during a site move is the classic way to lose rankings built over years.
404 error: There is no page at this address.; A 404 is not a breakage but an honest answer: the address was mistyped or the page was removed. The problem starts when it returns a blank screen instead — or worse, the home page with an “all fine” code, which keeps non-existent pages in the search index for years.

How it works inside

Frontend and backend: Frontend is what you see in the browser; backend is what runs on the server.; The button, the font, the animation are frontend. Checking a password, saving an enquiry, calculating a price are backend, and invisible. “Move the button up” and “add a field to the form” cost differently precisely because they live on opposite sides of that line.
Database: Where the site stores enquiries, products and users.; Page text can live in files, but everything created while the site runs — enquiries, orders, messages — lives in the database. Losing it hurts more than losing code: code can be rewritten, a client’s message history cannot. That is what backups are for, and what restore tests are about.
API: How two programs exchange data with no human in between.; When the site pushes an order into your accounting system, pulls an exchange rate or sends mail through a provider — that is an API. What matters to a client: if your system has one, the integration takes hours; if it does not, someone has to invent a workaround, and that is where half the cost hides.
Git and repository: Code storage with a history of every change and a way back.; Every edit is recorded: who changed which line, when and why, and any state can be restored. The practical consequence for a client: the code should live in *your* repository, not a contractor’s personal folder — otherwise changing suppliers turns into archaeology.
Deploy: Moving finished changes onto the live site.; A change made in code is not yet on the site: it has to be deployed. Hence the common surprise — “I saw it was fixed, but the site shows the old one”: fixed, not deployed. Deploys are done deliberately and in working hours, so someone is around if it goes wrong.
Staging: A full copy of the site where changes are checked before the public sees them.; It looks and behaves like the live site but is closed to outsiders and to search engines. This is where broken forms and collapsed layouts get caught. Showing a client staging is normal; mistaking it for the live site happens too, which is why the address is labelled.
Backup: A snapshot of site and database you can restore from.; A backup nobody has ever restored from is not a backup, it is a hope. Two questions for any supplier: how often it runs, and when a restore was last tested. The second matters more — that is usually where empty archives are discovered.
Cache: A saved copy of a page served instead of building it again.; Cache is what makes a site fast and also why “I changed it and nothing changed”. The old copy may be held by the browser, the CDN or the server itself. So check a fix with a cache-free reload, and on the live site only after the cache was deliberately cleared.

Search and SEO

Indexing: Getting a page into the search engine’s database — without it, nobody finds you.; First a robot visits and reads the page, then decides whether to store it, and only then can it appear in results. Days or even weeks pass between publishing and showing up — that is normal and money does not fix it. The one lever is asking for a recrawl in the search console.
robots.txt: A file of rules for robots: where they may go and where not.; It sits at site.com/robots.txt and is read first. It is a request, not a lock: polite robots obey, malicious ones do not, so hiding secrets there is pointless. One mistake in this file can remove an entire site from search, which is why it is checked after every move.
Sitemap: A machine-readable list of every page, handed to the search engine.; A robot would find pages by following links anyway, but a sitemap speeds that up and surfaces pages few internal links point to. It must update itself: a hand-written list from a year ago promises the engine pages that no longer exist.
Title and description: The headline and blurb a person sees in search results.; This is your shop window in the results: people decide from it whether to click you or the next listing. Every page needs its own; identical ones site-wide are the commonest mistake, after which the engine invents headlines for you. Description does not affect ranking directly — it very much affects clicks.
Canonical: A marker saying “this is the main version of this page” for duplicate content.; The same product is often reachable at several addresses — with a filter, with a campaign tag, with and without www. To a search engine those are duplicate pages splitting the weight between them. Canonical says which one counts and pulls the weight back together.
hreflang: The link tying language versions of one page together.; It tells search: this page is Hebrew, its twin is Ukrainian, and here is the English one. Then an Israeli sees the Hebrew version in results, not the Ukrainian. The rule is strict: every version must point at all the others, or the whole set is ignored.
Backlinks: Links to you from other sites — the main external trust signal.; Search reads a link as a recommendation: whoever respected sites point to is worth trusting. Ten mentions in trade publications outweigh a thousand from directory dumps, and bought links now do more harm than good. It is the slowest and most expensive SEO lever — and the most effective.
Core Web Vitals: Three measures of page speed and stability that Google takes into account.; They measure when the main block appears, how fast the page answers a tap, and whether the layout jumps under your finger. This is not about a pretty test score but about a person on a phone on the train. The usual culprits are heavy images and third-party tracking scripts.
Structured data: Hidden markup explaining to a machine what the page contains.; A person sees “₪1,200” and knows it is a price; a machine has to be told separately. This markup is what puts review stars, prices and expandable questions into results, and helps AI assistants quote you accurately. One rule: the markup must match the visible text, or it counts as deception and is penalised.

Analytics

Google Analytics 4: A free counter: how many people came, from where, and what they did.; It installs in one line of code and counts from the day it is added — there is no retroactive data, so it goes in before launch, not after. On its own it shows only page views; to see enquiries, events must be configured separately.
Event: A recorded visitor action: a click, a submitted form, a downloaded file.; Page views count themselves; “a person submitted an enquiry” does not — it has to be defined. Without that, analytics honestly shows traffic and says nothing about meaning: a hundred visitors a day may be three enquiries or none.
Conversion: The share of visitors who did the thing the site exists for.; A hundred visitors and two enquiries is a 2% conversion rate. It is the site’s headline number: doubling it is usually cheaper than doubling traffic. Comparing your rate to someone else’s is pointless — niches and sources differ too much; compare with yourself a month ago.
UTM tags: A tail on the URL telling analytics where the visitor came from.; Without tags, visits from a newsletter, an ad and a messenger post merge into one faceless heap. With them you can see which post brought the enquiry. Tags go on the links *before* the campaign starts: they cannot be added retroactively.

Email

SPF, DKIM, DMARC: Three records proving that mail from your domain really is yours.; SPF lists who may write in your name; DKIM signs the message; DMARC says what to do with mail that fails the checks. Without them your mail lands in spam, or anyone can write as you. They are set once in DNS and last for years.
Transactional email: Mail sent in response to an action: order confirmation, login code, invoice.; People are waiting for it, so it must arrive in seconds and not in spam. Such mail goes through a dedicated service rather than a mailbox on your hosting: the service has sender reputation, delivery history, and shows what happened to each message.
Deliverability: Whether your mail reaches the inbox rather than the spam folder.; The treacherous part is that a mail server answers “accepted” even when the message is then quietly filed as spam or dropped. So deliverability is verified against a real mailbox, not a response code: sent, opened, seen.

Money, timelines, process

Specification: The list of what will be built — and, silently, of what will not.; A spec is not bureaucracy but a boundary: anything not in it is a separate agreement. That is exactly why the price is fixed together with it, not estimated before it. Read it carefully — the question “is this included?” is cheap before signing and expensive after.
Estimate and price range: A preliminary “from–to” figure based on what is known today.; A range is honesty, not evasion: until pages and integrations are described, nobody has an exact figure. The range must come with the assumptions it rests on — those are what explain why the price moves if one of them turns out false.
Milestone: A chunk of work with a visible result and its own deadline.; A project is split into milestones so progress is visible instead of “something is being done for two months”. Each ends in something you can look at: a prototype, a design, a working site at a test address. Payment is usually tied to them.
Release: The moment finished work becomes available to real users.; A first release is rarely “the whole site” — deliberately: better to launch a narrow working version and meet real people than to build blind for six months. Whatever did not fit is not lost; it becomes the next release’s list.
Support: Work after launch: updates, small fixes, reacting to breakage.; A site does not stand still even without you: browsers update, certificates expire, mail providers change their rules. Support is not “in case it breaks” but planned upkeep. The key question in the contract: how fast someone answers when it is down.

AI and automation

Language model (LLM): Software that handles text like a person: reads, writes, translates, summarises.; This is what sits behind ChatGPT, Gemini and Claude. For a business the point is not cleverness but the boundary: models are good where there is text and rules, and weak where someone must answer for the outcome. So they draft, they do not decide.
Prompt: The written instruction given to a model.; Answer quality depends on the instruction more than on the model: the same model given a vague request returns a vague answer. In production systems the prompt is not rewritten each time — it is tuned once and kept as part of the code.
AI agent: A model given tools and permission to act, not just answer.; An agent can open a page, read a file, write a row to a database by itself. That is both the value and the risk: it takes steps without asking. So production systems define what it may touch and leave irreversible actions to a human.
llms.txt: A short site guide written for language models.; What robots.txt is for crawlers, this is in plain words: a short account of what the site holds and links to its main pages. A model asked “who builds sites with a client portal” reads it faster than fifty kilobytes of markup, and quotes it more accurately.

Did not find a word someone used on you? Send it over — we will add it here and explain it to you directly.