"But it's just a web page!"

You'll hear this phrase, usually combined with some kind of demand or argument like the following:

"It's just a web page, what's taking you guys that long?"
"It's just a web page, why are you charging so high?"
"It's just a web page, what do you mean you need specs?"
"It's just a web page, just find a free theme and get it going"

And in all these cases it's almost never "just a web page". It's usually a website backed by some Content Management System (CMS) and integrated with a ton of third-party stuff.

Isn't it wonderful how often clients simplify things, either out of ignorance or (in some cases) on purpose? A website becomes "a web page", a web application becomes "a website", and a suite of tools integrated with Web UIs and a ton of third-party systems becomes "the program".

Yes, few clients know how to properly name (or value) technical stuff, and we should all get used to it.

Or should we?

Clients not knowing (and not wanting to know) what their website is and what it should do, almost half a century since computers were introduced into our daily lives, and being currently in the second generation since the web became mainstream, are primarily a danger to themselves - and you. Assuming they don't deliberately oversimplify things targeting your insecurities and your impostor syndrome in an attempt to achieve lower costs, they will actually lose money if their site isn't doing the things it's supposed to right way - in fact, they'll lose money either way.

It's our duty, as professionals, to educate our clients. To make them understand that what we're building for them is not "just a web page". It's much more. And they HAVE to know EXACTLY how much more and how to use it for their benefit.

That, or drop them altogether.

Yes, fire them is what I'm saying. An ignorant client will never understand your high-priced quote, nor will they ever take full advantage of their web site. They will end up paying peanuts and considering it a success, but in the long term they'll end up being really unhappy with both the end result and the impact it'll have on their business.

And they'll blame it on you.

Sad but true, you don't want to be working for such clients unless you're really, really desperate for pocket money or very fresh at this kind of job.

So, dear client, in order to help you avoid putting yourself in an awkward position in case your contractor or agency turns what I'm writing above into practice, the rest of this post is addressed to you.

It's neither "just a web page" or "just a website". It's always more. Here's why.

(Note: if you're not considering a CMS for your website then please stop reading and do something better with your time - this post assumes that you will be using a content management system and not plain old static HTML pages).

PART 1: THE BIG AND ABSOLUTELY OBVIOUS STUFF

Let's start with that. You want a web site, so the first thing you do is try to figure out how it would look like. You usually have two options:

• Buy a template and have it adapted to your needs or
• Order a bespoke design

Be aware that a preconstructed template can be beneficial only if it covers about 80-90% of what you need. Its (usually) low price may tempt you, but having it significantly modified may well surpass the cost of bespoke design.

In any case, you have your design. Now you want a site "that looks like this".

So is your design responsive? Meaning, does it look well on various screen sizes, from mobile to desktop? Making things just smaller won't cut it, in most cases you'll need separate design variations for mobile and tablet screens, since fewer things can fit in there. A gallery with 4 images per row should probably turn into one image per row on mobile, traditional paging in lists could probably be converted to dynamic loading or endless scroll, a table with financial data should be able to display well in a smaller screen, mega menus should transform to hamburger ones and so on.

Don't leave it up to the developers to guess how your website should look like on mobile devices. It's the designers' job. And yours.

WHAT YOU SHOULD DO:

Don't be afraid to go for bespoke if you have special requirements. The overall cost may actually be smaller than having to adapt a template.
Ensure that you get designs for at least two resolutions - mobile and desktop - and preferrably for three, including the intermediate "tablet" resolution. Also ensure that the designers have provided concrete specs regarding the transition from one resolution to another. 
Make sure that you get a truly responsive site that works well in all resolutions. Not only on specific resolutions, ALL resolutions.

WHAT YOU SHOULDN'T DO:

Be contempt with just the desktop designs and target all your remarks to them, ignoring mobile design even if there is one. Actual percentage depends on various factors, but it's mathematically sure that around 50% of your site visitors will be using mobile devices. Don't lose them over cost or personal bias just because there were no mobile devices when you yourself were younger.

Have you got at least 2 or 3 different-sized designs for your site then? Okay, moving on.

PART 2: THE SMALLER (BUT STILL BIG) STUFF

Images

So you've got your design, and you've given it to the developers to integrate into the CMS system of (hopefully) your choice, and you get back a working site (or so you think). Let's see if you can answer the following questions:

• Do image sizes change when they are displayed in mobile devices or tablets, or will your website still be loading 1920x1080 pixel resolution images on 320px phone screens? In other words, are SRCSET tags correctly configured, and are there variations of the pictures (crops or resizes) for lower resolutions that provide smaller image sizes?
• How about background images? Are there any media queries that prevent loading huge background images in mobile resolutions?
• Are smaller images automatically created for the above purpose by your CMS or do you have to manually supply them?
• What if you discover that you need to change some image sizes, crops, or ratios after you've added them? Do you or your developers have to do all the image processing work by hand, from scratch?
• Are the image formats optimized for the web, or are you using uncompressed images that usually target printed media, resulting in enormous overall page sizes and/or taking up a lot of your hosting disk space? (Don't laugh, I've seen it happen).
• If an editor uploads a 10000x10000 image taken with a high-end digital camera, what does the site do? Does it display it as it is in desktop view even though it's uselessly larger than a normal image, or does it automatically resize it to the designated maximum allowed image size?
• Do images used in the site have ALT tags for SEO?

WHAT YOU SHOULD DO:

Make absolutely clear to your developers or agency that don't just need a "mobile responsive" web site, but rather something that utilizes all of the above. Yes, each and every one.

Pay special attention to overall page size in KB (or MB). Google (and other search engines) will rank your site very poorly if you have huge overall page sizes witout valid reasons or very slow loading times due to those sizes. Have in mind that Google follows a "mobile first" approach, where it first checks the mobile version of your site. It is crucial that you have this this version developed to be as effective and fast as possible.

Choose a CMS that can dynamically resize and crop images at runtime and cache them, so that nobody will have to edit hundreds or thousands of images upon a design change in the future.

WHAT YOU SHOULDN'T DO:

Believe that your audience is loyal and that "they'll come anyway" regardless of search engine rating or your site's speed. No audience is truly loyal (except if you're offering financial services, and even then it's having trusted their money to you that makes them loyal, not your site's quality). If you're poorly ranked, people will simply not find your site easily, no matter how good you think your content is. If your site is real slow, people will just move on.

