Key takeaways
- Migration failures are almost never technical. They happen because the project was configured carelessly in the first hour and nobody revisited it.
- Location, device and language settings must be decided before the first data point — changing them later destroys your ability to compare.
- Keyword grouping is the difference between a dashboard that explains the business and one that shows a meaningless average.
- Do not migrate everything at once. Two pilot accounts for two weeks will expose every mistake you would otherwise repeat twenty times.
Every agency that has switched platforms knows the pattern. The decision takes three months, the migration takes an afternoon, and six weeks later somebody notices the numbers do not match the old reports and nobody can explain why. The tool is rarely at fault. The setup is.
This is a practical guide to the first thirty days on the Semalt platform — what to configure on day one, what can wait, which decisions are effectively permanent, and how to run the transition so the historical comparison survives it. It is written for the situation we see most often in Athens: a small team carrying somewhere between eight and thirty active accounts, with reporting held together by spreadsheets and goodwill.
Why platform migrations go wrong
Three failure modes account for nearly all of it, and none of them involve the software.
The rushed configuration. Someone adds twenty domains in an afternoon, accepts every default, and moves on. Two months later the tracking is set to national results for businesses that only serve one neighbourhood, the keyword sets contain terms nobody chose, and the reports look wrong because they are wrong.
The parallel-running trap. The team keeps the old tool "just for a while" and ends up maintaining two systems for a year, with the worst of both: duplicated effort and two sets of numbers that never agree. Parallel running is correct for two or three weeks and corrosive after two months.
The undocumented decision. Someone chooses to track a client at city level rather than national, for a good reason, and never writes it down. Six months later a colleague sees "odd" numbers, changes the setting to fix them, and silently destroys the trend line.
Working parameters from the migration process described below.
Day one: the decisions you cannot undo cheaply
Four settings determine whether the data you collect for the next two years is useful. Make them deliberately, and write down why.
- Search location
National, city or neighbourhood. A law firm serving all of Greece is tracked nationally. A dental practice in Kolonaki is not — its real competitive picture only appears when results are pulled from the area it actually serves. Track the wrong level and you will spend a year explaining volatility that is really just geography.
- Device split
Mobile and desktop rankings differ, sometimes considerably, and the mix that matters depends on the business. A taverna or a beauty salon is overwhelmingly a mobile query. A B2B services firm selling to procurement departments is not. If you must pick one, pick the one that reflects your buyers rather than the one that flatters the chart.
See also: From Rankings to Revenue.
- Language and market
For a bilingual Greek site, Greek and English queries are separate markets with separate competitors and separate demand curves. They belong in separate tracked groups from the beginning, never in one blended set.
- The keyword set itself
Freeze it. Choose the terms that describe the business as it is today, then leave the set alone for the duration of the campaign. Every keyword added mid-quarter makes historical comparison weaker.
The rule that saves the most pain. Write the reason for each of these four choices into the project notes on the day you make them. Not in an email, not in someone's head — in the project. The colleague who opens this account in eight months has no way of knowing that "national tracking" was a deliberate decision rather than an oversight, and they will fix it.
Grouping: the step everyone skips and later regrets
An ungrouped keyword set produces a single visibility line that averages everything together and therefore explains nothing. Grouping takes twenty minutes per account and changes what the platform can tell you for the rest of the engagement.
The grouping that works for most Greek commercial sites:
| Group | What goes in it | What it answers |
|---|---|---|
| Brand | Company name and its misspellings | Is demand for the business itself growing? |
| Commercial | Service + city, "price", "book", "near me" | Is the money side of search working? |
| Informational | "how", "what is", "which", comparisons | Is the content programme earning attention? |
| By service line | One group per revenue stream | Which part of the business is actually growing? |
| By language | Greek set and English set separately | Which market is carrying the results? |
Once these exist, a flat overall curve stops being a mystery. It usually turns out to be a rising commercial group hidden behind a decaying informational one, which is a completely different situation from stagnation and calls for a completely different conversation with the client.
Defining the competitor set honestly
Ask the client who their competitors are and you will get a list of the businesses they meet at industry events. Search does not work that way. Build the set from actual result overlap: the domains that appear on the queries you are tracking, ranked by how much of your keyword universe they cover.
In the Greek market this exercise reliably produces at least one surprise. A furniture retailer discovers that its main organic competitor is a price comparison marketplace. A hotel discovers it is competing with booking aggregators and a travel magazine rather than with the hotel down the street. Those are different strategic problems, and you cannot plan around them if the competitor list was copied from the client's assumptions.
We cover this in detail in From the Greek Market to International.
Cap the set at five. More than that and the comparison chart becomes unreadable, and the discipline of choosing forces you to decide who you are actually trying to beat.
Configuring the first crawl
The audit runs off a crawl, and the crawl needs three decisions before its first run on any non-trivial site.
Scope. On a large ecommerce catalogue, crawl a representative sample across all templates before crawling everything. The template-level problems — which is where nearly all real issues live — show up just as clearly in five thousand URLs as in four hundred thousand.
Rendering. If the site builds its content client-side, rendering must be on. With it off you will receive a report claiming the site has no content, and you will lose a day proving that it does.
Parameters. Faceted navigation on a shop can generate effectively unlimited URLs. Decide up front which parameters to ignore, or the crawl will spend itself on colour and size combinations.
A useful first test. Run the first crawl on a client whose problems you already know. Compare the three issues the platform prioritises against the three you would have named yourself. If they match, you have calibrated the tool. If they do not, you have learned something — either about the site or about the scoring — before it matters.
There is a full walkthrough in Ecommerce at Scale.
Week one: the pilot
Do not migrate the portfolio. Take two accounts — ideally one simple and one complicated — and run them properly for two weeks. Everything you get wrong, you will get wrong twice instead of twenty times.
By the end of the pilot you should be able to answer four questions without opening a spreadsheet: where does this client rank on its commercial terms, what changed technically since the crawl started, who is gaining visibility in the tracked competitive set, and what did the backlink profile do this month. If any of those still requires a manual export, the setup is not finished.
Weeks two to four: rollout and handover
- Batch the migration by client type
Move similar accounts together — all the local service businesses, then the shops, then the bilingual sites. Settings and groupings repeat within a batch, so the third account in a batch takes a fraction of the time the first one did.
- Rebuild reporting from the platform, not from habit
Resist recreating your old report layout. The point of consolidating is that the report can now read live data. If you rebuild the same manual deck, you have bought a tool and kept the work.
- Give clients read access before they ask
Stakeholders with a live dashboard stop suspecting that nothing happens between reports. Spend fifteen minutes explaining what normal weekly volatility looks like, or every wobble will generate an email.
- Retire the old tool on a date
Pick the date during the rollout and put it in the calendar. Without a date, parallel running becomes permanent, and the whole exercise loses its point.
How to tell whether the setup is right
Signs the project is configured well
- You can explain what every tracked keyword is doing there
- Weekly volatility is small enough that a real change stands out
- The client's commercial URLs are tagged as a group
- Someone else could open the account and understand the choices
Signs it will cause trouble later
- Rankings jump every week for no visible reason
- One blended visibility line for a bilingual site
- Competitors were copied from the client's own list
- Nobody remembers why the location was set that way
The thirty-day checklist
| When | Task | Why it matters then |
|---|---|---|
| Day 1 | Location, device, language, keyword set — documented | These become permanent the moment data collection starts |
| Day 2 | Keyword grouping by intent and service line | Ungrouped data cannot explain anything later |
| Day 3 | Competitor set from result overlap, capped at five | Wrong competitors mean a wrong strategy |
| Week 1 | Crawl configuration and first audit on two pilot accounts | Calibration before scale |
| Week 2 | Reporting rebuilt from live data | The reason the migration exists |
| Week 3 | Portfolio rollout in batches | Repetition makes it fast |
| Week 4 | Client dashboard access, old tool retired | Ends the parallel-running cost |
What the first month actually buys you
At the end of thirty days done properly, the change is not that you have a new tool. It is that questions which used to require an afternoon now take a minute: which accounts moved, why, and what is worth doing about it this week.
The accounts that were quietly declining become visible, because the segmented view stops averaging them into the healthy ones. The technical problems that used to surface when a client complained now surface in a crawl diff, which is a much better place to find them. And the monthly report stops being a production task, which is where most of the recovered time comes from.
None of that arrives automatically. It arrives because the first hour was spent carefully. If you want to see what a properly configured project looks like before committing a portfolio to it, open the dashboard, set up one domain you know well, and check whether the first crawl tells you something you did not already know.
Frequently asked questions
How long should we run the old tool in parallel?
Two to three weeks, with a retirement date fixed in advance. Parallel running is useful while you verify that the new tracking matches your expectations. Beyond a month it stops being verification and becomes duplicated work, with the added cost of two sets of numbers that never quite agree.
Can we import historical ranking data?
Historical positions measured by another tool with different location, device and depersonalisation settings are not comparable to new measurements, so importing them creates a false trend line rather than continuity. The honest approach is to treat the migration date as a baseline, keep the old reports as an archive, and tell the client explicitly that the series restarts.
How many keywords should we track per client?
Enough to represent every revenue stream and no more. For a local service business, thirty to eighty well-chosen terms describe the market better than four hundred. Large sets feel thorough and mostly add noise, because the long tail is where measurement is least stable and where a single volatile term can distort a group average.
Who should own the account setup in a small agency?
One person, with the reasoning written into each project. Setup by committee produces inconsistent configuration across the portfolio, which is the single most common reason two clients' reports cannot be compared. The work is small; the consistency is what matters.
Open your Semalt dashboard
Site audits, rank tracking, competitor data and reporting in one place. Sign in and you will be looking at real numbers for your own domain within minutes.
Sign in to SemaltOr browse the service overview at semalt.com.
