SiteGround Spain, RIPE Membership and Centralized DNS: Who Controls Website Continuity?

Summary

RIPE NCC lists SiteGround Spain SL as a Local Internet Registry member in Madrid. That entry is a useful administrative record, but it does not identify a specific autonomous system, address block, route, server or customer website. It should be read as a ledger entry, not as a complete map of SiteGround's network or proof that a service is healthy.
SiteGround documents one centralized DNS service, a common pair of nameserver names, tools for records and delegation, hosting locations, backups, collaborator access and account recovery. These mechanisms reduce routine work, but continuity still depends on the customer's registrar authority, correct records, external checks, independent copies, rehearsed restoration and recoverable human ownership.

SiteGround is familiar to many small organizations because it turns several difficult jobs into visible controls. A customer can register or connect a domain, edit DNS records, host a site, restore a backup, invite a collaborator and contact support from a small number of screens. That convenience matters. It lets a shop, charity, publisher or professional firm operate a public service without maintaining a data center or a full network team.

Convenience can also hide boundaries. The person who buys the domain may not be the person who owns the hosting account. The nameserver delegation may sit at one registrar while the DNS records sit at SiteGround. Email may be delivered by a third party. A backup may exist but remain tied to the site that is about to be deleted. A developer may know the application but lack authority to recover the account. A provider can report normal platform operation while one customer's checkout fails because a DNS record, certificate, plugin or payment callback is wrong.

This analysis connects public registry evidence with SiteGround's own documentation. It does not attribute an outage, weakness or poor practice to SiteGround Spain SL, another SiteGround company or any customer. It does not infer private topology or claim that every product is operated by the Spanish entity. Its purpose is practical: show what each record or control can prove, what it cannot prove and what a non-specialist owner should verify.

The featured image is an original generated photorealistic editorial scene. It shows an unidentified small-business website operator comparing a printed DNS and recovery checklist with a simple dependency sketch at an ordinary desk, with generic unbranded equipment in the background. It does not depict SiteGround, SiteGround Spain SL, Google, any employee, facility, customer, system, incident, weakness, performance result or endorsement.

The RIPE entry is an administrative anchor, not a network map

RIPE NCC publishes a member page for SiteGround Spain SL. The captured page names the company, gives a Madrid address, publishes a contact address for RIPE matters and lists Spain as the area serviced. BTW's directory entry uses that public relationship as the reason for tracking the company.

For a non-specialist, a Local Internet Registry can be understood as an organization with a contractual and administrative relationship to the regional registry. RIPE NCC members can request and manage internet number resources under the applicable rules. Membership makes coordination possible and creates an accountable place in the registry system.

The page does not, by itself, say that SiteGround Spain SL announces a particular autonomous system number. It does not enumerate an IPv4 or IPv6 allocation. It does not say which legal company operates a given product, router, data center or customer contract. It certainly does not prove that a website is reachable.

That distinction is central. A registry should keep unique identities and transfer or contact records accurately. It acts as a ledger and coordination point. It is not a sovereign control panel for every machine using a resource. A clean membership entry can coexist with a DNS mistake, an application failure or a lost customer password. An imperfect contact entry does not automatically mean the running service is down.

The operational use of the entry is therefore bounded. Record its name, date and contact. Recheck it when ownership or corporate structure changes. Use it as one pointer during coordination. Do not turn it into a claim about routing, capacity, security or performance unless separate evidence supports that claim.

The company name and the service brand are related but not interchangeable

SiteGround's Spanish company page describes a group registered in several countries, including Spain. The public material presents a family of hosting, website-building, ecommerce, email and business tools. The RIPE page names SiteGround Spain SL, while product documentation commonly uses the broader SiteGround brand.

Customers often see several identities in one service relationship. A contract may name one company. A bank statement may show another descriptor. A support message may use the group brand. A domain registry may identify a registrar. A hosting address may sit on infrastructure supplied by another provider. None of those differences is automatically suspicious.

They should still be documented. During an incident, the team needs to know which legal name is on the invoice, which account owns the site, which address is expected to send support mail, which company can authorize a transfer and which portal controls the service. Otherwise a legitimate request may be ignored or a fraudulent one may be trusted.

This article binds its subject to the published SiteGround Spain SL directory object because that is the verified entity available in BTW. It uses group product documentation only for the controls SiteGround publicly describes. It does not assign every group operation to the Spanish company. That boundary protects both accuracy and usefulness.

A website depends on several authorities, not one green status

People often say that a website is "hosted at SiteGround" as though one switch controls the whole result. In practice, at least seven layers can decide whether a visitor completes an action.

