Ultra-fast hosting for websites and online shops

Domain — Your address on the internet

A domain is a string of characters that users type into their browser to visit your website — for example, gboost.pl. It sounds simple, but behind this simplicity lies an entire system that makes the internet work the way it does. Every website has its own IP address — a string of numbers like 185.234.67.12 — which identifies the server on which that site is hosted. The problem is that nobody remembers strings of numbers. Domains solve this problem — instead of typing in an IP address, you type in a name, and the DNS (Domain Name System) translates it into the corresponding numerical address and directs you to the right place. DNS is essentially the internet’s phone book — it works in the background, invisibly, but without it, the internet as a tool for everyday use simply wouldn’t function.

Domain registration is the process by which you reserve a specific name within a particular top-level domain — or TLD (Top Level Domain). A TLD is the suffix: .pl, .com, .eu, .shop and so on. Each of these suffixes has a different purpose and a different organisation managing its registry. .pl domains are managed by NASK, .com domains by Verisign, and newer extensions such as .shop or .online by specialised registrars. As the domain owner, you do not buy the domain outright — you lease the right to use a given name for a specified period, usually a year, with the option to renew. If you forget to renew the domain and someone else registers it, you may lose it permanently or have to buy it back at a multiple of the normal price from the person who has taken it over.

Choosing a good domain name is important both for branding and, indirectly, for SEO. From a brand-building perspective, the domain should be short, easy to remember, free of hyphens and numbers, and as close as possible to your company name or what you do. Hyphens and numbers in a domain name are a relic of the past — they look unprofessional, are harder to spell out over the phone and are more likely to cause typos. From an SEO perspective, there are many myths — one of the biggest is the belief that a domain with a keyword in its name automatically yields better rankings. Google has repeatedly confirmed that so-called EMDs (Exact Match Domains) are not prioritised as they once were, and websites with generic, dictionary-style domains may even be treated with greater caution by algorithms assessing content quality. Focus on a domain that represents your brand — not one that crams in keywords.

The domain extension — i.e. the aforementioned TLD — influences how the site is perceived by users and how it performs in search results. .pl domains are ideal for companies operating in the Polish market — Google treats them as a signal of local relevance and may prioritise them in results for Polish users. .com domains are the global standard, associated with professionalism and international reach — if you’re targeting a foreign market or simply want a domain that sounds familiar anywhere in the world, .com is a good choice. Newer extensions such as .shop, .online or .store may be worth considering if your preferred .pl or .com name is taken — but it’s worth checking whether the alternative domain has previously been used for spam or other malicious purposes, as such a history could negatively impact your search engine ranking.

A domain’s history is a topic rarely discussed explicitly during registration, yet one that can have serious consequences. If you’re buying a new domain — registered for the first time — you don’t have this problem. But if you’re taking over a domain that previously belonged to someone else, it’s worth checking its history using tools such as the Wayback Machine, Ahrefs or SEMrush. A domain that was previously used for spamming, selling prescription-free pharmaceuticals, generating artificial links, or other practices that violate Google’s guidelines may be ‘remembered’ negatively by the algorithms. In such cases, you may not be starting from scratch, but from a negative position — and remain unaware of this for many months. At GBoost, when registering or transferring a domain, we always verify its history so that you know what you’re getting into before you commit to the purchase.

A domain is also more than just a website address — it’s the foundation of your digital identity. You can base your company email address on the same domain (kontakt@twojafirma.pl instead of twojafirma@gmail.com), subdomains for different departments or projects (shop.yourcompany.pl, blog.yourcompany.pl) and the entire URL structure, which builds brand consistency across every communication channel. Customers and business partners take note of this — an email address on your own domain builds trust and professionalism in a way that no address on a free email server can match. It is an investment with a low cost and a disproportionately high return — both in terms of image and practical benefits.

SSL certificate — what does it encrypt and what does it protect against?

