The websites I get asked to fix were almost all accepted by an owner who looked at them on a laptop, decided they looked nice, and paid. That is a completely reasonable thing for a non-technical person to do. It is also how sites arrive with no headings, no analytics, images nobody compressed and a contact form that goes to an inbox nobody owns.
The leverage is entirely in the timing. Before the final invoice, a developer has a strong reason to fix things. After it, you are asking for a favour. So here is what I would check first, in the order I would check it, none of which requires knowing how any of it works.
Fifteen minutes, on your phone, on mobile data
Not office wifi. Mobile data, standing outside if necessary. This single test finds more problems than the rest combined.
1. Time it. Count how long until you can read something. Three seconds is acceptable; ten is a defect, not a preference. Slow sites in Nepal are usually slow for reasons that are fixable in an afternoon — I measured this across 34 sites and the median response was under a second, so a slow site is a choice somebody made.
2. Scroll the whole homepage. Does anything jump as images load? That shift means the images have no dimensions set, which is a two-minute fix and a real irritation for visitors.
3. Tap every navigation item. Including the menu on mobile. Including the logo, which should go home.
4. Rotate the phone. Landscape breaks more layouts than people expect.
The form, properly
5. Send a real message through the contact form. Not "test". A real one, with your name and a real phone number.
6. Confirm it arrived, with every field filled in. This is the check people skip and it is the one that costs the most. A form can show a success message and send nothing at all, or arrive with the name field empty. I found exactly that on my own site, and the cause was subtle enough that it survived a long time — the details are here.
7. Ask which inbox it goes to, and get access to that inbox. If enquiries go to the developer's address, or to an address created for the project, you will lose them the day the relationship ends.
Ownership, before anything else
This is the part that is genuinely hard to fix later, and it is not technical at all.
8. Confirm the domain is registered in your name. Not the agency's. Ask for the registrar login, or at minimum confirmation that you are the registrant. A domain registered to a developer is the single most common way a Nepali business loses control of its own website, and it surfaces at the worst possible moment.
9. Get the hosting login, the CMS admin login and the analytics access. In your name, on your email. If there is a Google Analytics or Search Console property, you should be the owner and the developer should be a user — not the reverse.
10. Ask where the backups are and how to restore one. A written answer, not a reassurance.
Four things you can check in the page source
You do not need to understand any of this. You only need to look for text. On the homepage, right-click, choose View Page Source, then use Ctrl+F.
11. Search for <title. It should contain your business name and what you do. If it says "Home" or "Untitled" or the theme's name, nobody did the basics.
In the same view, search for these three and expect to find each one:
<h1— should appear exactly once. When I audited 34 Nepali business sites, four in ten had none at all.canonical— should appear once and contain your own domain.og:image— this is the picture that appears when the site is shared on Facebook or WhatsApp. If it is missing, every share of your site will be a grey box.
12. Type a URL that does not exist — your domain followed by /nonsense-page. You should get a proper not-found page that still looks like your site. If you get a blank page, or a page that looks fine but is secretly reporting success to search engines, that is a real problem and a common leftover from WordPress rebuilds. I hit exactly that on this domain and wrote it up here.
Two questions to ask out loud
"Is this indexable?" Sites are routinely built with search engines blocked so the unfinished version does not get indexed — and then launched with the block still in place. Ask for confirmation it was removed. It is one line in a file and it is the difference between existing on Google and not.
"What happens when I want to change the text on this page?" Get them to show you, on a call, changing one sentence. If the answer is that you email them, understand that you are buying a maintenance dependency, and price it. That is a legitimate arrangement, but it should be a decision rather than a discovery.
What is not worth arguing about
To be fair to developers: some things are genuinely out of scope. Ranking is not something a build can promise. Content is usually yours to supply. Design preferences are preferences.
The list above is different — it is all things that were either done or not done, checkable in minutes, and cheap to fix while the project is open. None of it requires the developer to do anything they should not already have done.
If you have already paid
Run the list anyway. Everything except domain ownership is still fixable, and knowing which items fail tells you what you are actually working with. It is also the honest starting point for anything else — there is no useful SEO to be done on a site that is slow, unindexable and losing its enquiries.
If you would like the list run properly before you sign off on a build, send me the staging link. It is an hour's work and it is considerably cheaper than finding out later.