Scripts And CSS

• Does the site (at least) load minified versions of its javascript and CSS files? Even better, is there an automated minifying and bundling mechanism in place? Or does it just load everything in plain text, resulting in large page sizes (another reason for Google to bury your ranking?) are there huge in-page scripts and styles that rapidly increase every page's size that could be loaded as extenal files (and probably minified and bundled with other stuff)?
• Does the site load all CSS and javascripts on every page, regarless of where they are used, thus bloating overall page sizes without reason? (This is something to be discussed if minifying and bundling is used but let's leave that for now)

WHAT YOU SHOULD DO:

Demand that all your scripts and CSS are at least bundled and minified on your live site.
Ask that scripts and CSS are only loaded where they're really used (especially if there's too many of them) and not on every page of your site. Make your site's landing page as "light" as possible in this context by loading only the necessary assets.

WHAT YOU SHOULDN'T DO:

Go with "well, how much bandwidth does that save anyway?". For a site that aspires to be visited by thousands of people each month, each byte and millisecond counts. Multiply each byte not saved by the number of page views per month that you want to achieve and you'll find yourself in the Terabyte zone pretty early on.

Open Graph Tags, Meta Tags, Twitter Tags, Favicons

• Does the CMS give you a way to explicitly specify Open Graph and Meta tags for each page, so that sharing and indexing in social media is more effective? Or do you just rely on Facebook's, Twitter's and other social media sites' guesswork? What's more, can the site automatically generate those tags for you in the first place based on some predefined rules? Can it also generate tags for Twitter cards?
• Does your site use favicons? Does it use variations of favicons for several devices?

WHAT YOU SHOULD DO:

Ask your developer or agency whether there is a way for the site to both automatically create meta and OG tags and let you explicitly specify them overriding the default values. This is the very first thing you'll hear your SEO specialist complain about (provided that you hire one).

WHAT YOU SHOULDN'T DO:

Believe that social networking sites have such good algorithms that they'll always discover the best title, summary, and image for a page of your site being shared. You don't know how many times they'll serve a sponsor's icon, a partner's logo, or a totally irrelevant image, along with garbage titles and empty or identical summaries. They do that. A lot.

XML Sitemaps And Search Engines

• Does your site use an XML sitemap that search engines can read? Is that sitemap dynamic, meaning you don't have to update it manually every time you change something? Does your CMS give you a way to define priority for each element in the sitemap, and exclude pages or whole page hierarchies from it?
• Does your site utilize a robots.txt file that correctly blocks search engines from crawling content you don't need or want to be indexed?

WHAT YOU SHOULD DO:

Demand a dynamic XML sitemap that changes as your site changes, and ask that you can exclude stuff from it as well as set sitemap priority for each page individually.

WHAT YOU SHOULDN'T DO:

Rely on search engine crawlers to index your site. Alhough most of the times they'll do it correctly, chances are that there will always be some URLs that are either not directly linked from inside your site (e.g. ajax calls or even iframes) of more significant than search engines may think (where priority comes to play).