An SSL certificate is a technology that encrypts the connection between the user’s browser and the server hosting your website. In practice, this means that data sent in both directions — contact forms, login details, payment card numbers, addresses, passwords — is encrypted and cannot be intercepted by third parties. Without SSL, this data travels across the internet as plain text — anyone with access to the network between the user and the server could, in theory, read it. This isn’t a scenario from a thriller film — such attacks, known as man-in-the-middle attacks, are a real threat, particularly on open Wi-Fi networks that your customers use in cafés, hotels or shopping centres.

Technically speaking, SSL — or rather its successor TLS (Transport Layer Security), as SSL as a protocol is now obsolete, though the name has stuck — works on the principle of asymmetric cryptography. The server has a pair of keys: public and private. The public key is available to everyone and is used to encrypt data sent to the server. The private key, stored exclusively on the server, is the only tool capable of decrypting this data. Even if someone intercepts an encrypted message, without the private key it is useless — like a letter locked in a safe to which only the addressee has the combination. It is precisely this mechanism that makes HTTPS the standard for secure communication on the internet and that more and more systems, institutions and regulators require its use as a minimum.

A visible sign that SSL is in use is the green padlock — or simply a padlock — visible in the browser’s address bar next to the website’s address. For the average user, this is a simple signal: this website is secure. The absence of a padlock, and even more so the message “Connection is not secure” displayed by Chrome, Firefox or Safari, has exactly the opposite effect — it causes concern, reduces trust and very often results in the user closing the tab and looking for an alternative. Research shows that a significant proportion of internet users consciously choose not to make a purchase or fill in a form on a website without SSL. In a world where user trust is currency, the lack of a certificate represents a real loss of customers — not a hypothetical one.

Google took a clear stance on this issue as early as 2014, announcing HTTPS as a ranking signal. Since then, the weight of this signal has only grown — today, websites without SSL are actively flagged as unsafe, not merely unranked. In 2018, Chrome introduced the “Not Secure” label for all HTTP sites, regardless of whether they collect user data or not. This shifted the discussion from “is it worth having SSL” to “why don’t you have it yet?”. From an SEO perspective, an SSL certificate is one of the simplest technical signals to implement — and one of the few that offers simultaneous benefits for security, user trust and search engine rankings.

However, not all SSL certificates are the same — and this is a point that is often overlooked when only skimming the subject. Certificates are divided into three main levels of verification. DV, or Domain Validation, is the basic level — the certification authority checks only whether the applicant controls the domain in question. The process is automatic, takes a few minutes and costs from nothing (Let’s Encrypt) to a few dozen zlotys a year. This is a sufficient level for the vast majority of company websites, blogs and small online shops. OV, or Organisation Validation, goes a step further — the certification authority verifies not only the domain but also the organisation itself: its existence, registration details and address. The certificate details show the company name, which builds an additional layer of trust — particularly important in B2B, regulated industries or when dealing with corporate clients. EV, or Extended Validation, is the highest level — full legal verification of the company, used by banks, financial institutions, large portals and wherever user trust is critical. EV certificates used to display a distinctive green bar with the company name in the browser address bar — today, browsers have done away with this visual distinction, but an EV certificate still carries the highest level of verification and is visible when you click on the connection details.

The free Let's Encrypt certificate, which we install automatically in every GBoost hosting package, is a DV certificate — and for most of our customers, this is a perfectly adequate solution. It is automatically renewed every 90 days, so you don’t need to remember any deadlines or pay for renewal — the entire process is handled by us without any action required on your part. However, if you run a larger-scale online shop, a service for corporate clients, or operate in an industry where credibility and security are key selling points — it is worth considering an OV or EV certificate as a signal that sets you apart from the competition and builds trust right from the first point of contact with your website.

Web hosting and page speed — why does the server matter for SEO?

Website speed is one of those topics where it’s very easy to fall into the trap of looking for a solution in the wrong place. When most website owners hear that their site is loading too slowly, they immediately think of optimising images, caching plugins or changing the theme. And yes — all of that matters. But if the server hosting the site is overloaded, outdated or relies on slow hard drives, no amount of optimisation on the code or content side will unlock the site’s full performance potential. Hosting is the foundation — and just as you cannot build a stable house on a weak foundation, you cannot build a fast website on a weak server. This is the starting point, not a last resort.