First, the domain must remain registered. The registrar account must be paid, recoverable and protected. Second, the parent registry must delegate the domain to the intended authoritative nameservers. Third, those nameservers must return correct records. Fourth, the returned address must lead through the internet to the intended hosting or delivery layer. Fifth, TLS certificates and security policy must allow a trusted connection. Sixth, the application, database, files and external services must work. Seventh, an authorized person must be able to diagnose and change the system.

A failure at one layer can look like a failure at another. An expired domain can look like broken hosting. A stale resolver cache can look like an unsuccessful migration. A wrong MX record can break email while the website remains healthy. A running server can return an application error. A functioning application can still lose payments because a callback address is blocked.

The remedy is not to make every owner a network engineer. It is to give each layer a plain name, an owner, an expected observation and a recovery path. That small dependency map prevents a team from closing an incident merely because one dashboard is green.

The domain registry records delegation, not the answer a visitor receives

The captured Verisign RDAP response for SITEGROUND.NET lists NS1.SITEGROUND.NET and NS2.SITEGROUND.NET. It also records domain status values that restrict transfer and update through the registrar. This is registry-layer evidence for the domain used in SiteGround's standard nameserver names.

RDAP is a modern way to read registration data. It can help an operator confirm the registered domain, nameserver names, registrar and relevant status. Those fields matter because an unauthorized transfer or an expired domain can break every service below it.

The registry does not execute a customer's website. It does not show every DNS record in a customer's zone. It does not guarantee that either nameserver is answering correctly at a particular moment. It does not test whether a browser can load a page or whether an email reaches a mailbox.

For an ordinary organization, the useful control is a domain register containing the registrar, registrant organization, renewal method, expiry alert, administrative email, two recoverable owners, current nameservers and an emergency contact path. Check that register against the live registry, not only against an old invoice or screenshot.

SiteGround documents a centralized DNS service

SiteGround's current knowledge base names NS1.SITEGROUND.NET and NS2.SITEGROUND.NET as its standard nameservers. A 2021 engineering article explains that the company moved DNS away from individual production servers into a separate cluster and used a geographically dispersed anycast design. The article describes one shared pair of nameserver names across managed servers.

Centralization can remove fragile routine steps. If many hosting servers use the same authoritative service, a server migration may not require the customer to change nameserver delegation. DNS can continue answering for outside services, such as email, even if a particular hosting server is unavailable. One interface can manage records for several sites.

The same design also changes the questions a customer should ask. Two nameserver names are not necessarily two separately owned services. Multiple geographic instances may sit behind the names. A customer usually cannot infer physical diversity merely by counting labels. The issuer article describes the intended architecture at the time it was written; it is not an independent, current audit.

The practical conclusion is balanced. Use the documented service, but observe it from outside. Query more than one public resolver. Check both expected nameserver delegation and important records. Keep a dated export of the zone. Test email and the customer journey separately from the hosting dashboard.

Delegation decides which DNS editor matters

SiteGround's DNS management guide makes a crucial point: its editor controls effective public records only when the domain is pointed to SiteGround's nameservers. The interface can contain a perfect A record, MX record or TXT record and still have no effect if the parent delegation points elsewhere.

This is one of the most common control-boundary errors. A user changes a record in the portal that feels familiar. A second provider is actually authoritative. Hours later, the public answer has not changed. The person may repeat the edit, lower a local cache or blame propagation, but the wrong control surface was used from the beginning.

Before editing, confirm authority in this order: identify the registrar; inspect the nameservers delegated by the parent; query the authoritative nameservers directly; compare the intended zone; then observe public resolvers. The steps are simple when written down, and each one answers a different question.

The DNS editor supports common records. A and AAAA connect names to IPv4 and IPv6 addresses. CNAME creates an alias. MX directs email. TXT can carry verification and mail-security policy. SRV can locate a service. A change to one type can affect a service that is not visible on the home page.

A nameserver move is a data migration, not just a settings change

SiteGround's guide to changing nameservers warns that advanced records resolve from the DNS zone of the newly selected provider. It recommends adding custom records to the new zone before the switch. That advice matters because the nameserver change moves authority for the entire published zone, not only the website address.

Imagine a small company that moves a website but keeps mail with Microsoft or Google, verifies services through TXT records and receives payments through a callback hostname. If the new zone contains only the website's A record, the site may appear online while mail, verification or a subdomain fails.

