The loan officer website checklist: what borrowers expect before they apply

A loan officer website is ready for borrowers when it does five things: it carries a readable page for every program you originate, it offers a payment estimator that captures the lead on your own domain, it hands the borrower into your actual application without friction, it shows your NMLS identifier and the disclosures your compliance team requires on every page, and it opens instantly on a phone. Everything else on the site is helpful. Those five are the checklist, because those five are what a borrower who was given your name expects to find before they are willing to apply.

This article walks through each item, what borrowers actually do with it, and how to build it so it keeps working after launch. It is written for loan officers, and it applies almost unchanged to a small broker shop or a producing branch manager. It is about websites and lead handling. It is not lending, licensing or financial advice, and nothing in it tells you what a disclosure must say; that is your compliance team’s call, and the checklist assumes they are in the room.

Why the checklist exists: what a borrower does with your name

A borrower who was given your name by a real estate agent, a friend or a past client does the same three things almost every time: they search your name, they look for the program the agent mentioned, and they look for a way to find out roughly what a payment would be. If those three things are on the page they find, the next step is usually a call or an application. If the page is a headshot and a phone number, the next step is a message to the agent asking what to do, and the referral is now something the agent has to manage twice.

That pattern is why the checklist is short. It is not a list of everything a mortgage website could have. It is the list of what a borrower expects before they are comfortable applying, in the order they usually look for it. A site that carries the five items well will outperform a site with twenty features and none of them.

It is also why the checklist is about the borrower, not about you. Your credentials matter, your years in the business matter, and a good profile page says so. But the borrower is not reading the profile to be impressed. They are reading it to decide whether they can start here without being embarrassed by a question. Every item below is designed to make that answer yes.

1. Loan program pages a borrower can actually read

The first thing a borrower looks for after your name is the program the agent mentioned. A single “Loan programs” page with nine bullet points fails them twice: it gives them nothing to read at their own pace, and it gives search engines nothing to rank for the program searches people make in your area.

One page per program

Give each program you originate its own page: conventional, FHA, VA, USDA, jumbo, renovation, construction, whatever you actually work with. A page per program does three jobs at once. It gives the borrower a document they can read on the train without calling anyone. It gives the page a clear subject that search engines can match to a query like “VA loan lender in your city”. And it gives you a place to send a referral with a link, which is far more useful than “look at my site”.

The pages do not need to be long. A useful program page answers who the program is typically designed for, what a borrower usually gathers before applying, what happens after they apply, and how to start. It uses the borrower’s language, not the trade’s. A first-time buyer does not know what an overlay is and does not need to.

What goes on each page

Start with a one-paragraph answer to the question the page title implies. If the page is “FHA loans”, the first sentence says what an FHA loan generally is and who tends to use one, in plain words. Then a short section on the process as it usually runs, a short section on documents borrowers usually gather, a link to the estimator configured for that program, and the application link with the program preselected where your LOS or point-of-sale vendor supports it.

Every program page ends the same way, with the same disclosure block, so the borrower learns where to look and the compliance team knows the wording is identical everywhere. That consistency is not a design nicety; it is what makes the site maintainable when the wording changes.

What stays off the page

Rates, terms, fees and any statement about who qualifies. Program pages describe; they do not advertise. That is the line that keeps a program page from being an advertisement in the Regulation Z sense, which matters because an advertisement that states certain terms must carry the disclosures the rule requires. Your compliance team decides where that line sits for your firm. The practical rule for writing the page is simple: if a sentence would make a borrower think they have been told what they will pay or whether they will be approved, it does not belong on the page.

Google’s own guidance on helpful content is useful here for a different reason. It rewards pages written for people, with a clear purpose, that demonstrate real experience with the subject. A program page written by someone who has walked borrowers through that program reads differently from one assembled from a lender’s product sheet, and it ranks differently too.

2. Calculators as lead capture, not decoration

Almost every loan officer website has a calculator. Almost none of them capture the lead. That is the second checklist item, and it is the one with the most direct effect on your pipeline.

The problem with embedded third-party calculators

Most calculators on loan officer sites are embedded from somewhere else: a widget from a vendor, an iframe from a rate site, a plugin that phones home. When a borrower runs an estimate in one of those, three things happen. The borrower gets a number and leaves. The vendor records the interaction and, in many cases, the contact details. You get a page view and nothing you can follow up on. You paid, one way or another, for the visit, and the lead went to the widget’s owner.