Google measures website performance very specifically — through a set of metrics known as Core Web Vitals, which have been an official ranking factor since 2021. The three key metrics are LCP, CLS and INP. LCP, or Largest Contentful Paint, measures the time taken to load the largest visible element of the page — usually the main image or header. According to Google’s guidelines, a good result is under 2.5 seconds. CLS, or Cumulative Layout Shift, measures the stability of the page layout during loading — whether elements jump around the screen once the user has started reading or clicking. INP, or Interaction to Next Paint, is the latest metric, which has replaced FID — it measures the page’s responsiveness to user interactions, such as clicks or typing. All three metrics are linked to server speed, because even the best-optimised page cannot load quickly if the server takes a long time to send the first data.

The server’s first response — known as TTFB, or Time to First Byte — is a metric that clearly illustrates how much hosting affects the perceived speed of a website. TTFB measures the time from when the browser sends a request until the server begins sending the first data. On a poor, overloaded server or a server with HDD drives, TTFB can be several hundred milliseconds or more — by the time the browser receives anything to display, time has already elapsed which Google treats as a loss. On an NVMe server with the right configuration, TTFB often drops below 100–200 milliseconds, and the rest of the loading process — parsing CSS and JavaScript, rendering content — begins much earlier. It’s a cascade effect: one fast step at the start speeds up the entire chain of events leading to the page being displayed.

It is also worth understanding what a so-called shared server is in the context of performance and why the choice of provider is crucial here. On typical shared hosting, a single physical server simultaneously hosts dozens or hundreds of websites belonging to different clients. Resources — the processor, RAM, and disk bandwidth — are shared amongst everyone. In theory, everyone gets their own allocation. In practice, when a neighbouring website experiences a sudden surge in traffic — for example, due to an advertising campaign or a viral post — this can temporarily deprive other websites on the same server of resources. This phenomenon, commonly known as the ‘bad neighbour effect’, is a real problem with providers who cram too many customers onto a single server to maximise profits. The quality of shared hosting depends largely on how the provider manages resources and how many customers they actually host on a single machine — and this is usually not explicitly stated at the time of purchase.

However, page speed is not just a matter for Google and its algorithms — it is, above all, a matter for real users. Google research based on data from billions of sessions shows that when the page load time on a mobile device increases from one to three seconds, the likelihood of a user leaving the page rises by 32%. At five seconds — it’s already 90%. At ten seconds, you statistically lose over half of all visitors before they even see anything other than a blank screen. In a world where the decision to stay on a page or leave it is made in a fraction of a second, every millisecond has tangible business value. A slow website doesn’t just mean lower rankings on Google — it means actual lost customers who may have found you through an advert, a recommendation or organic search results, but never saw your offer because the server didn’t manage to display it in time.

Server location matters less than it used to — thanks to CDNs (Content Delivery Networks), content can be served from geographically distributed servers, closer to the user’s physical location. But the location of the main server itself still affects response times for local traffic. A server in Poland hosting Polish websites is usually a better option than a server in Germany or the US for a business operating locally — if only because the physical distance the data has to travel translates into network delay, known as latency. At GBoost, we use servers located in Poland, which, combined with NVMe drives and the right environment configuration, provides a genuinely fast starting point — without the need to purchase additional services or configure the cache layer on the client side yourself.

How do you choose the right hosting for your website?

Choosing a hosting provider is one of those decisions where it’s easy to get confused — there are loads of offers, they all sound similar, everyone promises “fast servers”, “99.9% uptime” and “24/7 support”, and the price differences between packages can be drastic without any obvious justification. The problem is that hosting is a service whose quality isn’t immediately apparent when you buy it — you only really notice it in day-to-day use, when the website works brilliantly or when it starts causing problems. That’s why, rather than being guided by price or a catchy advertising slogan, it’s worth knowing exactly what to look for and what questions to ask before making a decision.