A safe move begins with an export or complete inventory of A, AAAA, CNAME, MX, TXT, SRV, CAA and relevant NS records. Mark which application or supplier depends on each record. Build the new zone. Reduce TTL in advance where appropriate. Query the new authoritative servers before changing delegation. Keep the old zone available through the overlap. Validate from several networks and then restore normal TTL values.

The rollback condition should be explicit. If a critical record cannot be reproduced, stop before delegation. If the new authority returns an incorrect answer, know whether the registrar permits a quick reversal and how long caches may retain either version. A change plan without a test and rollback is only a hope.

Propagation is many caches changing at different times

SiteGround explains DNS propagation through TTL, record types, resolver caches and network conditions. The useful point is that there is no single global propagation button. Different recursive resolvers may hold different valid cached answers until their individual timers expire.

TTL is a cache instruction, not a promise that every user changes at the same second. Lowering it shortly before a migration may not help resolvers that already cached an older, longer value. Nameserver delegation can also have different caching behavior from an ordinary A record.

During a change, record the old answer, new answer, expected TTL and start time. Query the authoritative server, the organization's own resolver and at least two independent public resolvers. Test from a mobile network or an external probe. Do not repeatedly change values in response to normal, temporary disagreement; that can make the transition harder to understand.

Completion should be defined in business terms. The new answer is widely visible, the old system remains safe during the overlap, email passes, certificates work, important subdomains resolve and a representative transaction completes. "The portal saved my change" is only the beginning.

DNS continuity includes email and verification records

Many owners associate DNS only with the website address. SiteGround's editor documentation shows why that is incomplete. MX records select mail destinations. TXT records can hold SPF, DKIM, DMARC or ownership verification. CNAME and SRV records can connect marketing, support, identity and communication services.

A website migration that forgets MX records can interrupt incoming mail. A missing DKIM selector can weaken authentication. A stale TXT verification can block a service renewal. A CNAME change can disconnect a customer portal even while the main page loads.

The dependency register should therefore connect each DNS record to an owner and a consequence. The marketing team may own a campaign subdomain. Finance may depend on a payment callback. IT may own mail policy. A contractor may manage the website. The registrar and authoritative DNS remain organization-level assets because every team depends on them.

External monitoring should include more than HTTP. Check authoritative NS, SOA consistency, important A and AAAA answers, MX destinations and selected security TXT records. Alert on unexpected delegation changes. Keep alerts understandable; a small team needs a short list of high-impact signals, not thousands of unexplained measurements.

Hosting location and DNS location answer different questions

SiteGround's infrastructure page lists Madrid and other data-center and CDN locations and describes the use of Google Cloud infrastructure. Its centralized DNS article separately describes a DNS cluster. These are related delivery layers, but they are not the same thing.

The domain's authoritative service can remain available while a hosting instance is down. A CDN may continue serving cached files while an origin database is unavailable. A customer may host in one region while a backup is stored elsewhere. The visible source address may belong to a supplier rather than to the legal company named in a membership registry.

This layered supply chain is normal. It becomes risky when nobody has written it down. A customer should know the chosen hosting region, any CDN or proxy layer, the origin address, the authoritative DNS provider, the backup location policy and the support route. It should also know which of those can be changed by the customer and which require provider action.

Vendor statements about redundancy and connectivity describe offered design. They do not prove a particular customer's placement, contract, available capacity or tested failover. The customer's evidence comes from its account configuration, external measurements and recovery exercises.

A backup is useful only within its access and deletion boundaries

SiteGround's backup guide describes automatic copies and restoration of files, databases and email. It also warns that deleting a site removes ordinary access to its backups. Depending on the plan or backup service, downloadable copies may be available; otherwise the customer needs its own copy before deletion.

That warning turns a feature into an operational control boundary. If the site and its backups share one lifecycle action, a well-intentioned cleanup can remove both the production object and the normal restoration path. If the same account controls production and every copy, an account-access problem can block recovery even when bytes still exist.

List what the backup includes: website files, databases, email, configuration, certificates, secrets, DNS records, scheduled jobs, external storage and third-party settings. Do not assume the product name covers every item. Record retention, location, deletion behavior, download rights and the person who can start a restore.

An independent copy does not have to be complex. A small organization can periodically export its database and essential files into encrypted storage under a separately controlled account. It can export the DNS zone and keep registrar details offline. The copy should be protected, current and recoverable without the same single credential as production.

Geographic backup descriptions still require a restore test

SiteGround publishes a map of server and backup locations. The captured documentation says that Madrid-hosted sites are backed up in Eemshaven. That separation can reduce exposure to one local event, subject to the actual product and account configuration.

