An Already Running Online Store: What to Check Before You Buy

The seller opens a laptop, turns the screen towards you, shows a chart with a rising curve and names a figure, immediately followed by the rest of the figures and claims: the store is trading, turnover is this, buyer traffic is that, and the price is this. Everything looks in order, and that is exactly why it is worth stopping, because almost every one of these claims can be checked, and almost none of them is checked while the contract is still unsigned.

This article is about the technical inspection before you buy an already running online store, and it is not about what such a store is worth, because valuation and tax questions are other people’s work, which we deliberately do not touch here. We have written separately about how to build a store from scratch, and likewise about what it costs to create an online store. Here the situation is a different one entirely: the store already exists, it has a history, and the question is which of that history actually transfers to you and which stays with the seller.

Analytics access shows less than it seems

The first thing every reasonable buyer asks for is read access to Google Analytics, and that is right, but it is not enough, because that access proves less than most people think. Google Analytics 4 has five roles, namely Administrator, Editor, Marketer, Analyst and Viewer, and it is the Viewer role that the buyer is usually given: a Viewer can see settings and data and can change which data appears in reports, but cannot manage users or change property settings.

The assignment itself already says something, because only an Administrator can add a user, and users are identified by a Google Account email address, so a seller who cannot grant read access is not an Administrator of that property, and that is a question to ask at once. A screenshot is not access, and a conversation in which the seller shows their screen is not access either, even if the figures look convincing.

Next comes a detail few people know and which can reverse the conclusion entirely, because Google Analytics lets a property be given data restrictions, and two of those restrictions concern money: No Cost Metrics hides cost metrics, and No Revenue Metrics hides revenue metrics. The restricted values do not appear in reports, and the user sees zero instead. A buyer who sees zeros in the revenue column has therefore not seen that the store does not earn; they may have seen a restriction, and the only way to find out is to ask whether the restriction has been applied.

There is also a more general limit worth keeping in mind throughout the inspection, and it touches measurement itself: analytics shows what the installed measurement code recorded, not how many people actually came. A code placed only on the thank-you page, a code that fires twice, a code on a development environment, or the same code serving several websites, all look like visits in the report. None of these cases is fraud by definition, but each of them makes the figure into something other than what the buyer thinks.

Search Console is a different object and a different check

Google Search Console shows what Google itself recorded about the website’s appearance in search results, so it is partly independent of the measurement code the seller installed, and it is that independence that makes it more valuable than analytics, even though the figures there are smaller and less flattering. The roles there are different from analytics: Owner, Full user, Restricted user and Associate, and a property must have at least one verified owner, or nobody has access.

A Restricted user sees the Performance report, so queries, clicks, impressions and average position, but cannot add users, submit a sitemap or fully inspect a particular URL, so for the buyer that is enough to see search traffic, but not enough to take over the property. That is a deliberate difference worth understanding before the conversation, because a seller who offers only Restricted user access is offering figures, not a way to take over.

There is also the question of how old the history itself is, and that often decides more than the size of the figures, because Google starts collecting data for a property the moment someone adds it, even before verification, so a recently created property cannot show several years of history no matter how long the store has been trading. Ask when the property was created, and compare that with the age the store claims.

Now for what this tool can show wrongly, and these are not claims about the seller’s dishonesty, just mechanics: a property can be of two types, namely a URL-prefix property, which covers only one address with its protocol, and a Domain property, which covers the whole domain with all subdomains. A Domain property can therefore mix the store’s traffic with that of a completely separate blog into one figure, and the only way to see that is to look at what type of property is open.

The second mechanics question is verification, and it works like this: ownership is verified with a proof on the website, and one of the permitted methods is precisely the Google Analytics tracking code. That means both tools can have been verified with the same code, controlled by the same person, so two apparently independent checks can be talking about the same, possibly wrong, website. Unused ownership tokens, moreover, let a previously removed owner verify themselves again, so a buyer who becomes an owner has to review which proofs are still left on the website.