The first and most important issue is the type of storage. We’ve already covered this in our general introduction to hosting, but it’s worth repeating in the context of making a choice — because many providers still sell hosting on first-generation HDD or SSD drives without explicitly stating this. Look for specific details: NVMe is now the standard you should insist on. If the provider does not specify the type of drives in the package specifications, you can assume that they are probably not the most modern solutions — because if they were, the provider would highlight this as a marketing selling point. This is not a technical detail for techies — it is the foundation of performance, which directly affects your website’s speed, Core Web Vitals and user experience.

The second issue is the resources allocated to the package — specifically, whether they are guaranteed or merely stated. A cheap offer may look tempting on paper: “unlimited disk space”, “unlimited bandwidth”, “unlimited databases”. The problem with the concept of “unlimited” in hosting is that nothing in the physical world is unlimited — a server has a specific disk capacity, a specific bandwidth, and a specific processing power. In practice, “unlimited” often means “until you actually start using a lot of resources” — at which point restrictions in the terms and conditions kick in, your account is suspended, or your speed is throttled. An honest provider gives specific figures: this many GB of storage, this much monthly data transfer, this many CPU cores, this much RAM. Specific parameters are a sign of transparency and usually give a better indication of the actual quality of service than the vague “unlimited”.

Another key factor is uptime — that is, server availability expressed as a percentage. Almost every provider claims 99.9% uptime, and that sounds great until you convert it into actual hours. 99.9% equates to just under 9 hours of downtime per year — which sounds acceptable. But 99% is over 87 hours, or more than three and a half days a year, during which your website may be unavailable. The difference between 99% and 99.9% is a world of difference, even though the figures look similar at first glance. It’s also worth checking whether the provider provides historical availability data — some hosting companies publish public server statuses and incident histories. If such data isn’t available, ask for it. If the provider can’t give a specific answer, that’s a red flag too.

Technical support is another aspect that significantly differentiates providers — and which is of paramount importance in emergency situations. The website stopped working at 10 pm on a Sunday, just before an important client presentation or immediately after launching an advertising campaign — and what then? If the only way to contact them is via a form promising a reply within 48 working hours, you’re on your own. A good provider offers real-time contact — live chat, phone or a quick email reply — and does so not just during office hours. It’s also worth paying attention to the language of support: English-language support for a Polish client shouldn’t be treated as a neutral fact — in a stressful technical situation, communicating in a foreign language via a ticketing system is an additional barrier. At GBoost, you’re in touch with people who know your project, speak Polish and give specific answers — they don’t just refer you to a knowledge base with articles from five years ago.

Equally important is the issue of backups. It’s a topic customers only think about when they need it, which is usually too late. Ask every potential provider: how often are backups taken, how far back are they stored, and is restoring data from a backup free of charge? Some providers take a backup daily and store it for 30 days — that’s a good standard. Others take a backup once a week and store only the most recent copy — that’s already a risk. There are also those who offer backups as a paid add-on, without including this in the basic package price. Losing website data without the ability to restore it from a backup is one of the most serious disasters a website owner can face — and it is entirely avoidable if you take care of it in advance.

Finally, it’s worth mentioning scalability — that is, the ability to upgrade your package as your website grows. Today you might need 5 GB and a single domain. In a year’s time — three domains, 25 GB and a dedicated email address for the whole team. A good provider allows for a smooth transition between packages without data migration, downtime or complicated procedures. A bad situation is one where you’ve outgrown your provider and have to find new hosting yourself, transfer data and start from scratch — often at the worst possible moment. When choosing a hosting provider, think not only about what you need now, but also about what you might need in two or three years’ time — and whether the provider you’ve chosen can deliver this without unnecessary complications.

Hosting security — backups, firewalls and what else?

Hosting security is a topic that most website owners treat as an abstract concept — until something goes wrong. A hacked website, encrypted files, malicious code injected to display pharmaceutical adverts, or simply a total loss of data with no chance of recovery — these are scenarios that sound like someone else’s story, until they happen to you. And then it turns out that the cost of neglecting security is many times higher than the cost of prevention. An e-commerce site with its shop down for several days, a service company without a working contact form in the middle of the season, a restaurant whose website displays spam instead of a menu — these are real business losses, not just a technical headache for a specialist to sort out. Hosting security isn’t just an IT department issue; it’s part of your business strategy.

