The store moved to a new domain, the storefront opens, but the admin panel stubbornly redirects to the old address. Or another scenario: pages seem to work, but the layout is broken, images disappeared, and the browser console is filled with mixed content errors and references to a domain that no longer exists. Both situations have one reason: the store's address in OpenCart is hardcoded in more than one place, and you can't change it "in settings" because there is no such option in the admin panel at all.
Let's figure out where the store address actually lives and what needs to be touched so the migration goes smoothly.
Where OpenCart stores the address
Not in the database, as many would expect. The base address is set by constants in two files:
config.phpin the site root, for the storefront;admin/config.php, for the control panel.
In the root file for OpenCart 3.x it looks like this:
// HTTP
define('HTTP_SERVER', 'https://newshop.ua/');
// HTTPS
define('HTTPS_SERVER', 'https://newshop.ua/');
In the admin file there are more constants, and it's this one that's most often forgotten:
// HTTP
define('HTTP_SERVER', 'https://newshop.ua/admin/');
define('HTTP_CATALOG', 'https://newshop.ua/');
// HTTPS
define('HTTPS_SERVER', 'https://newshop.ua/admin/');
define('HTTPS_CATALOG', 'https://newshop.ua/');
Two points that people stumble on most often.
First: the trailing slash in the address is mandatory. Without it, OpenCart will concatenate paths incorrectly, and you'll get broken links like https://newshop.uaindex.php.
Second: if the admin folder is renamed (and for security it should be renamed), the HTTP_SERVER in the admin config must have the new folder name, not admin.
The symptom of a forgotten admin/config.php is recognizable immediately: the storefront works on the new domain, but trying to enter the admin panel ends with a redirect to the old one or an endless loop on the login page. The old address in the root config.php manifests differently: the page opens, but styles, scripts, and images are generated by the engine with the old domain. Then two scenarios. If the old domain is already dead, resources simply won't load and the console throws ERR_NAME_NOT_RESOLVED. If it's still alive and responds via http, the browser blocks such requests as mixed content, and the store looks like bare HTML without styling.
Steps to take during migration
- Edit both
config.php: replace the old address with the new one in all constants, with the protocol and a trailing slash. - Clear the cache: delete the contents of
system/storage/cache/(leave the directory itself). - Check
.htaccessin the root: if there were rules with the old domain hardcoded (redirects, RewriteCond by HTTP_HOST), update them.
At this stage, the store already opens at the new address. But it's too early to stop, because the old address hasn't gone anywhere: it's sitting in the content.
Remnants of the old address in the database
Constants in configs only account for link generation by the engine itself. Everything you entered manually has remained as it was: absolute links to images in product descriptions, links in articles, banners, module settings. A classic picture after migration: a product opens on the new domain, but images in the description are pulled from the old one. If that one is already shut down — broken images, if it still works via http — the same mixed content, only this time from content, not from configs.
Go through tables with descriptions:
UPDATE oc_product_description
SET description = REPLACE(description, 'https://oldshop.ua', 'https://newshop.ua');
UPDATE oc_category_description
SET description = REPLACE(description, 'https://oldshop.ua', 'https://newshop.ua');
UPDATE oc_information_description
SET description = REPLACE(description, 'https://oldshop.ua', 'https://newshop.ua');
Before any bulk UPDATE, dump the database. Though it may hurt, but you can't run such queries without a backup: one inaccurate REPLACE, and there's nowhere to roll back.
301 redirects and Search Console
Technically the store has moved, but for Google these are still two different sites with identical content. If the old domain is still in your possession, set up a permanent redirect from it to the new one, page by page, not everything to the homepage.
For NGINX this is a separate server block:
server {
listen 443 ssl;
server_name oldshop.ua www.oldshop.ua;
return 301 https://newshop.ua$request_uri;
}
For Apache — a rule in the old site's .htaccess:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?oldshop\.ua$ [NC]
RewriteRule ^(.*)$ https://newshop.ua/$1 [R=301,L]
Then go to Search Console: add the new domain as a separate property, verify it, and use the "Change of address" tool on the old property. This speeds up the repositioning, although the full migration in the search engine's eyes will still stretch over weeks. Don't forget to update the sitemap (in standard OpenCart it's generated at index.php?route=extension/feed/google_sitemap already with the new domain, but the link to it in robots.txt and in Search Console itself needs to be replaced manually) and check robots.txt if there was an absolute path to the sitemap map written there.
And keep the redirect from the old domain alive for at least a year. Dropping it after a month, "because everything has already moved", means giving competitors all the weight of external links that led to the old address for years.
Checklist after changing the address
- New address with trailing slash in
config.phpandadmin/config.php(all constants, includingHTTP_CATALOG) - Cache in
system/storage/cache/cleared - Admin panel opens and doesn't redirect to the old address
- Styles, scripts, and images load from the new domain (check in browser console)
- Product, category, and article descriptions checked for absolute links, database backed up before REPLACE
- 301 redirect from the old domain works page by page
- Search Console: new property added, "Change of address" started, sitemap updated
- Homepage, category, and product card opened manually: no broken images or mixed content errors in console