Finally, it is worth knowing the bound of the historical window, which here is strict: Performance data is kept for sixteen months, so a three-year growth story cannot be pulled from this tool, and a seller who promises that has to prove it with something else. And last: it is not right to expect the analytics and search-tool figures to match, because they measure different things, and no Google document promises any particular relationship between them.

An export is not the store

The second large trouble sits in the word export, because the buyer understands it as a copy of the store, but in practice it is an extract of particular tables with particular limits. WooCommerce core includes a product import and export tool, and it does work, but it is a product tool: it does not cover customers and orders at all, and those need either a paid plugin or direct access to the database.

Images are a separate small thing with disproportionately large consequences, and the reason is in the export mechanics: product export works with image addresses, not the files themselves, so the images have to be reachable at the moment of import, and the core tool does not transfer image alternative texts. For a store with a few thousand products that means that after the move some of the images may simply not be there, and that is discovered only when it is already too late to negotiate the price.

On more closed platforms the limits are stricter, and they have to be known before the conversation about price, not after it: password hashes usually do not transfer, and that means every existing customer will have to reset their password after the move, which is a direct loss of customers and which the seller will mention rarely. The theme licence often stays with the seller’s account, plugins are separate subscriptions with their own licences, and some platforms do not let order history be imported back through the admin panel at all.

To the same group belong three small things that are rarely remembered and each of which costs money on its own. Gift cards with a remaining balance are liabilities towards customers, and they do not always move with the rest of the data, so the question of how much unused balance is in the store belongs in the price conversation. A TLS certificate is not transferred as property, but issued again in the new holder’s name, and that is routine only if the domain is already in your hands, while the theme licence is often tied to the seller’s account, so after the move it can turn out that the look has to be bought again.

From that follows an inspection step that costs nothing and says a great deal. Ask the seller to produce a test export before the contract and open it yourself, because there you will see at once whether customers are in it, whether orders have line items, whether images have addresses, and whether something that is visible in the store does not appear in the file at all.

The domain transfers with a change of registrant, not by changing nameserver records

The domain part is where buyers mix up three completely different operations, and that mix-up tends to end with the domain remaining in the seller’s name. A nameserver change is only a pointer to who serves the domain’s records, and it has nothing to do with ownership; a registrar transfer changes who administers the domain; and a change of registrant is what changes whose name the domain is registered in.

A change of registrant is done under that domain’s registry rules, and it is this requirement that protects registrants against a stranger rewriting the name into their own name. The usual path is through the current registrar; some registries also have a documented path when the outgoing holder no longer exists. There is no single English-language registry. If a registrar administers the domain, the request goes through that registrar, not directly to the registry.

Two details in this procedure matter more than the rest, and the first of them is that once the registry has processed the change of registrant, the previous registrant no longer controls the name. Restoration periods, where they exist, differ by registry and are not a general right to unwind a completed change, so the change has to be done correctly the first time. The second is that a legal person’s request is made by people with authority to represent it and has to meet that registry’s own formal requirements, so it is not enough that some employee of the company sends it.

Separate attention is due when the seller is a company that is going to be liquidated, because this is where buying the store can end with losing the domain. There is no single rule across registries for what happens after liquidation, because there is no single registry an English-language reader can treat as their own. The change of registrant has to be done while that company still exists as a registrant the registry will accept; after that, whether the name can still be moved, is deleted, or later becomes available to anyone, is that domain’s registry’s question. A buyer who waits for the seller to sort their affairs out can find that the store’s address has gone to a stranger.

The payment account does not transfer with the purchase contract

The assumption that taking payments also transfers with the store is common and wrong, but it is equally wrong to say that a payment account cannot be moved at all, because the right formulation is in the middle: the purchase contract itself does not move the account, but the payment-service provider has a procedure of its own, and it can also refuse.

Stripe in its documentation describes exactly this case, stating that the existing account owner who wants to hand the account to someone else, for example when selling a business, must first contact support to find out what information has to be updated. After that, the bank-account details for payouts, the legal business name, the tax identification number and the representative’s details are changed, and the company specifically warns against sending the new owner’s details by email; if the business has been taken over by a legal person in another country, the procedure is different.