The first and most basic layer of protection is a firewall — a network barrier that filters incoming traffic to the server and blocks connections deemed suspicious or malicious. A good hosting provider uses a server-level firewall that acts before any request reaches your website. Modern solutions include the so-called WAF, or Web Application Firewall — a firewall operating at the application level that understands the specifics of HTTP traffic and can distinguish a normal user query from an attempt at SQL injection, XSS attacks or vulnerability scanning by bots. WAF is a particularly important layer of protection for online shops and websites that collect user data — because attacks on web applications are now the most common vector for breaches, far more common than bypassing network security at a lower level.

Backups are a topic that has already come up when choosing a hosting provider, but it deserves a separate discussion in the context of security — because a backup is not only a safeguard against server failure, but also against human error, ransomware attacks and the consequences of hacking. Imagine that someone gains access to your WordPress admin panel and installs a malicious plugin that gradually modifies your website’s files over several weeks — so subtly that you don’t notice the changes as they happen. If your backup is only kept for 7 days, you may not be able to revert to a clean state prior to the infection. If the backup goes back 30 days — you have a chance. A good standard is daily backups stored for a minimum of 30 days, kept on a separate physical server or in a different location from the main hosting — because a backup on the same server as the data isn’t a real backup; it’s just a false sense of security.

Software updates are another layer of security that many people overlook — and which accounts for a huge proportion of successful hacks. WordPress, plugins, themes, PHP, databases — each of these components has its own vulnerabilities, which are regularly discovered and regularly patched by developers. The problem is that once a vulnerability is published, hackers very quickly create automated scanners that search the internet for sites with out-of-date software and attack them en masse — often within hours of the vulnerability being disclosed. A site that hasn’t been updated for several months is an open invitation. Good hosting should make updates easy — and ideally automatically update critical infrastructure components, such as the PHP version or database server, whilst informing the customer of the changes in advance.

Protection against DDoS attacks is something one mainly hears about in the context of large companies and institutions — but small and medium-sized websites are also sometimes targeted, often not as a target in themselves, but as victims of attacks aimed at the entire shared server infrastructure. A DDoS attack involves flooding the server with a huge number of fake requests, which overload its resources and prevent it from serving genuine users. Even if your website is not the direct target, it may suffer as a side effect of an attack on a neighbouring website on the same server. A professional hosting provider employs DDoS traffic filtering mechanisms at the network level — often in collaboration with external security providers — which allow such attacks to be absorbed and neutralised before they affect the availability of clients’ services.

Access management is a security aspect that lies entirely with the user, but a good provider should support this with appropriate tools. Strong, unique passwords for the hosting control panel, FTP, the database and the website’s admin panel are the absolute minimum. Two-factor authentication — or 2FA — should be available and enabled wherever the provider offers it. It is also worth restricting FTP and SSH access to specific IP addresses where possible, regularly auditing the list of accounts with server access, and removing those that are no longer needed — for example, after ending a collaboration with an agency or freelancer. The vast majority of website breaches are not the result of sophisticated technical attacks, but of simply using stolen or weak login credentials — and this can be prevented with relatively simple measures, without any technical knowledge.

Website monitoring and alerts are the final layer worth mentioning. Even with all security measures in place, it is worth knowing what is happening with the website in real time — whether it is accessible, whether the SSL certificate has expired, whether there have been sudden spikes in traffic suggesting an attack, or whether the server is reaching its resource limits. Some providers offer basic uptime monitoring as part of their package — but it’s worth supplementing this with external tools such as UptimeRobot or Better Uptime, which, regardless of the provider, check the site’s availability every few minutes and send an alert via email or SMS if the site stops responding. It’s a simple solution, often free, that allows you to respond to problems before a dissatisfied customer does by calling to ask why your website isn’t working.

A custom domain for your business email — how does it work?

