How requests, infrastructure and analysis are handled.

• 01 What happens after a request is submitted? It is reviewed first. Nothing is charged and no work starts at the point you send it.

  When you send the contact form, the request is stored so it can be read carefully. Sending it is the start of a review, not a commitment — no payment is taken and no work begins at this stage.

  How the review works

  The details you provide are read to understand three things: what is actually being asked for, whether any external provider is involved, and whether the work fits what Grau offers. If anything is unclear, it is raised before scope is confirmed rather than assumed.

  • The scope is defined in plain terms — what is included and what is not.
  • Provider needs (domain, hosting, SSL, server) are identified where relevant.
  • Payment details are prepared to be shared once the scope is confirmed.

  What you receive

  After the review you get a reply through the contact details you provided. That reply confirms the scope, any provider needs and how payment would work. Work begins only once the scope is agreed in writing — so there are no surprises about cost or coverage later.

• 02 Why infrastructure may involve external providers Domains, hosting, SSL and servers come from specialised providers; these items are arranged through them when needed.

  A website needs infrastructure to exist on the internet: a registered domain, a place to be hosted, a certificate for HTTPS and, for heavier work, a server. That infrastructure is operated by specialised providers. Arranging it through them is the normal, correct way to work — not a workaround.

  What the work actually covers

  This is not simple reselling. The value is in choosing the right option for the scope, configuring it correctly, aligning it with the rest of the setup, and handing it over cleanly so you keep control.

  Where the boundaries are

  Providers set their own rules, prices, account limits and maintenance windows. Outages, price changes and account restrictions come from them and are outside Grau’s control. Where a provider is involved, that is stated openly rather than hidden behind a single bill.

• 03 Domain, DNS and hosting responsibilities Domain ownership, DNS records and hosting are separate responsibilities. Settling them early prevents confusion.

  These three things are often spoken of together, but they are separate — and knowing which is which prevents most of the confusion that comes up later.

  Who holds what

  • The domain lives in a registrar account. Ownership and renewal stay with the account holder — you.
  • DNS records decide where the domain points: to the hosting, to email, or to other services.
  • Hosting stores and serves the website files. It can be with the same provider as the domain or a different one.

  A note on DNS changes

  DNS changes are not instant. When a record is changed, it takes time to spread across the internet — often minutes, sometimes longer. Migrations and go-lives are planned around this so the site is never left unreachable.

  When these items are arranged within a scope, the setup and the handover are documented, so control stays with you and nothing depends on remembering a verbal detail.

• 04 SSL setup and renewal scope SSL enables encrypted HTTPS. Setup fits inside a scope; renewal depends on the provider and certificate type.

  An SSL certificate is what lets a site load over HTTPS, with the padlock in the address bar. It encrypts the connection between the visitor and the server, and modern browsers expect it on every site.

  What setup covers

  Many hosting environments issue certificates that renew automatically. Where SSL is part of an agreed scope, installation and correct configuration are covered, and the site is verified to load over HTTPS without mixed-content warnings.

  About renewal

  Renewal behaviour depends on the provider and the certificate type. Certificates that renew on their own need no attention; a certificate that does not must be watched before it expires, otherwise the site will show a security warning. If ongoing renewal monitoring is needed, it is arranged as a separate scope.

• 05 Choosing the right VPS / VDS A virtual server gives dedicated resources for heavier work. It is provided through a partner chain and is self-run once purchased.

  Shared hosting is enough for most sites. A VPS or VDS becomes worth it when a project needs dedicated resources, specific software, or more control than shared hosting allows.

  What to weigh

  • Load: the expected traffic and workload set the size. Too small slows things down; too large wastes budget.
  • Location: a server closer to your audience feels faster.
  • Management: a managed plan includes provider-side upkeep; an unmanaged plan leaves administration to you.

  How it is provided

  A virtual server is provided through a partner chain. Selection, sizing and initial setup can be handled within scope, and access is handed to you. After that, running and securing the server is yours to handle unless a separate managed scope is agreed. Taken together with domain and hosting, more hands-on help can be arranged.

• 06 Migrating an existing website Moving a live site is planned so content, links and email keep working, with downtime kept short.

  Moving a website that is already live is mostly a matter of planning. The goal is simple: the visitor should notice nothing, and email should not break.

  How a move is prepared

  • The current site, its files, its database if it has one, and its email setup are reviewed first.
  • The move is prepared on the new environment and checked there before anything is switched.
  • DNS is planned for a short overlap, not a hard cut, because DNS changes take time to spread.
  • Access to the old provider is needed for a clean migration; anything that cannot be exported is noted in advance.

  If a site is on WordPress or a similar platform and the goal is to move away from it, that is treated as a rebuild rather than a copy — see the note on how sites are built.

• 07 What technical SEO can and cannot guarantee It improves structure, crawlability and measurement. It does not guarantee a search ranking.

  Technical SEO is the part of search optimisation that is actually within a site’s control: how it is built, how it is structured, and how it is measured. Done well, it removes the obstacles that stop a site being read properly.

  What it covers

  • Site structure, internal linking and crawlability.
  • Indexation signals and page metadata.
  • Correct measurement setup, so results can actually be seen.
  • Findings and fixes written up in a readable report.

  What it does not promise

  Ranking depends on many factors beyond any single site — competitors, the market, and ongoing search-engine changes. For that reason a specific ranking is never guaranteed. Anyone who guarantees a position is not describing how search actually works.