There is another detail that concerns the data itself and that buyers learn late: if the move happens not by taking over the same account but by moving to a new one, then customers and payment methods can be copied between the two accounts, but individual charges, invoices, plans and subscriptions, coupons, events and logs do not copy. For a store with subscriptions that is critical, because interrupting subscriptions means interrupting revenue, and this question has to be asked before the deal, not after it.

We have not used the acquisition-contract terms of banks or local payment intermediaries in your market, because we did not read them for this inspection, and it is more honest to say that than to fill the gap with a guess, so this is a deliberate gap, not an omission. If the store takes payments through a bank or a local payment intermediary in your market, whether the contract may be assigned is a question to ask of that provider, and Stripe’s procedure must not be carried across to it.

The customer list is the legally sharpest part

This is the place where the buyer can acquire not an asset but a duty, and that is why this section is written as a warning, not as a how-to. It starts in the structure of the deal: if you buy the company’s shares (a share deal), the controller remains the same legal person and the database does not change owner; if you buy the store as a bundle of assets from another legal person (an asset deal), the personal data arrive at a new controller, and that is a completely different case.

The General Data Protection Regulation promises nothing about buying a store, and it contains no article that says a customer database transfers automatically. Where the Regulation applies — in the EU and, through the EEA, in Norway — there has to be a legal basis under Article 6, and there is an information duty: Article 13 requires the controller’s identity to be given at the moment the data are obtained, while Article 14, which applies precisely when the data were not obtained from the person themselves, requires the new controller to state its identity, purposes, legal basis, categories of data and source, and to do so no later than within a month or at the first communication. The Regulation is not of its own force the law of a reader outside the EU and the EEA; the same questions still arise there, under that country’s own rules.

On marketing emails a second layer sits on top, and that is the core of this section. In the EU and the EEA the floor is Directive 2002/58/EC Article 13: sending commercial communications by email requires prior consent, and Article 13(2) permits an exception only for the same natural or legal person who obtained the electronic contact details in the context of a sale, for that person’s own similar products or services, with a free way to refuse at collection and in every later message. National transpositions differ — some are stricter, and Poland currently has no similar-goods exception at all — so an English-language reader has to apply their own country’s ePrivacy transposition, or, if they are outside the EU and the EEA, their own marketing law. This article does not treat any one country’s act as the English rule.

And now what makes this a trap: that exception is written for the trader who obtained the addresses in their own commercial transactions, that is, the same one who served the customers. A buyer who did not obtain the addresses is not that trader, so the previous owner’s exception does not travel with the file; a regulator’s silence on store acquisitions is not a permission.

This question has been settled in different ways from country to country, and it is more honest to show that mismatch than to cover it. Germany’s conference of data-protection authorities (Datenschutzkonferenz) in 2024 took a strict position, holding that the sale of a customer database as a detached asset usually requires prior consent, while Spain’s Organic Law 3/2018 (LOPDGDD) contains a provision that, on a structural modification or the transmission of a business or of a branch of activity, processing is presumed lawful if it is needed for continuity of the services. Most other countries have no such extra statute, so the buyer is left with the Regulation where it applies, their own country’s ePrivacy transposition, and legal advice on the specific deal.

Checks that do not depend on the seller

All the previous checks depend on what the seller grants and what their settings show, so alongside them it is worth putting at least one whose source is different, and the simplest of those checks is the server logs, because they record requests independently of whether a measurement code is installed on the page at all and of whether the visitor consented to cookies.

This is not a Google method and no Google document recommends it, so we do not present it as an official recommendation either, but as a practice in which, comparing the volume of log requests with analytics sessions for the same period, you usually see either a reasonable ratio or a difference worth asking about. Access to the logs is usually given by the hosting control panel, so this check requires hosting access, and that is why it is worth requesting it at the same time as the rest.