A business email address on your own domain is one of those things that makes a huge difference to how your brand is perceived, yet costs relatively little. The difference between kontakt@twojafirma.pl and twojafirma.kontakt@gmail.com is immediately apparent to anyone who receives such a message — one says “we are a professional company”, the other says “we’re just starting out and haven’t got the basics sorted yet”. This may sound like an exaggeration, but in reality, an email address is one of the first signs of credibility that a potential client, business partner or journalist assesses before they even read the content of the message. In a world where first impressions are formed in a fraction of a second, such details have a real impact on whether someone replies or ignores you.

Technically speaking, a company email address on its own domain works via so-called MX records — Mail Exchange — which are part of the domain’s DNS configuration. An MX record indicates which mail server is responsible for receiving messages sent to addresses within a given domain. When someone sends an email to kontakt@twojafirma.pl, their email client first queries the DNS for the MX record for the domain yourcompany.pl, finds out which server to route the message to, and delivers it there. From the sender’s perspective, it looks like a normal email send — all the magic happens invisibly within the network infrastructure. Configuring MX records is a one-off task, but it must be done correctly — incorrect MX records are one of the most common causes of email deliverability issues, i.e. situations where emails either fail to reach recipients or end up in spam.

However, simply owning a domain is not enough to run an email service — you also need a mail server to handle the emails. Here, you have a few options. The first is to use the mail server built into your hosting package — most hosting packages allow you to create email accounts on your own domain directly from the control panel. This is the simplest solution, which in many cases is perfectly adequate for a small or medium-sized business. The second option is an external email server — the most popular being Google Workspace (formerly G Suite) and Microsoft 365 — which offer email on your own domain, but with the interface and infrastructure of Gmail or Outlook respectively. This solution costs a monthly fee per user, but provides access to a whole ecosystem of office tools and better email deliverability thanks to the reputation of Google’s or Microsoft’s infrastructure. The choice between these options depends on the size of your business, the number of users, and how intensively and professionally you use email.

Email deliverability is a topic that deserves a separate discussion, as it is far more complex than it seems. Sending an email from your own domain does not guarantee that it will reach the recipient’s inbox — anti-spam filters assess the message against dozens of different criteria along the way. The three key mechanisms that affect deliverability are SPF, DKIM and DMARC — all three configured via DNS records. SPF, or Sender Policy Framework, is a record specifying which servers are authorised to send mail on behalf of your domain. DKIM, or DomainKeys Identified Mail, is a cryptographic signature added to every message sent, which allows the recipient to verify that the email actually originates from your domain and has not been tampered with en route. DMARC, or Domain-based Message Authentication Reporting and Conformance, is a policy specifying what the recipient’s server should do with messages that fail SPF or DKIM verification — reject them, mark them as spam, or pass them through with a report. The absence of these records not only risks your messages ending up in spam — it also risks someone being able to send emails impersonating your domain.

The structure of email addresses within a company is another issue worth considering in advance — before you start handing out addresses left, right and centre without any system. The simplest and most commonly used format is imie.nazwisko@domena.pl — clear, professional and unambiguously identifying the sender. It’s also worth creating functional aliases: contact@, office@, invoices@, support@ — which, regardless of who currently holds a particular role, always reach the right person or group of people. Aliases are particularly useful when a company is growing and staff turnover is inevitable — a customer who previously wrote to kontakt@twojafirma.pl doesn’t need to know that someone else is now on the other end. A good email management system on your own domain allows you to create both full mailboxes and aliases that redirect to existing addresses — without the need to purchase an additional licence for each alias.

It is also worth knowing that your company’s email and website hosting may, but do not have to, be with the same provider. Technically, the domain, website hosting and email server can be split between different providers — everything is tied together via the appropriate DNS configuration. This makes sense, for example, if you want to use Google Workspace for email but a different provider for website hosting. In practice, however, for small and medium-sized businesses, keeping everything in one place is simpler to manage, easier to deal with in the event of technical issues, and does not require coordinating settings across several control panels.

 It’s a simple solution, often free, that allows you to respond to problems before a dissatisfied customer does by calling to ask why your website isn’t working.