• 08 What social media analysis includes It covers analysis and reporting. Managing accounts or running ads is separate and not included by default.

  Social media analysis is about understanding what is already there and what it is doing, then setting it out clearly — not about running the accounts.

  What is reviewed

  • Existing accounts, content and posting patterns.
  • The metrics that are actually available for each platform.
  • How the accounts compare with named competitors, where useful.

  What you get, and what is separate

  The result is a readable report with observations you can act on. Running the accounts, producing posts and advertising are separate activities; they are included only under a scope that says so.

• 09 Payment methods after scope confirmation Payment details are shared only after the scope is reviewed. No card data is collected on the site.

  Payment details are shared only after the requested scope is reviewed. Depending on the confirmed scope, payment may be made through IBAN/bank transfer, CepBank, easy address transfer or payment link. The website does not collect card numbers, banking passwords or sensitive payment credentials.

  Why it works this way

  Cost follows scope. Until the scope is clear, a price would be a guess — so payment is discussed after the request is reviewed, not before. The contact form never asks for payment information.

  Rules, delays, fees or interruptions that come from a bank or payment provider are outside Grau’s control.

• 10 Security and maintenance scope Maintenance, monitoring, backups and emergency work are separate and need their own written scope unless already included.

  A site is delivered in a working state, with the agreed setup documented. What happens after that — keeping it updated, watched and backed up — is a separate kind of work, and it is treated as such so expectations stay clear.

  Handled under a separate scope

  • Ongoing maintenance and updates.
  • Monitoring and uptime checks.
  • Backups and recovery.
  • Emergency intervention when something breaks.

  A note on hand-built sites

  Because sites are built by hand in code rather than on a CMS, there is no plugin stack to keep patched and far less surface for tampering. That lowers routine maintenance, but it does not replace a monitoring or support scope where one is needed.

• 11 Post-delivery changes and third-party intervention Changes made after handover fall outside the original scope. New work needs a new, agreed scope.

  The agreed scope describes exactly what is delivered. Once handover is complete, that scope is considered met — which is what makes it possible to state a clear price and a clear boundary in the first place.

  What counts as new work

  • Edits made later by you or by a third party.
  • Changes to the code, the hosting panel, DNS or content after handover.
  • Unauthorised edits, or changes made through another provider.

  Problems that follow from such changes are handled as new work under a separate scope. This is not a penalty — it is simply how the boundary of the original scope is kept honest for both sides.

• 12 How long contact form data is kept The request is delivered by email; the on-site copy is deleted after about a week. No payment card data is collected.

  When you send the contact form, the request is delivered to Grau by email — that email is the working record. On the server itself only a short-lived copy is kept, and it is deleted automatically after about a week.

  What it contains

  • The fields you fill in on the form.
  • IP address and user agent, kept for security and record-keeping.
  • The timestamp, the language and your consent record.

  Your rights

  You can ask what is held about your request, ask for it to be corrected, or ask for it to be removed, using the contact address in the notices. Payment card details are never collected.

• 13 A quick tour of cPanel Where to find files, email, databases and backups in a typical cPanel host.

  cPanel is the control panel most shared hosts use. It lays everything out as tiles; here is where the useful ones are.

  Files

  • File Manager opens your site’s files. The site itself lives inside public_html.
  • FTP details (host, username, password) are under FTP Accounts, if you prefer an app like FileZilla.
  • Backup or Backup Wizard makes a full copy you can download before any big change.

  Email and databases

  Email Accounts creates addresses on your domain — the next guide covers connecting them to a phone or Outlook. MySQL Databases and phpMyAdmin only matter if your site uses a database; a hand-built static site usually does not.

• 14 Connecting email to your phone or Outlook The IMAP/SMTP settings you need after a mailbox is created, and what they mean.

  Once a mailbox exists in cPanel, any mail app can connect with a few settings. Use these, swapping in your own domain and address.

  Incoming — IMAP

  • Server: mail.yourdomain
  • Port 993, security SSL/TLS
  • Username: the full email address
  • Password: the mailbox password

  Outgoing — SMTP

  • Server: mail.yourdomain
  • Port 465, security SSL/TLS
  • Authentication required (same username and password)

  Prefer IMAP over POP so your mail stays in sync across devices. If the app offers an automatic setup, these manual settings are the fallback that always works.

• 15 Uploading a site by File Manager or FTP How files get onto a host, and why everything goes inside public_html.

  A website is just files on a server. Getting them there is either through cPanel’s File Manager in the browser, or an FTP app like FileZilla.

  The one rule

  Everything the public sees goes inside public_html. A file at public_html/index.php is served at yourdomain/. Anything above public_html is not public.

  File Manager or FTP

  • In File Manager, open public_html and use Upload, or upload a .zip and Extract it in place.
  • For FTP, put the host, username and password from FTP Accounts into FileZilla and drag files into public_html.
  • Leave file permissions as the host set them unless you are told otherwise.

No entries match.