There is a second problem. Third-party calculators are often slow, they often load before your content, and they often carry their own disclaimers that do not match yours. Every one of those is a small tax on the checklist items below.

What an estimator should show and say

An estimator on your own domain shows an illustrative principal and interest figure from a purchase price, a down payment, a term and, if your compliance team allows it, a rate you publish. It can carry placeholder fields for taxes and insurance that you set. It is labeled, on the page and next to the result, as an estimate: not a quote, not an offer, not a rate lock, not a pre-qualification or pre-approval, and not a statement that anyone qualifies for anything. The wording of that label is compliance’s to approve.

Whether a rate appears at all is a decision, not a default. Many loan officers choose an estimator with a rate field the borrower can adjust and no published figure, so the page never states a rate. Others publish one with the disclosures that come with it. Either is workable; the point is that the choice is made deliberately and the site is built to match it.

Capture the estimate, then follow up with context

The estimator asks for a name and a way to reach the borrower, either before the figure appears or just after it. Then it sends the inputs and the result into your CRM or your LOS lead intake as a record with context: the price range, the down payment, the term, and the program page the borrower came from. Your first call starts with a picture of what the borrower is trying to do, rather than with the questions you would otherwise spend the first ten minutes asking.

This is where the estimator pays for the whole site. A contact form gives you a name. An estimate gives you a name, a budget and an intent. The follow-up sequence you already run in your CRM can be tuned to that, and the borrower experiences a call that starts where they left off.

Configuration differs by audience. A reverse mortgage specialist, a commercial lending team and a purchase-focused loan officer need different inputs and different wording, and the pages on this site for loan officers and branch managers describe where each configuration starts. The features page covers the estimator in more detail.

3. The application path: from your page into your LOS

The third item is the one most sites get wrong in the opposite direction: they try to do too much. The marketing site should get the borrower to the application and hand them over cleanly. It should not become the application.

Do not rebuild the application

You almost certainly already have a hosted application from your LOS or your point-of-sale vendor. It handles identity, documents, consent, disclosures and security in ways a marketing site should never attempt. The site’s job is to send the borrower into that application with as little friction as possible and with as much context as the vendor allows.

That means the “Apply” links on your site carry your originator identifier, the branch and the program into the application as parameters wherever the vendor supports it. A borrower who reads the renovation loan page and clicks Apply lands in your application with renovation preselected, not in a general queue where they have to find you again. If the vendor supports an embedded application, it can sit on a dedicated page with the same disclosures as the rest of the site. If not, a clean handoff to the hosted application is better than a half-built form.

Short forms, no sensitive data on the marketing site

Any form that does live on the marketing site should ask only for contact details and the one or two facts you need to route the inquiry. No income, no social security numbers, no document uploads. That keeps the form short enough to finish on a phone, keeps sensitive data inside the systems built to hold it, and keeps the marketing site out of scope for the controls those systems carry. A borrower on a phone abandons a long form; a borrower on a phone finishes a short one.

Where the inquiry lands

Nothing should sit in a web inbox. Every inquiry, callback request and estimate goes into your CRM, your LOS lead intake or both, by API where the platform offers one and through an automation tool where it does not. Each record arrives with the page it came from and the program if there was one. Your existing follow-up sequences fire as they would for any other lead, and nobody has to remember to check a mailbox on Friday.

The test is simple. Fill in your own form from your phone, then look for it in the system you actually work in. If it is not there within a minute, with the page and program attached, the application path is not finished.

4. Compliance footers and NMLS display

The fourth item is the one a borrower rarely notices and a regulator always does. It is also the one that most often drifts out of date, because on most sites it is edited by hand in a dozen places.

What the footer usually carries

A loan officer website footer typically carries the originator’s NMLS unique identifier, the company’s identifier, a licensing line per state the originator is licensed in, the equal housing notice, a link to the NMLS Consumer Access site so a borrower can verify the license, and any disclosure the employer or the state requires on advertising. The profile page repeats the identifier and the licensed states near the originator’s name. What exactly must appear, and in what words, is set by your state rules, your employer’s policy and your compliance team, not by this article and not by whoever builds the site.

The practical requirement for the website is that the block is complete, identical on every page, and easy to change. NMLS Consumer Access exists so that a borrower can look you up; your footer should make that lookup a single click.

