About the studio
A digital practice. Not an agency.
DSEO Marketing grew out of a simple idea: a digital presence should make the business easier to understand.
The work connects web design, development, visibility, content and strategy. But those are tools, not the product. The real product is understanding.
What it means for the product to be understanding
When we say understanding we do not mean a nice idea. We mean four concrete things that either happen or do not.
A person has to understand what the business does, on the first screen, without effort.
A search engine has to understand how the pages relate to each other, because it reads them without seeing them.
Somebody on a phone has to be able to get to the end without fighting the interface.
And a customer has to know how to reach a real person, without forms that go nowhere.
If those four hold, the site works even if the design wins no awards. If they fail, no amount of styling saves it.
What DSEO Marketing is not
It is not a large agency. There are no departments, and no account team standing between you and whoever does the work. You talk directly to the person building it.
That has advantages and it has a limit, and both are worth saying. The advantage is that nothing gets lost in translation, and decisions get made quickly and on technical grounds. The limit is capacity: we do not take on more projects than can be done properly at once.
It is not an hours shop either. We do not sell maintenance packages just in case, or add-ons you have to keep paying for so the site keeps working.
The house rule
Never claim more than can be demonstrated.
It sounds obvious, but it rules out most of what gets said in this industry. It rules out promising search positions. It rules out inventing client counts or result percentages. It rules out fabricated reviews and ratings stuffed into structured data so a little star shows up in Google.
That rule also decides what appears on this site. You will not find a number of projects delivered, or an improvement percentage, or a client logo that does not exist. If something cannot be checked, it does not get published.
Writing this way costs more. It is easier to claim a round number of happy clients than to explain how you work. But anyone can invent the first, and nobody can fake the second.
Why the code decides whether you get found
A search engine does not look at your page. It downloads it, reads it and decides. And the order in which it does those three things explains most of what people put down to luck.
First it crawls: it requests the HTML file and reads it exactly as it arrives. Then, if the page needs to execute JavaScript to show its content, it sets it aside in a render queue and comes back later, when resources are available. Only then does it index whatever it found.
That «comes back later» is where half the web gets lost. If your text, your links and your headings live inside a script that has to run, you are not competing: you are waiting your turn. If the content is already in the HTML, you get read on the first pass, with no queue and no dependence on there being rendering budget for you that day.
That is why content here is served written into the HTML, and JavaScript only adds behaviour on top of something that already works without it.
There is only one main thread
Every kilobyte of JavaScript has to be downloaded, parsed, compiled and executed. And that does not happen on a powerful server: it happens on the phone of whoever is visiting you, which is almost always considerably slower than the machine the page was designed on.
While the browser processes that code, it does nothing else. It does not paint, it does not respond to a tap, it does not fetch the next image. It is a single lane. That is why a site can look instant in the office on fibre and take forever out on the street on patchy coverage.
The difference between three kilobytes and three hundred is not a number to show off in a meeting. It is the difference between somebody seeing your offer and closing the tab before reading it.
And there is a less obvious consequence: what you do not load cannot break. A visual builder has to cover every possible case, so it ships the code for all of them even if you use three. Each of those scripts updates on its own schedule, and every update is a chance for something to stop working on a Tuesday morning without anybody having touched a thing.
What is actually measured, and what nobody can promise
Google publishes three experience indicators. One measures how long the main content takes to appear. Another measures whether elements jump while the page loads: that moment when you go to press a button and it moves under your finger. The third measures how long the page takes to respond when you interact with it.
All three get worse with every library that was not needed, every typeface requested from somebody else's server, and every image served without dimensions.
Now the honest part: none of those indicators guarantees a position. They are engineering and experience targets, not a ranking lever. Anyone promising you the top spot in exchange for improving them is selling something they do not control. What they do describe precisely is why somebody stays or leaves, and that genuinely depends on how the page is built.
The same goes for the rest of the craft. Structured data helps a search engine understand what kind of entity you are, but does not guarantee a rich result. A sitemap helps discovery, but does not guarantee indexing. Saying it that way sells less and is the only thing that is true.
Structure before style
A machine that reads without seeing needs hierarchy. A heading that is genuinely a heading, not large text painted with styles. Links that are links, not blocks with a click detector bolted on. Sections marked up as sections.
When that structure is right, three things happen at once, and all three matter. The search engine understands what each page is about and how it relates to the others. A screen reader can move through the site in order. And the page keeps working even if the JavaScript fails, gets blocked, or simply takes its time.
That last one is not a theoretical detail. Poor connections, browser extensions, corporate networks that filter scripts: there are many ways to end up without JavaScript. A well-built page degrades; a badly built one goes blank.
The pieces, explained
If you have read this far and want to understand what people are talking about when they talk about web development, this part is for you. There are four pieces and each has a different job.
HTML: the structure
HTML is the skeleton. It does not decide colours or movement: it decides what each thing is. This is a heading, this a paragraph, this a list, this a link, this a form.
It looks like the smallest piece and it is the most important, because it is the only one everybody reads: the browser, the search engine and the screen reader of a blind person. A heading written as a heading is understood in all three. A heading made of large bold text is understood in one, the visual one.
That is called semantic HTML: using the element that matches the meaning, not the appearance. It is free, it weighs nothing, and it is the difference between a page that can be interpreted and one that has to be guessed at.
CSS: the presentation
CSS decides how things look. Typefaces, colours, spacing, and above all where things sit on screen.
It has two mechanisms worth knowing. The cascade, which means several rules can affect the same element and the most specific — or the last written — wins. And media queries, which let the layout change with the width of the screen: that is why the same page can be one column on a phone and three on a desktop, without duplicating content.
A detail almost nobody knows: CSS blocks painting. The browser draws nothing until it has the styles, so it does not show you the page naked and then dress it in front of you. That is why a huge stylesheet, or one requested from a slow server, delays what the visitor sees even when the text had already arrived.
JavaScript: the behaviour
JavaScript is the only one of the three that executes. The other two are read; this one runs.
It is for what happens after loading: opening a menu, validating a form before sending it, playing a video when it comes into view. All of that is behaviour, and that is its territory.
The common mistake is using it for what is not its job. If the page content only exists once JavaScript runs, you have turned something that was read on the first pass into something that has to be waited for. And if it fails, nothing is left.
The right approach is called progressive enhancement: make it work without JavaScript first, then add behaviour on top. A menu that without JavaScript is still a list of working links. A video that without JavaScript shows its poster frame instead of a hole.
Node: JavaScript outside the browser
Node is JavaScript running on a computer instead of in a tab. That opens two completely different uses, and confusing them is the source of a lot of misunderstanding.
The first is as a build tool. Node works on your machine before publishing: it bundles files, compresses images, generates the pages and checks nothing is broken. That work happens once and the result is finished files. Node does not travel with the site.
The second is as a server: a program that answers every visit in the moment, computing the page on the fly.
This site uses the first. Every page is generated at publish time and served ready-made. A visitor does not wait for anybody to compute anything, and there is no application server to maintain, update or defend.
Static, dynamic and the CDN
A static site is a set of finished files the server hands over as they are. A dynamic one builds the response on every visit, usually by querying a database.
Dynamic is needed when the content changes per user: a cart, a private dashboard, a catalogue with stock. When it does not change, it is weight and risk in exchange for nothing. Almost every service business site falls into the second group, and yet gets published on dynamic systems out of habit.
On top of that sits the CDN, copies of your files spread around the world so the visitor gets the nearest one. Sanabria Property Group is served through Cloudflare; USA Luxury Cleaning, from Railway. Both with pre-built files, no per-visit computation.
How it shows on this very site
The fastest way to know whether somebody practises what they preach is to look at their own house.
This site is written by hand, with no visual builders and no purchased templates. What reaches your browser is between 5.8 and 8.9 kilobytes of our own JavaScript, depending on the page, and no interface library at all: no React, no Vue, no jQuery.
Every change is checked automatically across eighteen combinations of language and screen width, from 320 to 1920 pixels, verifying that no element escapes the screen, that touch targets reach 44 pixels, and that no accessibility violation appears.
We do not say it to boast. We say it because it is checkable in the source of this very page. The portfolio has the full breakdown of this site and of the other two, including what is counted and what is not.
Who is behind it
DSEO Marketing is run directly by Daniel Sanabria, a Florida-licensed professional with experience in real estate, community association management and property inspection.
His technical background began in Cuba, where he studied Informatics Engineering at CUJAE. Today he combines that base with hands-on experience running businesses, web development, digital systems, automation and artificial intelligence.
That mix explains the approach: the technical side comes from engineering, and the judgment about what is worth building comes from having run businesses where a mistake costs real money.