EU Cookie Law 

• If you are in the EU, does your site employ a Cookie Consent box that asks users to accept cookies before they continue?

Security

• Is your site being served using a security certificate (over HTTPS?)
• Does your site take care so that there is no mixed content in your pages (http calls over a https connection)?

WHAT YOU SHOULD DO:

Demand preemptive support for secure connections with no calls to unsecured resources (like CDNs for scripts and CSS, of absolute urls to assets like images and files).

The Often Neglected Stuff

If you are upgrading from a previous site, are there redirections in place that take users from the most popular (but now non-existing) URLs of your old site to pages with similar content on your new site? Do the redirections point to specific pages or do they all just point to your new site in general? Don't ask your developers or agency "why do I have less visitors now". Just give them a list of redirections from old URLs to new ones, make them as specific or generic as you must, and have them add them.

• If your site "listens" on both www and non-www domains, have you specifically instructed your developers to permanently redirect one to the other to avoid the site's content being indexed twice and penalized as duplicate content? Same if your sites "listens" to more than one domain.
• Does your site feature custom 404 error pages that display when some content is not found?
• Does your site feature custom 500 error pages that display when something goes wrong with the server?
• Have you posted about your new site on your site's social media accounts? Taking one step back, does your site have corresponding social media accounts? Like a page on Facebook or LinkedIn, a distinct account on Twitter, etc?

WHAT YOU SHOULD DO:

Ask your developer or agency to design special 404 and 500 pages for your site and integrate them to be displayed on corresponding errors. 
Provide them a list of old url to new url redirections and ask them to implement permanent redirects based on that list when the site goes live
Explicitly ask for non-www to www (or reverse) redirections, as well as http to https redirection.
Create social media accounts and connect them to your site or ask a third party to do it for you. Update your social media accounts (or ask a third party to do it for you) regularly, especially when you have new content on your site. Be sure to have control of all social media accounts yourself and don't just rely on a third party that may disappear suddenly one day with all your social media access.

WHAT YOU SHOULDN'T DO:

Think that secure connections are overrated and only useful when sensitive data is submitted. That's not the case any more. Your search engine ranking depends on whether your site is secure, even if it is just a brochure site with no user input at all. Social media posts will also increase your visitors and your's site's visibility and prestige.

PART 3: INTEGRATION WITH 3RD PARTY SERVICES

Now that your site hopefully features all of the above, you should take the time to see what 3rd party services you should add your site to depending on your site's functionality and purpose.

• You need a way to track visits to your site, see what visitors are interested in most, peak times, bounce rates, all the good stuff that will help you better target your site to your audience. So the question here is: Do you have a Google Analytics account (or an account from a similar service)? If so, does the CMS provide you with a way to easily add it to all your site's pages?
• You also need to submit your site's new XML site maps (see above) and track any 404 errors or search engine crawl errors, as well as trends on how visitors find your site. So have you added site to Google Search Console or any similar service? Have you submitted your site maps there?
• Have you also checked your site's performance ranking with Google Page Speed or a similar tool? Assuming that you've done all things described above, your rank should be fairly good. If not, maybe you should reevaluate what might be wrong with your site.

WHAT YOU SHOULD DO:

Create accounts for Google Analytics and Google Search Console and ask your developer or agency to integrate your Analytics code and any other relevant third-party script in your site, or, better yet, provide you an easy way to do it yourself.

WHAT YOU SHOULDN'T DO:

Let your agency handle your Analytics and Google Search Console accounts and just provide you with reports. You can give them full access to the data, if you like, but you are the one that runs the business and you must learn to read what's reported and act accordingly and on time. And, of course, it goes without saying that if you totally ignore this stuff and don't maintain such accounts at all, you'll lose a lot of valuable information on your site's popularity and ease of use.

PART 4: OTHER STUFF DEPENDING ON SITE'S FUNCTIONALITY

If your site uses forms for visitor feedback, have you had your email credentials correctly set up?

Have you also set up a way to prevent spamming on this? You'll need an anti-robot verification system like ReCaptcha, and you'll need to set up an account and give the public and private keys provided to your developers to integrate it into your live site.

Do you also want users to comment on stuff on your site? If so, you'll need a commenting system. A popular one is Disqus, but you'll (again) need to set up an account and give your developers all the necessary info in order for them to set it up on your site. And yes, you'll have to learn to use it.

WHAT YOU SHOULD DO:

Demand that your site's email settings are set up correctly when the site goes live or ask for instructions on how to set them up yourself.