Trigger terms and advertising rules

Regulation Z’s advertising rule, 12 CFR 1026.24, defines terms which, if they appear in an advertisement, require additional disclosures alongside them. A page that publishes a rate or certain payment terms is an advertisement in that sense and carries those obligations. This is why the estimator’s wording matters, why program pages describe rather than advertise, and why the decision to publish a rate belongs to compliance. The website’s job is to make it easy to do the right thing: one place for the rate if there is one, one place for the disclosures that go with it, and no stray figures elsewhere on the site.

One block, changed once

The single most useful build decision for compliance is to put the identifiers, licenses and disclosures in one component that is placed on every page, rather than typed into each page. When a license is added, when the equal housing wording changes, when compliance asks for a sentence to be added under the estimator, the change is made once and appears everywhere at the same moment. On a managed site that is a single email and it is live within days. On a site edited by hand it is an afternoon of finding every copy, and one is always missed.

The same logic applies to originator profiles on a branch site. Each profile carries the same structure, so an identifier is never in a different place on two people’s pages, and a departure is one change rather than a hunt.

5. Speed on mobile

The fifth item is where the checklist meets physics. A borrower opens your site from a text message, a listing agent’s email or a search result on a phone, and decides in the first second whether the page is worth waiting for.

The thresholds Google publishes

Google’s Core Web Vitals are the clearest public benchmark. The thresholds web.dev publishes are a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, each measured at the 75th percentile of page loads. Google Search Central describes page experience, including those metrics, as one of the signals its systems use to evaluate whether a page delivers a good experience. That is the ranking reason. The borrower reason is simpler: a slow page reads as a careless business, and mortgage is a business where care is the product.

What makes a mortgage site slow

The same things, on almost every site. A rate ticker loading from a third party. A chat widget that initialises before the content. Three tracking pixels. A hero video. A calculator in an iframe. A page builder that ships a large script bundle to render a paragraph. None of these are individually fatal, and together they are why a site that scored well on launch day scores poorly six months later, after each department added one thing.

How to keep it fast after launch

Speed is a build decision, then a governance decision. The build decision is to serve static HTML from an edge network, ship almost no JavaScript, load fonts and images sized for the device, and make the estimator the only interactive element that loads at all, after the page has painted. The governance decision is that nothing is added to the site without someone measuring the page afterward. A managed site does this by default: every page is measured after every weekly update, against a floor that is written into the terms. A hand-maintained site can do it too, if someone owns it. Most do not, which is why most drift.

Test it the way a borrower experiences it: on a phone, on mobile data, from a link in a text message. If you see a spinner, so do they.

The rest of the checklist

The five items above are what a borrower expects before applying. A handful of other pages make the site complete, and they are quick to list.

A profile page with a photo, a short plain-language introduction, your identifier and licensed states, the programs you focus on, and your direct application link. A page for real estate agents, because they are your referral source and they want to know how you handle their clients. A page of reviews, presented honestly, with the platform they came from. A contact page that offers more than a form: a phone number, an email, and the hours a person answers. A short “how the application works” page that sets expectations for what happens after the borrower clicks Apply. And an about page that says, in one paragraph, why you do this work.

None of those replace the five. All of them are easier to keep accurate when the site is built the way the five require: one block for disclosures, one place for each program, one path into the application, and a build that stays fast because nothing is added without measurement.

Putting the checklist to work

Run your own site through the five items from a phone, as a borrower would. Search your name. Find the program page. Run an estimate. Click Apply. Scroll to the footer. Time each step. Where the site fails, the fix is usually structural rather than cosmetic: the program pages do not exist, the estimator belongs to someone else, the application path loses the borrower, the disclosure block is hand-typed in nine places, the page loads a widget before the headline.

Structural fixes are what a managed build is for. The plans on this site carry every item on this checklist on every tier, including the estimator on your own domain and the application path into your CRM or LOS, with the site kept fast and the disclosure block changed once when compliance asks. If you would rather see it than read about it, book a demo and we will walk through a site built for your kind of mortgage business, on your screen, with your programs.

Whichever way you build it, keep the borrower’s three questions in view: is this the person I was told about, is this the program they mentioned, and can I find out roughly what it costs and start without being embarrassed. A site that answers all three, on a phone, in a second, has done its job.