The second independent source is the payment-service provider’s statement, and it is the only one of all of them that shows money, not visits. One distinction matters here: a statement the seller sends as a document is not the same as a statement you see in the provider’s own panel, because the first can be prepared by anyone and the second cannot, so ask for access to the panel, or at least a shared screen with it open.

There is another check that costs five minutes and that almost everyone skips: look at how the store appears in the search engine today, by entering its name and a few product-name phrases. If the store claims stable search traffic but does not appear under its own name, or appears behind marketplaces on which it itself sells, then the traffic comes from somewhere else, and it is worth finding out from where, because paid advertising can simply stop after the deal.

The third is the accounting side, which we do not touch on the substance, but whose existence is worth mentioning, because it is the only one that ties everything else to declared figures, and if analytics, the payment panel and the accounts tell three different stories, then the problem is not measurement accuracy, and from there it is no longer a technical conversation.

The state of the code and the platform can be checked cheaply

A check of the technical state sounds like an expensive audit, but most of the answer can be obtained in a few hours and with public data. The first step is to establish the platform and language version and compare it with the vendor’s published support calendar, because after support ends new vulnerabilities are no longer patched, even though the store continues to run exactly as before.

The second step is the list of plugins together with their update history, because an abandoned plugin is at once a security risk and a hidden cost: at some point it will have to be replaced, and replacement in a running store usually means rewriting everything built around it as well. The third is the question of whether the store has ever been hacked and what was done afterwards, and this question is worth asking directly, because an evasive answer here is as informative as an affirmative one.

The fourth step concerns the code, if the store has been customised, and it is close to the question we have looked at separately in the article on what you own when the system is ready. Here the practical side is enough: where the repository sits, who can access it, and whether it transfers to you with the store, because a repository in the seller’s personal account stays in the seller’s personal account after the deal if it is not moved separately.

Beside the repository are access and keys, and they tend to be scattered across places nobody has written down: the hosting panel, the domain account, the payment panel, the email service, keys for external services, and analytics. It is worth asking for a list of them in writing before the deal and checking it afterwards, because a key that nobody handed over usually shows itself when something stops working, and by then the seller is already gone.

The fifth is the list of recurring costs that arrive with the store, and it tends to be longer than the buyer expects, because it includes the platform subscription, separate plugin subscriptions, the theme, the payment intermediary’s commissions, hosting, the domain and certificates, and each of them has its own renewal date and its own price after the first term. It is worth putting this list into one table before discussing the price, because that is what shows the store’s real monthly cost.

What to ask for before you sign

Everything above leads to a set of demands that does not take much time and that an honest seller has no difficulty meeting: on the analytics side it is Viewer access to the property itself, not screenshots, together with an answer as to whether the No Revenue Metrics restriction has been applied, and on the Search Console side Restricted user access together with an indication of what type of property is open.

On the data side it is a test export before the contract, an answer as to whether password hashes transfer, and clarity about what happens to order history. On the domain side it is confirmation of whose name the domain is registered in today, and an agreement that the change of registrant happens before payment or at the same time as it, not after.

On the payments side it is a question for the payment-service provider, not the seller, because only they can say whether the account transfers and on what conditions, and the seller’s confidence on this point is not proof. If the store has subscriptions, then the same question has to be asked again separately about those, because subscriptions are the part that breaks most often in a move. On the data-protection side it is clarity about how the list was collected and what customers were told at the time, and a written agreement that after the deal the new controller will fulfil their information duty.

This set of demands looks long, but it is shorter than one week spent trying after the deal to recover a domain or restore subscriptions, and an honest seller prepares most of it in a couple of hours. A seller who objects to these demands has with that same act answered the most important question, and that is the cheapest possible way to find it out.

And finally there are two things this article deliberately does not do, because they are not our work and pretending to be another profession would be the worst thing we could do here. We do not give an opinion on what the store is worth, and we do not replace a lawyer on the question of using a particular customer list, because both are other people’s work. If you would like us to check the technical part before you sign, write to us, and we will do it together with the online store development team.