As with Analytics, create your own accounts and provide access to corresponding embeddable scripts to your agency or developer to integrate them with your site - or better yet, provide you an easy way to do it yourself. Do keep an eye on notifications and reports from those third party systems, because things like comments and feedback are usually essential to your business. Unless you are, I don't know, Shakira, LeBron James, the President or something. But still.

WHAT YOU SHOULDN'T DO:

Restrict user input to a single contact form with no protection at all or, even worse, prompt your visitors to just email you. Chances are you'll be getting more spam than user input and this will make you unwillingly ignore real user input at some time.

PART 5: PERFORMANCE

Google Page Speed can be a great tool to measure the overall performance of your website, but in real use there are also other factors that come into play. A poorly developed site can bring you dozens of headaches when it goes live, especially if it's a high-traffic one. Things you should have in mind:

• Does the site employ correct cache expiry headers for static media, or does it force visitors' browsers to reload content more often than they should?
• Does it use effective caching so that it can keep CPU and disk usage as down as possible?
• Does it use effective memory management so that your site doesn't eat up the server's entire RAM? This is crucial in shared hosting environments - your site can get kicked out because of that - as well as in cloud environments and VPS hosting since more resources mean more money for you to pay. In the long term, you may end up having paid the original cost of the site multiple times.
• How about effective database querying (in case your website uses a database)? You should definitely check whether it gets slow when it comes to filtering or searching lists of stuff.
• Does your site have integrated search? If so, how is it implemented? Poor implementations usually just query a couple of tables in a database expecting to find your search term contained in huge text fields filled with markup or irrelevant information. More serious implementations employ an indexing subsystem like Lucene that allows for full-text and even fuzzy search with lightning speeds.

WHAT YOU SHOULD DO:

Get informed on whether your CMS and your developer or agency can provide you with all the above functionality. Ask for details and, possibly, some metrics. Make sure that your site will still function well under stress and that your hosting specs match your site's requirements.

WHAT YOU SHOULDN'T DO:

Rely on a CDN and let it all play out by itself. Your site will still be underneath the CDN, and even if you manage to save some speed and bandwidth, a slow site will reveal itself after a while. Integrated search, filtering on lists and other more complicated than usual stuff usually bypass the CDN entirely and leave your users frustrated while they are waiting your laggy site's response. If your site makes inadequate use of memory and / or CPU, it may even have to automatically shut down periodically. Don't take that risk.

PART 6: ADMINISTRATION & CONTINUOUS SUPPORT

• How do you deal with new requirements for your web site? Does your CMS allow you to add new content to existing pages, add new pages or whole sections (and integrate them with your menus)? Or do you rely on your developer or agency to do this work for you? And why? Is it because you haven't been trained on the CMS your site runs on, or just because you "don't know how those things work" (and don't want to know)?
• How about new features? Did you develop the site with a fixed list of specs at the first place, or is each new feature discovered on the go and considered "part of the original deal" by you?
• Was training included on the original work of developing and delivering the site?
• Have you, perhaps, signed a support contract with your developer or agency?

WHAT YOU SHOULD DO:

Learn how to use your CMS. Ask (and pay for) training on how to use it, so you can handle your site's contents by yourself and not have to rely on third parties. 
Sign a support contract so that you can have the right to ask for modifications on your site as well as data entry work in case you can't or don't want to do it yourself.

WHAT YOU SHOULDN'T DO:

Try to trick your agency or developer into thinking that a missing feature is, in reality, a bug, or something that was agreed and never implemented. 
Ask them to do extra work thinking they're obliged to
Ask them to do extra work IMMEDIATELY because you need it NOW thining they're obliged to :)

CONCLUSION

Dear client, I honestly hope you realize by now that "it's not just a web page". Not even "just a web site". It's a web of things, all tightly dependent on one another, and you MUST deal with them and ask your developers or your agency for them. Otherwise, you're in serious risk of making them fire you. Yes, THEM fire YOU. Unless you have taken care of (most of) the above, calling your agency every day and complaining that "your site is slow" or that "you don't have the visitors you expected" without having the slightest idea of how all the above things work neither having asked for them to be implemented, you're either dealing with somebody who just took your money and jumped to the next project or with somebody who has already asked you to deal with this stuff and you ignored them. Either way, you won't be in a good place.

(Disclaimer: With this post we do not imply we are perfect and do each and every one of those things correctly, nor that we only accept the perfect clients who know exactly where they are going and how to get there - it's a fact that nobody is perfect! The points above are useful only if they serve as a rough guide to the client as to what they should pay attention to when creating a new site. We've found ourselves - and our clients - in positions less optimal than those described above more often than not, for various reasons, so use the above advice only as reference).