Geography is only one part of recovery. A copy in another country may still be controlled by the same account, deletion workflow or encryption key. It may omit an external database or a SaaS integration. It may be too old for the business's recovery-point objective.

A representative restore creates stronger evidence. Restore into an isolated destination. Recover files and the database. Recreate required DNS or a safe test hostname. Load secrets through the approved process. Confirm that background jobs do not contact real customers. Then complete a business action such as a test order, form submission or authenticated update.

Measure two outcomes. Recovery point is how much recent data could be lost. Recovery time is how long the business can tolerate the service being unavailable. The right schedule follows transactions and obligations, not the number of backup icons in a portal.

Restoration can overwrite current data

The backup documentation offers whole-site and selective restoration. Replacing all files and databases can be exactly the right action after corruption, but it can also overwrite good data created after the chosen backup.

Before restoring, preserve the present state where safe. Record the symptom, recent changes and chosen restore point. Decide whether files, one database, email or the full site needs replacement. Check whether orders, uploads or messages arrived after the backup. Notify the business owner if a rollback may remove them.

After restoration, clear relevant caches and verify the service from outside. Confirm that database migrations match the deployed application. Reconcile payment and message queues. Test scheduled jobs. A technical success message is not a closeout until the business path and data expectations are checked.

The exercise should be rehearsed before an emergency. A short runbook with screenshots, roles and stop conditions is more valuable than a long policy nobody has used.

Collaborator accounts reduce password sharing, but access still needs ownership

SiteGround documents collaborator accounts that use their own Client Area rather than the owner's personal login. Collaborators receive access to assigned sites or services and are restricted from owner billing, personal information, private support history and unshared services. For many hosted sites, this is safer and more accountable than sharing one owner password.

The collaborator model also shows that operational ability and ultimate ownership are different. A developer may manage files, databases and hosting settings while the owner retains billing and account authority. A marketing contractor may work on content without controlling the domain. Those boundaries should match the actual job.

SiteGround separately documents how to add access, grant another site, remove a collaboration and delete a collaborator. The customer must still operate the lifecycle. Invite the correct person. Review access after a project changes. Remove permissions when someone leaves. Keep an organization-controlled owner account capable of acting if the collaborator is unavailable.

For each critical service, maintain at least two named people who understand the recovery process, but avoid giving both unlimited everyday access. Separate ownership, routine operation and emergency approval where the consequence justifies it.

Two-step verification protects authority only if recovery is controlled

SiteGround's account-security guide describes time-based two-step verification, extra authenticator devices and a backup phone. These features can reduce the risk that a stolen password alone gives an attacker control of the account.

Recovery information is part of the same security boundary. A phone number belonging to one departing employee can become a single point of failure. A personal email may be inaccessible to the company. An extra authenticator copied without an inventory can become untracked access.

Use an organization-controlled administrative email. Record who holds each authentication device. Protect backup codes or recovery information in an approved vault. Review phone numbers and addresses after staff changes. Test the recovery route without disabling protection or exposing secrets.

The strongest setting is not always the most recoverable setting. Good control preserves both security and continuity: an unauthorized person cannot enter, and the legitimate organization can still prove authority and act during a crisis.

Ownership recovery is slower than ordinary login

SiteGround publishes procedures for lost administrative email or phone, a third party who owns the account, a former employee and a deceased owner. The paths can require identity documents, payment evidence, corporate records, a court order or other proof of authority.

Those procedures are necessary because support should not transfer a valuable service on a casual request. They also show why ownership should be corrected before an emergency. A company whose former employee controls the account may face delay at the exact moment a website needs repair.

The organization should compare the service account with its legal and operating reality. Is the owner a current company-controlled identity? Is billing recoverable? Can a second authorized person reach support? Does the company have the documents needed to prove ownership? Is the registrar controlled by the same fragile personal account?

Do not wait for an outage to discover the answers. Account recovery is a governance process with operational consequences.

Provider monitoring and customer monitoring see different realities

SiteGround describes platform monitoring and communication for scheduled and unscheduled maintenance. Its troubleshooting guide asks whether a site is reachable from other locations, what error appears, what changed recently and whether work is in progress.

Those questions encourage a layered diagnosis. If many independent locations cannot resolve the domain, begin with delegation and DNS. If DNS is correct but only one network fails, consider resolver or path differences. If the server answers but the application returns an error, inspect code, database and recent changes. If the home page works but checkout fails, test the transaction and its dependencies.

