When I started building my website, I was thinking about how to show more of my work. A résumé gives someone a quick overview of my experience, but it leaves limited room to explain how I approach a problem, what I investigated, and what I learned along the way.

I also started thinking about how people find candidates now. A recruiter might read a résumé directly. An applicant tracking system might extract the work history into separate fields. Someone might search Google for a skill, find an article, and then look at the person who wrote it. An AI search tool might summarize information from pages it can access.

Each situation asks something different of the same professional story. That realization changed how I think about a résumé and a website. I want them to work together so a person can find my experience, understand it, and follow the evidence.

The number 7 made me think about visibility

Ask a language model to choose a random number, and its answers may follow patterns instead of an even distribution.

Researchers tested several models across different number ranges, languages, and settings. For numbers from 1 to 10, three models in their study chose 7 in approximately 80% of the responses they examined. Read the study.

I find that interesting because it shows that a system’s answer can reflect patterns in the information and processes behind it. The researchers discuss training-data bias as a possible explanation, though the study does not prove every reason a model favored a particular number.

There is a limit to the comparison. Choosing a number is different from evaluating a job candidate. The study does not show that repeating my name online will make a hiring system select me. Search tools, résumé screeners, and language models use different information and methods.

The useful question for me is more practical: When someone searches for my experience, what information can they actually find and understand?

A résumé has to make sense to a person and a parser

An applicant tracking system, often called an ATS, can extract information from a résumé and place it into an applicant profile. Some employers also use tools that compare applications with job requirements. The technology and hiring process vary by employer, so I do not assume that every application is scored the same way.

The first step is making sure the information can be read.

Greenhouse’s résumé parsing guidance identifies things that can cause problems, including image-only résumés, complex columns, tables, and contact information placed in headers or text boxes. Lever suggests a simple check: try selecting the text in the file. If you cannot highlight it, a parser may have trouble reading it too.

My practical checklist is:

  • Use clear headings such as Experience, Education, and Skills.
  • Keep job titles, employers, and dates easy to identify.
  • Use a text-based PDF or another format the application accepts.
  • Review the application fields after uploading. Parsing can make mistakes.
  • Include relevant skills in the context of work I actually performed.

The last point matters to me. If a role asks for payroll software support, I can explain that I helped customers with payroll batches, earning and deduction codes, onboarding, and reports. Those details give a recruiter something more useful than a list of software names.

A website gives the résumé somewhere to lead

A résumé has limited space. My website gives me room to explain the work behind a bullet point.

For example, a résumé might say that I investigate billing issues and coordinate corrections. A work story can show how an address-change error affected a member’s coverage, what I reviewed, how I worked with billing, and why I followed up afterward.

That context gives a reader a better view of my judgment and communication. It also helps me prepare for interviews. Writing out the situation makes me think through what happened, what my contribution was, and which details I can support.

I can do the same with my software support experience. Instead of relying on a broad title, I can explain the types of Paylocity questions I handled and how I helped customers use the platform.

My goal is to make the connection easy to follow:

  1. The résumé identifies the relevant experience.
  2. The website expands on a specific example.
  3. The interview gives me space to discuss the decisions and what I learned.

Not every recruiter will open a portfolio, and a website is not required for every role. When someone does want more detail, I want the explanation to be ready.

Search visibility starts with clear information

Search engine optimization, or SEO, sounds technical, but much of the work starts with basic questions: What is this page about? Who wrote it? Can someone find it from another page? Does the title help them decide whether to read it?

On my site, that means using descriptive article titles, linking related work, and making my experience understandable in plain language. It also means keeping my name and professional details consistent across my résumé, website, and public profiles.

Consistency helps a reader connect the pieces. If my website describes payroll and HR software support, my résumé should explain that same experience accurately. If I update a role or contact method, I should check the other places where someone may find me.

Google says its usual search guidance also applies to its AI search features. It does not require a special AI-only schema to appear in those features. A sitemap can help Google discover pages, but Google says it does not guarantee indexing or a higher ranking. Google’s AI search guidance and indexing FAQ explain those limits.

That gives me a useful standard: publish pages that make sense to the person reading them, connect those pages clearly, and check whether search engines can access them.

Some AI tools answer questions using information retrieved from the web. Others may rely on information available in a different context. A candidate should not assume that every hiring tool searches the public internet, visits a portfolio, or reads every page it finds.

For web-based AI search, accessibility still matters. OpenAI’s crawler documentation distinguishes its search crawler, OAI-SearchBot, from other crawlers. Allowing a search crawler to access a page can make the page available for discovery; it does not guarantee the page will be indexed, cited, or included in an answer.

I also want to make my pages easier to interpret if they are found:

  • State what I did in direct language.
  • Label fictional exercises as fictional.
  • Link to the source when an article relies on research.
  • Keep dates and qualifications close to claims that need them.
  • Avoid adding keywords or credentials I cannot support.

I cannot control whether a model mentions my name. I can control whether the information I publish is clear enough for a reader to understand and verify.

Build a body of work you can maintain

My plan is to use content as part of my job search by documenting work I can explain. That could be a story about resolving a billing issue, a guide to reviewing an AI-drafted note, or an example of helping customers use payroll software.

Each piece should have a reason to exist. What question does it answer? What does it show about how I work? What evidence can I include without sharing private information?

I also want the articles to help me grow. If I am learning a new skill, writing about a small project can force me to explain what the tool does, where I needed help, and what I would improve. That gives me something concrete to discuss when an employer asks how I learn.

I do not need to become a search engine’s favorite answer. I want a recruiter who finds my name to see a consistent picture: the work I have done, the problems I am learning to solve, and the next direction I want to take.

A résumé can start that conversation. A useful website gives it room to continue.

Reviewed

Work stories omit identifying details. Fictional examples are identified in the text. Views are my own.