Glad it’s working.
FWIW, the two files you cite (alias.properties & site.properties) should only be found in in the root folder of an NP site (i.e. within a child folder of /sites/). Anywhere else and they shouldn’t be there. Sites aren’t designed to be nested. Each discrete NP site should be single folder of assets within /WebRoot/sites/ (same on Mac or Win OS).
By way of triage, alias.properties is a plain text file and, if opened, some of the items therein might give you pointers as to the source catalogue he site used to create the file, especially the following lines:
catalog.1.gallery = [gallery name or blank if whole catalogue]
catalog.1.path = portfolio://[path to named FDB or SQL catalogue]
catalog.1.user = [portfolio user account used to access data]
From that you might get a clue as to what/where/who went wrong.
When issue like yours crop up it’s usually human error due to someone unfamiliar with the set-up trying to rebuild or re-arrange previous data (often because a site can’t be republished as the source master wasn’t kept).
Also, if you're doing a manual clean-up of /sites/ and deleting subfolders for NP site-es you no longer want, you can also go into the /cache/ folder (a sibling of /sites/) and delete any sub-folders of the same name as the unwanted sites.
A more correct way (once NP's working OK) is to admin it from a Desktop client and then select and delete unwanted sites from there, via the 'Manage sites' tab.
Tip, the latter lists the OS folder names of the published sites. for a support perspective, it's worth ensuring the user admin(s) of Portfolio who do the publishing have some idea of the site names as they relate to the master template sets used to make them (before said person forgets/moves post/leaves).