A provider status or maintenance notice is one observation. It can reveal a broad event. It cannot see every customer record, plugin, certificate, secret, integration or business transaction. Conversely, one customer's failure does not prove a platform-wide incident.

Create an outside check for the most important user action. Use a second channel for alerts. Subscribe to provider notices. Preserve timestamps and recent changes. Close the incident only after the external action succeeds and delayed work has been reconciled.

The cost of failure extends beyond the hosting bill

Small organizations often choose managed hosting to reduce fixed technical cost. The provider operates large parts of the infrastructure, updates tools and offers support. That economic choice can be sensible.

The monthly invoice is not the full cost of continuity. The customer still needs domain renewal, account governance, DNS review, external monitoring, backup exports, restoration exercises, access reviews, incident communication and staff time. A failure adds lost sales, missed enquiries, support effort, contractor fees and reputational harm.

The right level of control depends on impact. A temporary campaign page may accept a manual rebuild. A booking system, member portal or ecommerce store may need lower data loss, a tested restore and faster escalation. The decision should be explicit and funded.

Resilience is not the purchase of every premium feature. It is the deliberate removal of dangerous assumptions: that one person will always be available, that a backup contains everything, that two names prove independent systems, that a registrar and DNS provider are the same, or that a green server means customers can complete their work.

A thirty-day continuity plan for a small organization

In the first week, establish authority. Record the legal owner, registrar, expiry, payment method, administrative email, nameservers, hosting account and support route. Confirm that two current people can reach the recovery process without sharing a personal password. Enable two-step verification and document its backup path.

In the second week, map DNS and services. Export the zone. Label A, AAAA, CNAME, MX, TXT, SRV and CAA records by business purpose. Identify email, payments, marketing, identity and third-party callbacks. Query authoritative and public resolvers. Correct records through the control surface that is actually authoritative.

In the third week, map data and copies. List files, databases, email, uploads, secrets, scheduled jobs and external services. Compare the list with the hosted backup. Create a separately controlled copy of essential data and the DNS export. Record deletion and download boundaries.

In the fourth week, restore and observe. Use an isolated destination and a safe hostname. Restore data and configuration. Test login, form, order or other representative action. Measure recovery time and data age. Add a simple external check and an alert route that does not depend on the failing website.

The final output is a one-page service card: owners, suppliers, authority map, critical records, backup scope, recovery path, last test and accepted gaps. Review it after any migration, personnel change or new integration.

Questions to ask before accepting a continuity claim

What exact registry or account record supports the identity being discussed? Does it identify membership, a domain, an address, an ASN or only a brand? When was it captured?

Which nameservers are delegated at the parent? Which portal controls the authoritative zone? Are important email and verification records included in the change plan?

What is the actual hosting and delivery chain? Which parts are SiteGround controls, supplier controls or customer controls? Which public claims are design descriptions rather than measurements?

What does the backup include and exclude? Where is it retained? What happens when the site or account is deleted? Can a copy be recovered through a different authority path?

Who owns the account? Who can perform routine work? Who can revoke access? What happens if the main phone, email, employee or contractor is unavailable?

What observation closes an incident? Is it a platform status, a server response, an application check or a completed business transaction? Which one actually matters to customers?

Conclusion

SiteGround Spain SL's RIPE NCC membership entry is a useful administrative anchor. It places a named legal entity in a registry relationship and provides a coordination contact. It does not map a private network, establish a route or prove that a customer service is available.

SiteGround's documentation describes practical controls for centralized DNS, records, nameserver changes, hosting, backups, collaborators, two-step verification and recovery. Those controls can make a small organization's work easier. Their value depends on accurate authority, disciplined changes, clear ownership and representative tests.

The most useful continuity statement is not "our hosting is online." It is specific and dated: the domain remains under recoverable ownership; the intended nameservers are delegated; authoritative records match the service map; external probes see the right answers; essential data exists in a recoverable copy; authorized people can act; and the customer journey has completed successfully.

That is the reality layer. Registries preserve identity. Providers supply mechanisms. Running services and tested recovery show whether the organization can continue operating.

Sources

Image attribution

Original photorealistic editorial image generated for BTW Media: an unidentified small-business website operator compares a printed DNS and recovery checklist with a simple dependency sketch at an ordinary desk, with generic unbranded equipment softly visible in the background. The image was created with the built-in image generation tool and prepared as a 1600 × 900 JPEG. It uses no third-party photograph, logo, trademark, real dashboard or readable private information.

It does not depict or imply SiteGround, SiteGround Spain SL, Google, any employee, facility, customer, system, architecture, service performance, incident, weakness or endorsement.